i can explain it. (ok, i can't explain why someone would create a react monster instead of using a better suited frontend framework, but i can explain why i prefer to separate backend and frontend)
ever since i started using frontend frameworks for websites, the backend has become trivially simple. so simple that i have been able to reuse the same backend for all my websites built since. most websites do not need more than CRUD on the backend. and even for those that do need more backend logic, separating front and backend makes both parts easier to develop. they don't get entangled, and i can make drastic changes in either part without breaking the other.
frontend frameworks allow me to think of the frontend as an independent client application that runs in the browser. instead of having a complex application that displays here but runs over there, i have two simple applications, one that runs on the server and one that runs in the browser.
using a frontend framework makes development feel like writing a desktop application. i don't have to consider network latency, except to load and update data. but that can happen in the background. it doesn't affect the UI. it makes me think about loading data from the server efficiently. it allows me to preload data in the background. it allows me to cache it so that when the user switches between different views, the data doesn't have to be reloaded, yet it can still be updated.
you can do this with a server framework only too. but getting that working smoothly across multiple page loads is a lot more complex than having all views that share data in a single page application.
I like that too, in theory. We used to call that "rich client". Basically UIs that had full database access.
And there begin the problems. Do you really want to expose a full CRUD API, or are there consistency/security rules you want to enforce? That's cool, but makes API design a little more challenging and frontend development a little more frustrating. SSR eliminates a lot of these problems, and for many types of software, it's quite sufficient.
For a lot of software, it doesn't make that much sense of course, e.g. if you need clients for multiple platforms.
That's the kind of conversation I wanted to have with the candidates that went for that architecture.
Do you really want to expose a full CRUD API, or are there consistency/security rules you want to enforce? That's cool, but makes API design a little more challenging and frontend development a little more frustrating.
fair point, however i don't see that as a drawback. the security/consistency rules you want anyways. and an API makes it easier to enforce them and not allow people working on the frontend to get around them because they have direct access to the database. in difference to what you said, i believe the benefit of a rich client is that it doesn't have full access to the database, but only the access the API provides.
i also don't feel that it makes frontend work more frustrating, on the contrary, it means i don't have to worry about access control in the frontend because the backend is supposed to take care of that.
to give an example: if i want to limit the size of the text field, i have to implement checks twice, once in the html/js, to help the user, and once in the database access to make sure the user didn't cheat. i have to do that regardless of whether front and backend are separated or not. it doesn't make a difference. but the separation ensures that the frontend code can't get around the limit.
where it does get frustrating is when you have different teams that have to communicate and agree. but the problem there is the team size, not the architecture.
this subthread started out with the claim that small teams don't need the complexity of frontend/backend separation introduces. that's where i disagree. the complexity shouldn't be an issue. as i said, i find it reduces complexity. a small team also won't have the communication problems when disagreements arise over the API. they can handle that like disagreements over the class hierarchy or datastructures or whatever. you talk about it, make a decision and everyone is on the same page on what to implement.
That's the kind of conversation I wanted to have with the candidates that went for that architecture
are you still hiring? :-)
For the consistency/security rules, I meant that any API accessible in the browser is also publicly accessible to anyone. Quite a lot easier to e.g. syphon data out of a system than if they just did SSR. So if you want to avoid that, you'll have to build a proverbial Chinese wall between frontend and backend. And whenever you want to add a feature, you'll have to adjust that wall.
For SSR, the devs working on the frontend can access anything they like. Sure, in bigger teams and for important consistency rules you'll want to encode that, but it's all a _very_ solved problem with stuff like Django.
Nope, not currently hiring :/
For the consistency/security rules, I meant that any API accessible in the browser is also publicly accessible to anyone.
not quite. you still need access credentials. having an API doesn't mean that anyone can access it without permission. you protect an API the same way you protect the actual website.
Quite a lot easier to e.g. syphon data out of a system than if they just did SSR.
if the data is sent to the client, then the client ca access it either way. sure, embedding it in HTML makes it harder to parse, but that is really just security by obscurity. that's actually another reason why i prefer APIs. they make it blatantly obvious what data you are publishing. in a SSR page it is easier to let things slip through. the SSR page looks like a closed box, it gives the impression that it is possible to prevent users from entering that box and getting data out of it, but that is an illusion.
you'll have to build a proverbial Chinese wall between frontend and backend.
which is the API. small, only containing what is needed, very easy to verify that private data doesn't leak out.
Yeah, if the API design prevents this, parsing HTML is about as hard. But I've seen a lot of cases where a single request will get you _all_ the data you could ever want, a lot of it not even rendered on the frontend, no need to deal with pagination or anything. Kinda full database access as long as you have an auth token, which any logged in user has.
those are the cases that make it into the news when someone reports the insecurity of a API they found, and then gets accused for breaking into the website or database.
there are many reasons to prefer SSR over SPA, but covering up incompetence should not be one of them. designing an API is not hard.
My main issue with putting state in the frontend is that you introduced sync points, which is where, like, 90% of the bugs happen.
Take form input and validation. Great, let's write out the validation on the frontend. But that doesn't mean much. We need to sync it.
Okay... So let's just write the validation, again, on the backend. Hope it's the same validation. It never is, so we just introduced a whole class of bugs around that.
Or just take a look at routing. Okay, let's route on the frontend. But what about access control? Okay, let's do a little routing logic on the backend too. Oh and now we've run into the same problem.
When you do rich frontend and backend, you always have a minimum of two application states. You have two apps. You cannot get rid of the backend state, it's non-negotiable.
So you have to keep them in sync, or more accurately, try to keep them in sync.
you have to do the same on the server side and your database, if you have one. the API is just data too. you don't keep all your application state in you database, do you?
i don't know what kind of application you have in mind, but in mine the frontend state and the backend state are entirely different things. the only thing that needs to be kept in sync is the data itself. and that's easier than the whole frontend state which is a lot more complex. in most cases you treat the backend like a database itself. there is n additional state to be kept in the backend, than what goes into the database. at least with all the applications i ever built. i am sure there are other applications that are more complex, and i may change my mind when i get to work on one, but i believe most applications are CRUD, and complex UI state is only in the fronted, data state in the backend/database,
my keyboard swallows keys, to remove ambiguity, i meant to say "there is no additional state to be kept in the backend"
I don't see much difference between returning some json or displaying the same data in a server side template.
the difference is how the application feels to the user. especially on a slow network. for every pageload in hackernews i have to wait seconds. as an SPA i would not have to wait at all unless i open a new story. because new comments can be loaded in the background while i read, and my own comment submissions can be sent in the background too.
I was speaking from a developer / technical perspective obviously.