3 ms·

I think there are actually a few reasons for this that are addressable. GraphQL clients cover a ton of the functionality—so much so that you're more concerned

I think there are actually a few reasons for this that are addressable. GraphQL clients cover a ton of the functionality—so much so that you're more concerned about the basic concerns you're already familiar with: doing stuff with your data. The server has the inverse problem. A GraphQL server library covers the low-level part of breaking down the query into actionable slices, but how you resolve those is more of an open-ended problem. And because there's such a variety of ways you could be fetching that data, it's hard for the server library to steer the implementer in any one direction. Every server is going to be vastly different, while every client is going to use very similar patterns.

adamkl 8y ago
Very true. In our case, we resolve queries against some pretty old legacy SOAP/XML services, so topics like selectively loading fields from databases and dataloaders don’t enter into our equations. I thinks it important to remember that GraphQL should form a very thin layer of an application stack. I gave a 4 hour intro lesson at my employer and the bulk of it was not GraphQL, but how we resolve GraphQL against our specific backend data sources.