3 ms·
Your response is to the typing nature of GraphQL, but this isn't the only strong reason for GraphQL. GraphQL reduces both response payload size to only what is
by ar_lan 6y ago
Your response is to the typing nature of GraphQL, but this isn't the only strong reason for GraphQL. GraphQL reduces both response payload size to only what is necessary for the client, but also reduces round-trips.
Unless you are writing custom REST endpoints for every aspect of your UI, most formulation of what data a consumer needs will usually resolve in multiple trips to the server. So, you either scale out by having custom REST endpoints to handle each case of this (which both feels odd and presumably won't scale very well), or you take advantage of GraphQL doing this natively.
- collyw 6y ago> Unless you are writing custom REST endpoints for every aspect of your UI Wouldn't that be the normal way to implement a REST API?
- ar_lan 6y agoThe problem is you might end up writing strange endpoints just to satisfy a specific UI page. For example, take a small blog, that holds several posts, each with an author. In GraphQL, you could fetch all the posts, and all info related to the author in the same query (without any new, funny business). In REST, if you wanted this in a single query, you'd need to define some endpoint like /post-and-authors-list that fetches all the posts and complete author information for each post, whereas most REST implementations would probably involve a small set of CRUD steps on all posts, and then several queries to fetch each author for further information as well (based on the author ID in the post). So it's not that REST can't implement anything GraphQL wants to implement, but there is a lot more work involved, is harder to scale out with developers, etc.