3 ms·
This is a strong argument for not using a generic JSON api for your core web application, but rather using server side rendering where you have full access to t
by recursivedoubts 5y ago
This is a strong argument for not using a generic JSON api for your core web application, but rather using server side rendering where you have full access to the data store using whatever the native query language is.
Getting web app UX right typically requires page specific query tuning and introducing those as JSON API end points leads to a gronky, churny API. GraphQL helps in this regard, but that has some pretty serious security implications[1].
I wrote an article on this topic back a while back on the intercooler.js blog:
https://intercoolerjs.org/2016/02/17/api-churn-vs-security.html https://intercoolerjs.org/2016/02/17/api-churn-vs-security.h...
You can and should still create a generic JSON API for server-to-server automations, but it has a different set of design considerations when compared with your web app needs (rate limiting, generic but secure functionality, etc.)
[1] - https://twitter.com/AdamChainz/status/1392162996844212232 https://twitter.com/AdamChainz/status/1392162996844212232
- qsort 5y agoI don't disagree in principle, but often you need the API anyway, and it makes little sense to duplicate the effort just for the sake of purity. If you are in that situation, GraphQL is actually worse, because you end up with less control over the SQL you end up running. I can see that idea working very well for content-driven, interactive but mostly static websites, something like HN.
- recursivedoubts 5y agoYour JSON API, once you pull your web app usage and all the special end points for it out, should be pretty regular and not a ton of code. So the actual amount of duplication cam be low, and your API engineer will be bored and happy. :)