Right. Regardless of how you go about doing things, if a UI is going to compose more than one kind of resource (which in reality is pretty much every UI), there's going to be some kind of n+1 problem hidden in there somewhere -- unless you go down the route of building a bespoke endpoint per screen or operation, which isn't the worst thing in the world, but it's not the work I want to spend my time doing when building products.
What GraphQL essentially gives you is a mechanism for providing a specification and getting back an endpoint, either fully dynamically at runtime, or at build-time if using persisted queries.
Comments
Right. Regardless of how you go about doing things, if a UI is going to compose more than one kind of resource (which in reality is pretty much every UI), there's going to be some kind of n+1 problem hidden in there somewhere -- unless you go down the route of building a bespoke endpoint per screen or operation, which isn't the worst thing in the world, but it's not the work I want to spend my time doing when building products.
What GraphQL essentially gives you is a mechanism for providing a specification and getting back an endpoint, either fully dynamically at runtime, or at build-time if using persisted queries.