In your opinion what are some advantages and disadvantages on choosing an architecture with a backend api + React/Angular as consumers instead of monolithic frameworks like Django or CakePHP/Laravel?

Responses(3)

Advantages of API + React > Monolith

Separation of concerns. My frontend isn't tethered to my backend, so I can do dramatic things like scrapping my frontend completely and recoding it without mucking my API.
Scalability. Being a monolithic website is great, but when you need to start creating mobile or web apps that work off the same API -- you'll quickly wish they were separated. If someone bombs your frontend, you also lose your API, which leaves other apps hanging out to dry.
Easier development. It's hard to hand off a giant monolith to every dev on the team who wants to contribute. It's way easier to clone what I need (API or frontend or both), and build off that. And it makes organizing your git flow difficult, when you're managing features from way different sectors of the architecture.

Disadvantages

Building APIs. People might act like they love building APIs, but it's inarguable that it's a time sink. Anytime you build a feature, you need to create an API endpoint for your external apps to access (and ideally testing, to ensure it works). Sometimes it's way easier just to send data directly from my models to my view.
More work. Every time you want to make big changes to your app, you end up spinning up a development API and frontend, and committing changes to both. It can get confusing working across two projects, and particularly setting up a workflow that works flawlessly every time (like getting Docker containers to sync up). Way easier just to have everything in one project.
More infrastructure. Having a separate API means setting up another subdomain on my Apache/Nginx, and all the devops that goes behind managing that.
Less secure. It's way more secure just to have your app on the same server any secure data is queried/located. Client-side solutions like JWT are great for authentication, but not 100% secure, and require you to run another server as a middleman for any client-side apps anyway (plus CSRF, sessions, and all that jazz). Much easier just to have everything under the same server.
More complicated. Like stated in the previous point, tasks like authentication require setting up an OAuth server, generating JWT tokens, and plenty of other extras on the client-side (CSRF for forms, sessions for encrypted cookies, frontend form validation, etc). A monolithic Laravel app makes all that painless.

well first there is a rule of thumb. everything that does not have isolated complexity in the state can and probably should be done as a classic SSR (server side rendering). Isolated complexity means -> many different moving parts that do different things. For example facebooks timeline, notifications and chats. These states are mainly connected via the layout, not their functionality. As they advance, the harder it gets to control them if those states are not isolated but accessed via even listeners.

The main reason for not throwing a state-component rendering approach onto everything .... it's way less complex just using a SSR template and with complex I don't necessarily mean hard. I mean the amount of parts that have to work together to achieve an outcome, hence the amount of work needed to combine them.

You can however use something like nextJS and write react components ... I leave this up to you.

But in my opinion simplicity should dominate, writing a blog in angular and react has no real benefit, besides making things overly complex. And you can pat yourself on the shoulder. Which is nothing bad, it's just not really beneficial.

However adding certain components to enhance your SSR with a client side engine can be beneficial. For example a searchbar with interactive filters, here a component-based / state oriented design is better than event based design (we just hook up, event-listeners with the content, we lose control of the state and people tend to overload dom events) if we think about it from a JS perspective.

The reason here is simple, if the (search-bar) component has an internal state, it's easier to control than having everyone trying to hook up your elements with events. So if we got 5 filter settings with, I don't know, 3 drop-downs and 1 multi-select this state is way easier to handle if the state is represented not only in the meta markup but is the markup is the result of our state on the client-side.

That is my experience after working with JS and other languages for a long time now.

advantage

interactivity / app feeling
hundreds of packages
isolation of components
better isolation between the systems
Isomorphic approaches, if done right
flexibility
state within the client
reduces the complexity of your backend by pushing it to the frontend

disadvantages

increased complexity in the frontend
a new set of problems (time to first paint, update cycles, SEO)
state within the client (which means -> 2 sources of truth)
overhead which is not always beneficial

And I won't go into the eco system issues because tens of thousands of packages means a lot of shitty packages that won't get maintained in the longterm.

Meanwhile django, php is pretty stable esp because it's not so hyped at the moment. And I won't even go into the state handling problems, Higher order Components and all those things.

These techs are really cool and can be a lot of fun, but they also need work and understanding. Both of them need time. I enjoy working with react / redux / typescript still having a PHP backend. But I have an application with a rather complex frontend that interacts with it self.

If you don't need a lot of isolate moving parts -> stick with a backend system that just delivers plain old HTML, GZIP it use HTTP2 and the right defer, async script tags and utilizes all the existing technologies.

Less work, same result. Which probably means less bugs and more focus on your needed parts.

If bad comes to worse and you find out you want a react component in your parts -> just create the normal Form in the backend, give it a unique id and hook in the react component over the form, so if JS is not working you still have the normal form not as pretty but still fully functional and if it's working you can have a highly interactive search with live reload.

That's called progressive enhancement and that's a robust way to build web-pages. You still have your fun but only as an add-on not your base.

Search Hashnode

In your opinion what are some advantages and disadvantages on choosing an architecture with a backend api + React/Angular as consumers instead of monolithic frameworks like Django or CakePHP/Laravel?

Responses(3)

Advantages of API + React > Monolith

Disadvantages