4 ms·
> back-end juggling this stuff just to make these guys happy? I don't see this design pattern as forcing a particular back-end framework? It's merely shifting
by asciiresort 4y ago
> back-end juggling this stuff just to make these guys happy?
I don't see this design pattern as forcing a particular back-end framework?
It's merely shifting the frontend<-->backend contract from JSON to HTML.
Some backend engineers arguably would prefer HTML. Especially if their backends weren't Node. Backends were originally C servers that sent a string of HTML back.
I think backend engineers are fully capable of "juggling" with this new/old paradigm.
- ducharmdev 4y agoThe problem with using HTML in this way is that it couples the view with your data. What happens when non-browser clients (e.g. mobile, other servers) need to easily consume the same API? I know some projects plan to only ever use browser clients, so this may seem irrelevant for them. But I'd rather not try to predict how a business will want to use it's data in the future, and would prefer to design a backend that can be adapted to many scenarios without being bound to a particular client.
- asciiresort 4y ago> But I'd rather not try to predict how a business will want to use it's data in the future Sure, then the backend can expose a gRPC / protobuf interface instead. Mobile apps can readily deserialize this and it will be more performant, both in network bandwidth and data parsing, too, especially with first-party to first-party SDKs. It's strongly typed and serves as a better data contract language than both HTML and JSON. JSON is loosey goosey because of JavaScript. Then the frontend server now plays the role of aggregating data from gRPC backends and converting it to HTML. The gravitation to JSON is a case of web developer familiarity.