3 ms·
This is something I struggle with a lot in API design. If the frontend is to never join, then the backend has to provide either: 1. a very dynamic API (e.g. Gra
by klysm 3y ago
This is something I struggle with a lot in API design. If the frontend is to never join, then the backend has to provide either:
1. a very dynamic API (e.g. GraphQL) and support arbitrary queries
2. a static but 'bloated' API where every query joins in too much data to cover every use case
3. a static but 'wide' API where each use case gets its own specially crafted response
I have no good answer for what makes sense but I usually straddle 2 and 3.
- solarkraft 3y agoIf GraphQL was actually a query language (as in: allowing you to change the result set, not only the result shape), maybe 1 would be easily possible. Intuitively I would like that. 3 seems to be the most pragmatic option to me when you have good control over each side.
- klysm 3y agoSupporting the interface of graphql from the backend though is usually not very easy - you usually end up with a half baked database implementation that wraps a better database
- qazxcvbnm 3y agoCan you elaborate on what you mean by changing the result set as opposed to the shape?
- nicwolff 3y agoHuh? GraphQL field arguments are used to filter and paginate result sets.
- dustingetz 3y agothis is the problem electric clojure solves: https://github.com/hyperfiddle/electric https://github.com/hyperfiddle/electric
- DanielHB 3y agoIt depends a lot on the product, how wide and deep your API is and the division of labor. Like are frontend and backend separate teams? do people do full stack? At some point there will be a need for some "bloated" API requests. GraphQL can help minimize how many of those you need.