6 ms·

Any project that doesn't need 30 or more devs with various specialties working on it all at the same time doesn't need the complexity that frontend/backend sepa

Any project that doesn't need 30 or more devs with various specialties working on it all at the same time doesn't need the complexity that frontend/backend separation introduces. I learned this the hard way through years of over-architecting 1-2 person projects as a freelancer. Nowadays, it's just Django with a little bit of Tailwind on top.

LollipopYakuza 1y ago
I second this. In most industries, your clients won't care if the software relies on an ultra scalable architecture split in microservices or a monolith + PostgreSQL.
- thinkingtoilet 1y ago
  In every project I ever do, I start with a server and a postgres database. Every addition to that architecture has to be rigorously defended. So often people add complexity for absolutely no reason. Once you actually start scaling then you can worry about the problems that you think you might have.
fhd2 1y ago
I was hiring for a Django dev earlier this year. For the case study, almost all of them built a thin API backend in Django, and a React monster for the frontend (and in some cases, pretty much all the business logic). When asked about their motivations, almost nobody could explain it. We hired one of the very few people that just used SSR.
- em-bee 1y ago
  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.
  - fhd2 1y ago
    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.
    - em-bee 1y ago
      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? :-)
- LanceH 1y ago
  > and in some cases, pretty much all the business logic and you still have to enforce that business logic in the backend as well.
b_e_n_t_o_n 1y ago
What if you're building a highly interactive front end?
- JodieBenitez 1y ago
  That might be a case where you want a SPA + backend API. But the point is that in many cases you either don't need a highly interactive frontend or the frontend is not that interactive (ie. progressive enhancements work).
  - b_e_n_t_o_n 1y ago
    Ime progressive enhancements are brittle and hard to maintain. If your site doesn't need any JS it's fine, but as soon as it needs some interactivity beyond the absolute basics you benefit from having reusable components and automatic change detection / data binding.
    - JodieBenitez 1y ago
      Not true anymore, as tools like unpoly, htmx and the like make it really easy to integrate and maintain with very little dependency and no build step.
      - b_e_n_t_o_n 1y ago
        Those are part of what I'm talking about re. brittle and hard to maintain. Similar to jquery, just server sideZ
        JodieBenitez 1y ago
        I fail to see the connection with jquery. Anyway brittle and hard to maintain is what we experience now with frontend stacks and codebases with very short lifespan. I can't keep track of components libs du jour that come and go and keep being reinvented with very little value added on each iteration, along with constant api breakage. Brittle, indeed. Meanwhile, Rails and Django have been rock solid.

LollipopYakuza 1y ago

I second this. In most industries, your clients won't care if the software relies on an ultra scalable architecture split in microservices or a monolith + PostgreSQL.

thinkingtoilet 1y ago
In every project I ever do, I start with a server and a postgres database. Every addition to that architecture has to be rigorously defended. So often people add complexity for absolutely no reason. Once you actually start scaling then you can worry about the problems that you think you might have.

fhd2 1y ago

I was hiring for a Django dev earlier this year. For the case study, almost all of them built a thin API backend in Django, and a React monster for the frontend (and in some cases, pretty much all the business logic). When asked about their motivations, almost nobody could explain it. We hired one of the very few people that just used SSR.

em-bee 1y ago
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.
- fhd2 1y ago
  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.
  - em-bee 1y ago
    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? :-)
LanceH 1y ago
> and in some cases, pretty much all the business logic and you still have to enforce that business logic in the backend as well.

b_e_n_t_o_n 1y ago

What if you're building a highly interactive front end?

JodieBenitez 1y ago
That might be a case where you want a SPA + backend API. But the point is that in many cases you either don't need a highly interactive frontend or the frontend is not that interactive (ie. progressive enhancements work).
- b_e_n_t_o_n 1y ago
  Ime progressive enhancements are brittle and hard to maintain. If your site doesn't need any JS it's fine, but as soon as it needs some interactivity beyond the absolute basics you benefit from having reusable components and automatic change detection / data binding.
  - JodieBenitez 1y ago
    Not true anymore, as tools like unpoly, htmx and the like make it really easy to integrate and maintain with very little dependency and no build step.
    - b_e_n_t_o_n 1y ago
      Those are part of what I'm talking about re. brittle and hard to maintain. Similar to jquery, just server sideZ
      - JodieBenitez 1y ago
        I fail to see the connection with jquery. Anyway brittle and hard to maintain is what we experience now with frontend stacks and codebases with very short lifespan. I can't keep track of components libs du jour that come and go and keep being reinvented with very little value added on each iteration, along with constant api breakage. Brittle, indeed. Meanwhile, Rails and Django have been rock solid.