5 ms·

It has a certain appeal to developers because it makes separation of concerns easier. If your backend only takes in requests and spits out data, you can build

It has a certain appeal to developers because it makes separation of concerns easier. If your backend only takes in requests and spits out data, you can build the backend without spending any thoughts on user experience, layout, templates etc. All you do is design a database structure and API endpoints.

BiteCode_dev 5y ago
Which is ironic, considering the best way to improve your product is to delay the backend implementation until you have a well tested and validated user experience designed. Because you can then derived a good architecture from that, but never the other way around. But UI means dealing with those messy humans, while the backend is this nice quiet place where you can whisper to orderly computers. As a backend dev, my projects started to get way better once I learned to not start with the database model and start to test some mock up on users first. Yet it's so tempting...
tyingq 5y ago
I suppose, but it wouldn't be that different to then render that on the server side instead of the browser.
- ArtTimeInvestor 5y ago
  How so? Say the backend developer coded a bunch of Django views where they output json data. They say "Job done. There are API endpoints for everything now.". Now how does the frontend developer bring their templates into play so the json gets rendered "on the server side"?
  - tyingq 5y ago
    If you were using Django and rendering server side, then I don't imagine you would bother with a REST api layer. But, assuming the the data was already in some REST/JSON api, you would have a Django template filter that used json.loads(), right?
    - ArtTimeInvestor 5y ago
      Either way - how does the front end developer get into play? In a setup where the frontend is doing the rendering, you can give the frontend developer access to a directory with static assets that get output to the browser verbatim. How do you give them the ability to "have a Django template filter" without them having the ability to mess with the rest of the backend? Or do you set up a second server that talks to the APIs of the first server?
      - tyingq 5y ago
        I'm not in a Django shop, but I assume these problems exist anyway. Front-end developers probably also want access to templates, images and css that sit on a server. A template filter would be fairly static though, just converting json into python objects. How to give them access to the Django template itself would be the thing you would want to solve. Node.js seems to have considered some of this, since it's more common to co-mingle front/back end.
        ArtTimeInvestor 5y ago
        I am also not in a Django shop. But I don't think Django templates are safe in a way that they protect the backend from a clueless or malicious frontend developer. Even if they were, you would have to take great care that you do not expose dangerous functionality. So "give them access to the Django template itself" is not enough. You would have to have a whole security concept around it. And that is not enough. How does the fronted dev create routes? How do they create views, which are the glue between the DB and the templates? Node.js is a runtime, not a framework. It does not have routes, views or templates at all. So that comparison makes no sense. No matter which backend framework you choose - you will have a lot more work to bring the frontend dev into the game if you do backend rendering. Please be aware that I am not against backend rendering. I indeed think that backend rendering is the better approach! I just explain here why there is some appeal to developers to write the backend as an API and do the rendering on the frontend.
        5y ago
  - travisjungroth 5y ago
    By making Django templates and rendering them with the view the backend dev created. Django's original architecture handles this exact separation of concerns. A view creates a context dictionary (which is equivalent to a JSON response) and then the template is rendered with the context before being returned with the response to the client. https://docs.djangoproject.com/en/3.2/ref/class-based-views/base/#templateview https://docs.djangoproject.com/en/3.2/ref/class-based-views/... This pattern seems to have declined in popularity, but it can really win in speed and simplicity over a frontend/API split.

BiteCode_dev 5y ago

Which is ironic, considering the best way to improve your product is to delay the backend implementation until you have a well tested and validated user experience designed. Because you can then derived a good architecture from that, but never the other way around. But UI means dealing with those messy humans, while the backend is this nice quiet place where you can whisper to orderly computers. As a backend dev, my projects started to get way better once I learned to not start with the database model and start to test some mock up on users first. Yet it's so tempting...

tyingq 5y ago

I suppose, but it wouldn't be that different to then render that on the server side instead of the browser.

ArtTimeInvestor 5y ago
How so? Say the backend developer coded a bunch of Django views where they output json data. They say "Job done. There are API endpoints for everything now.". Now how does the frontend developer bring their templates into play so the json gets rendered "on the server side"?
- tyingq 5y ago
  If you were using Django and rendering server side, then I don't imagine you would bother with a REST api layer. But, assuming the the data was already in some REST/JSON api, you would have a Django template filter that used json.loads(), right?
  - ArtTimeInvestor 5y ago
    Either way - how does the front end developer get into play? In a setup where the frontend is doing the rendering, you can give the frontend developer access to a directory with static assets that get output to the browser verbatim. How do you give them the ability to "have a Django template filter" without them having the ability to mess with the rest of the backend? Or do you set up a second server that talks to the APIs of the first server?
    - tyingq 5y ago
      I'm not in a Django shop, but I assume these problems exist anyway. Front-end developers probably also want access to templates, images and css that sit on a server. A template filter would be fairly static though, just converting json into python objects. How to give them access to the Django template itself would be the thing you would want to solve. Node.js seems to have considered some of this, since it's more common to co-mingle front/back end.
      - ArtTimeInvestor 5y ago
        I am also not in a Django shop. But I don't think Django templates are safe in a way that they protect the backend from a clueless or malicious frontend developer. Even if they were, you would have to take great care that you do not expose dangerous functionality. So "give them access to the Django template itself" is not enough. You would have to have a whole security concept around it. And that is not enough. How does the fronted dev create routes? How do they create views, which are the glue between the DB and the templates? Node.js is a runtime, not a framework. It does not have routes, views or templates at all. So that comparison makes no sense. No matter which backend framework you choose - you will have a lot more work to bring the frontend dev into the game if you do backend rendering. Please be aware that I am not against backend rendering. I indeed think that backend rendering is the better approach! I just explain here why there is some appeal to developers to write the backend as an API and do the rendering on the frontend.
        5y ago
- travisjungroth 5y ago
  By making Django templates and rendering them with the view the backend dev created. Django's original architecture handles this exact separation of concerns. A view creates a context dictionary (which is equivalent to a JSON response) and then the template is rendered with the context before being returned with the response to the client. https://docs.djangoproject.com/en/3.2/ref/class-based-views/base/#templateview https://docs.djangoproject.com/en/3.2/ref/class-based-views/... This pattern seems to have declined in popularity, but it can really win in speed and simplicity over a frontend/API split.