Yes, this does make instrumentation and rate limiting harder, but not impossible. It’s akin to using SQL... sometimes the query optimizer does weird things, but declaratively asking for your data is much better than imperatively pulling and joining it yourself.
Why? This is always my chief complaint about GraphQL: there is no reason it should take fewer trips than directly hitting an endpoint unless you're structuring everything very rest-y in which case you're doing it wrong and GraphQL is a bandaid (and you'd still probably make the same amount of trips unless you're heavily caching things). IMO.
> 2. Clients only download the data they need.
Most third party APIs let you specify what fields you want via a query string or post variable which amounts to the same thing.
Honestly I think if people stopped trying to force REST into everything and just made RPC like calls to HTTP we'd have far less of a need for GraphQL.
Don't get me wrong, I still think GraphQL is pretty cool for third party access in some respects but I don't think it's as useful as a lot of people make it out to be.
Not really. The type of API where you specify what you want and the API itself included whatever data you need in an RPC fashion has been around for decades, I feel weird calling it a "graphql api".
Ultimately GraphQL gives you some tools. The developer just has to figure out if those tools make up for the additional overhead (processing, size, training, etc). Sometimes it'll be justified I just think more often then not it really isn't.
You can roll your own version of the concept, but why bother when a perfectly serviceable one already exists? With already written client & server implementations in your language of choice?
GraphQL is indeed not a new invention. It's a standardisation of existing ideas, that has been given a particular name, and a whole community of people who are building tooling around it.
If you tell me you are using/implementing GraphQL then I immediately know what to expect. I know which tools I can use, I know you have a schema, I know I can run queries and the syntax of those etc. But if you tell me that you are using a REST/HATEOAS/RPC with some particular query syntax then I first have to spend a day reading through the documentation to understand the API.
i think you're giving graphql too much credit, and give too little to REST.
The schema of graphql is going to require just as much reading up and domain knowledge as the REST api.
The great thing here is that you don't have to anymore - you automatically support them all (or close to). And if it saves you from writing and documenting each of those new endpoints, that's a win at least in development time for me.
In most cases a thoughtfully designed REST API built according to HATEOAS shouldn't exhibit these problems. I've seen too many teams with a flawed understanding of both viewing GraphQL as some kind of silver bullet. Instead of stopping to consider their architecture they just rush out and implement GraphQL only to find themselves having significantly worse performance issues than they were having before.
user {
groups(first: 10) {
posts(first 1) {
content
author {
name
address {
state
}
}
}
}
}
/user
/user/12/groups?limit=10
/groups/34/posts?limit=1
/posts/56
/users/78
/users/78/address
/top_posts_view
I don't understand from the description "a thoughtfully designed REST API built according to HATEOAS" what your proposal to solve this problem is.
I'd have concerns about writing business logic in resolvers. If I was using it with a single SQL db I'd probably write a separate non-GraphQL layer for business logic and keep the resolvers thin.
For example, let's say you have have two endpoints /albums/1/ and /users/2/ and want to query them both at the same time.
They're unrelated data, so following REST best practices would make them separate endpoints.
With GraphQL, they're seperate resolvers but you can write
{
albums { get(id: 1) { .... } }
users { get(id: 2) { .... } }
}
GraphQL can do it, but I don't think that's a big strength, compared to the dependent queries it can do. Using the results from one query to drive a further query without going back to the client will save a bunch of time if the client is far from the server.
I do agree though with your point about dependent queries, though I have only used GraphQL for internal apis so my experience doesn’t include that sort of problem.
Unless you’re building one giant graphql enpoint exposing your whole database ?