3 ms·

To GraphQL there is also the opposite: Just move as much stuff as possible to the backend - make the frontend thin. With that approach you also don't end up wr

by je42 7y ago

To GraphQL there is also the opposite: Just move as much stuff as possible to the backend - make the frontend thin. With that approach you also don't end up writing a lot of specialized REST endpoints for the frontend. You can just use the queries directly and output for example HTML (or json and render that into HTML on the client). You can also do a lot more queries at once, because the services backend have usually more bandwidth and less connection limits than a frontend running inside a browser. You are full control of the queries. Only UI related data is exposed to the frontend. One draw back is the frontend team wouldn't do any business stuff anymore. They would do more generic components that the backend can drive. And depending on the implementation you need more server round trips. On the other hand, there is less JS to load and execute by the browser, since the backend is doing most of the orchestration and rendering.

tracker1 7y ago
Servers are expensive, and if you do it all on the server, you spend more scaling. Clients connecting have their own compute resources that are effectively free in terms of growth of a system as a whole. GQL allows for the client UI/UX to describe what it needs, and the backend delivers that, within the context of well defined data structures that can then be distributed. There's a cost to setting this up, but in the case of Facebook or Netflix, absolutely worth taking on. For a few hundred users, not so much.
- je42 7y ago
  However, Frontends are also expensive when you look on other metrics. They consume battery for example on a mobile device. > GQL allows for the client UI/UX to describe what it needs, and the backend delivers that, within the context of well defined data structures that can then be distributed. In the other model, it is done in the same way, except it is being executed in the backend and not the frontend. Both the frontend and the backend are general computing platforms, but they have different characteristics in terms of performanc, connectivity, control etc. Most UI/UX requirements are not that specific that only a frontend heavy implementation will be adequate to fulfil the requirements. Please keep in mind that back in the old days, when we didn't have JS in the browser, all html was rendered on the server and a thin client was rendering it. And even in right now, sometimes there are architectures popping up that try to make the client thin and the push the majority of the computation to the backend: Like for example Google's Stadia.
  - tracker1 7y ago
    I'm sorry, but the battery example just doesn't fly... the biggest battery usage is the screen, if the user is looking at their phone, they're actively using it. Back in what old day? I've been at this since 1995, and have been using JS pretty proactively since 1998 or so, it's been 20+ years now. Computers are a considerably more powerful and power efficient compared to 1998. If you want to be able to use the internet on an 80386 without a math co... have fun with that. I'll take modern tooling, with modern hardware.
    - je42 7y ago
      Generating UX/UI in the backend doesn't imply to use old tooling. React server side rendering, Vue's Nuxt, etc are all modern ways to render UX/UI in the backend for example. And there are more. The discussion of rendering server side goes deeper than just performance or using a "modern" framework. There is for example: how many teams can work on a single application at the same time and deploy independently features in an efficient manner. How can we share business processing flow requirements between the web version of an application with the native mobile application counter parts in an efficient way, without implementing everything three times. Or other aspects mentioned here, like predictable performance etc. Or choice of language, in the backend your choice of languages to choose is greater and/or simpler than in the frontend. You can add more monitoring in the backend about aspects of your application than you can do in the frontend. Obviously, the frontend has advantages as well. I.e. if something needs to be calculated, animated it is almost instantly available to the user when done in the frontend. Frontend can perform functions offline, can use device specific features: like camera, contact list, push notifications etc. Thus I prefer to look at the requirements and pick the tools for the job that best fulfils all the requirements for a giving application in a given organization and strategy. If that means i do more stuff in the frontend, sure fine. But I wouldn't go for GraphQL just because it is "modern". Being "modern" is not solid reason to choose a technology unless you want to attract developers that like "modern" technologies. Which could be a valid reason as well for some organizations.
      - tracker1 7y ago

by je42 7y ago

tracker1 7y ago

Servers are expensive, and if you do it all on the server, you spend more scaling. Clients connecting have their own compute resources that are effectively free in terms of growth of a system as a whole. GQL allows for the client UI/UX to describe what it needs, and the backend delivers that, within the context of well defined data structures that can then be distributed. There's a cost to setting this up, but in the case of Facebook or Netflix, absolutely worth taking on. For a few hundred users, not so much.

je42 7y ago
However, Frontends are also expensive when you look on other metrics. They consume battery for example on a mobile device. > GQL allows for the client UI/UX to describe what it needs, and the backend delivers that, within the context of well defined data structures that can then be distributed. In the other model, it is done in the same way, except it is being executed in the backend and not the frontend. Both the frontend and the backend are general computing platforms, but they have different characteristics in terms of performanc, connectivity, control etc. Most UI/UX requirements are not that specific that only a frontend heavy implementation will be adequate to fulfil the requirements. Please keep in mind that back in the old days, when we didn't have JS in the browser, all html was rendered on the server and a thin client was rendering it. And even in right now, sometimes there are architectures popping up that try to make the client thin and the push the majority of the computation to the backend: Like for example Google's Stadia.
- tracker1 7y ago
  I'm sorry, but the battery example just doesn't fly... the biggest battery usage is the screen, if the user is looking at their phone, they're actively using it. Back in what old day? I've been at this since 1995, and have been using JS pretty proactively since 1998 or so, it's been 20+ years now. Computers are a considerably more powerful and power efficient compared to 1998. If you want to be able to use the internet on an 80386 without a math co... have fun with that. I'll take modern tooling, with modern hardware.
  - je42 7y ago
    Generating UX/UI in the backend doesn't imply to use old tooling. React server side rendering, Vue's Nuxt, etc are all modern ways to render UX/UI in the backend for example. And there are more. The discussion of rendering server side goes deeper than just performance or using a "modern" framework. There is for example: how many teams can work on a single application at the same time and deploy independently features in an efficient manner. How can we share business processing flow requirements between the web version of an application with the native mobile application counter parts in an efficient way, without implementing everything three times. Or other aspects mentioned here, like predictable performance etc. Or choice of language, in the backend your choice of languages to choose is greater and/or simpler than in the frontend. You can add more monitoring in the backend about aspects of your application than you can do in the frontend. Obviously, the frontend has advantages as well. I.e. if something needs to be calculated, animated it is almost instantly available to the user when done in the frontend. Frontend can perform functions offline, can use device specific features: like camera, contact list, push notifications etc. Thus I prefer to look at the requirements and pick the tools for the job that best fulfils all the requirements for a giving application in a given organization and strategy. If that means i do more stuff in the frontend, sure fine. But I wouldn't go for GraphQL just because it is "modern". Being "modern" is not solid reason to choose a technology unless you want to attract developers that like "modern" technologies. Which could be a valid reason as well for some organizations.
    - tracker1 7y ago