Just a coder and a dad. I love my family and I love to code!!!! started coding at 11, so I have 25 years under my belt. Still love learning about it every day. Black lives matter!
By making it easier to code for a single specific functionality (serving a template, serving json for a profile, displaying a profile with a user and their favorite movies, ...) vs trying to code to an overall product.
When you code the backend and frontend by itself you start to code based off its internal logic and tend to make it more streamlined, focusing on a single responsibility.
sidenote Google SOLID pattern. Then practice this pattern if you don’t already.
A profile gets a user, movies get movies and so on...
When you code as a monoapp, many times you’re coding to an entire project as a whole all in one spot. So even if you practice MVC, you tend to throw everything together like a mixing pot.
You started with a profile, but end up with a profile that not only gets the user, but also handles settings, and getting the user favorite movies and then getting their friends and so on.
At first things made sense but now your profile is doing way more work than it should. You break something every time you add new functionality because it’s so over complicated.
By coding to either the backend or Frontend by itself, you are not holding them reliable for each other.
So on the front end, a profile that also shows a users favorite movies, may make perfect sense. It’s easy to do, you ask the backend for a user and then the users favorite movies. While the backend would have a user and a users movies. Which also makes sense but they are separated out.
Now you’re not forcing the user to handle its movies, you are separating out the domains properly. The movies just ask for a user and returns that users favorites.
Your front end is asking for the data and then it makes it a profile by adding that data in a manor that makes sense.
When you can hyper-focus on a single piece it makes it so much easier to see the architecture as how it should be. If someone says, “can you add wings to my car” you don’t worry, because ymicroou will make a new domain that deals with it. You won’t force all of your cars to know how to have wings.
At the same time you can still give the user want they want without breaking your system to do so. “Here is your car with wings 😉”
It’s a win win. Their are many more benefits such as multiple interfaces (desktop, mobile, iot...) yet one backend to handle them all. Easy to split out when the project grows and the teams grow. Break out to micro services and so on.
Benefits of separating backend/Frontend
There are many benefits of separating them out.
By making it easier to code for a single specific functionality (serving a template, serving json for a profile, displaying a profile with a user and their favorite movies, ...) vs trying to code to an overall product.
When you code the backend and frontend by itself you start to code based off its internal logic and tend to make it more streamlined, focusing on a single responsibility.
sidenote Google SOLID pattern. Then practice this pattern if you don’t already.
A profile gets a user, movies get movies and so on...
When you code as a monoapp, many times you’re coding to an entire project as a whole all in one spot. So even if you practice MVC, you tend to throw everything together like a mixing pot.
You started with a profile, but end up with a profile that not only gets the user, but also handles settings, and getting the user favorite movies and then getting their friends and so on.
At first things made sense but now your profile is doing way more work than it should. You break something every time you add new functionality because it’s so over complicated.
By coding to either the backend or Frontend by itself, you are not holding them reliable for each other.
So on the front end, a profile that also shows a users favorite movies, may make perfect sense. It’s easy to do, you ask the backend for a user and then the users favorite movies. While the backend would have a user and a users movies. Which also makes sense but they are separated out.
Now you’re not forcing the user to handle its movies, you are separating out the domains properly. The movies just ask for a user and returns that users favorites.
Your front end is asking for the data and then it makes it a profile by adding that data in a manor that makes sense.
When you can hyper-focus on a single piece it makes it so much easier to see the architecture as how it should be. If someone says, “can you add wings to my car” you don’t worry, because ymicroou will make a new domain that deals with it. You won’t force all of your cars to know how to have wings.
At the same time you can still give the user want they want without breaking your system to do so. “Here is your car with wings 😉”
It’s a win win. Their are many more benefits such as multiple interfaces (desktop, mobile, iot...) yet one backend to handle them all. Easy to split out when the project grows and the teams grow. Break out to micro services and so on.
thanks for this in depth explanation.