4 ms·

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

by 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? :-)
    - fhd2 1y ago
      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 :/
- conradfr 1y ago
  I don't see much difference between returning some json or displaying the same data in a server side template.
  - em-bee 1y ago
    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.
    - conradfr 1y ago
      I was speaking from a developer / technical perspective obviously.
- array_key_first 1y ago
  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.
  - em-bee 1y ago
    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,
    - em-bee 1y ago
      my keyboard swallows keys, to remove ambiguity, i meant to say "there is no additional state to be kept in the backend"
    - array_key_first 1y ago
      I keep as much state as I can in the database, yes. For example - foreign keys. I use constraints in the database to enforce application logic. I could do this in the backend, yes. But that's needless complexity and it will blow up. Eventually, I'll write something to the database that's inconsistent and then I have to fix it. Because bugs happen.
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.

by fhd2 1y ago

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? :-)
  - fhd2 1y ago
    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 :/
conradfr 1y ago
I don't see much difference between returning some json or displaying the same data in a server side template.
- em-bee 1y ago
  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.
  - conradfr 1y ago
    I was speaking from a developer / technical perspective obviously.
array_key_first 1y ago
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.
- em-bee 1y ago
  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,
  - em-bee 1y ago
    my keyboard swallows keys, to remove ambiguity, i meant to say "there is no additional state to be kept in the backend"
  - array_key_first 1y ago
    I keep as much state as I can in the database, yes. For example - foreign keys. I use constraints in the database to enforce application logic. I could do this in the backend, yes. But that's needless complexity and it will blow up. Eventually, I'll write something to the database that's inconsistent and then I have to fix it. Because bugs happen.

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.