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.

I’d say with separation your pieces are more modular and interfaces generally become cleaner.

Integrated frameworks are logically simpler (especially at first) but could introduce coupling that could lock you in to an approach and/or lead to more mangled codebase.

Similar to monolith vs microservices, there are going to be trade offs either way.

Simple it might be easier to manage since both require different skill sets and it makes sense to separate them for ease of management and finding talents with specific skills in either Front-end or Back-end.

For example, the use of design systems or CSS 3 and Javascript fatigue is a real thing for front-end.

Whereas for the backend they might focus on API development like the use of Postman or GraphQL implementation as part of their backend not forgetting deployment using cloud hosting services like Google or AWS for scaling their services.

Lastly, I'm a full-stack developer but I don't really say I know everything in front-end especially when it comes to designs of website or the UX/UI department.