4 ms·

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

by 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
    And you don't think server rendering has a cost? Running a very rich UI client side allows for tens of thousands of users per server, your suggestion reduces that to dozens or a couple hundred. Meaning many times more servers... more servers to configure, support, orchestrate, pay for. Meanwhile the clients are idle resources that could have been used. If you are the one paying for the servers, and you want to pay for 10x+ the servers to support your app, feel free.

by je42 7y ago

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
  And you don't think server rendering has a cost? Running a very rich UI client side allows for tens of thousands of users per server, your suggestion reduces that to dozens or a couple hundred. Meaning many times more servers... more servers to configure, support, orchestrate, pay for. Meanwhile the clients are idle resources that could have been used. If you are the one paying for the servers, and you want to pay for 10x+ the servers to support your app, feel free.