[t_fatus]

I'd like to add that correctly designed resolvers allow you: - to control very easily who can fetch what where it's fetched (permissions) - to fetch nested data when you need it without writing serializers - to help your frontend team find what they are looking for without asking the backend team everytime - mutations are a huge plus when it comes to standardization of your API too

FYI we're using it in production over a django backend (which comes with some drawbacks, since subscriptions == pushed updates are not perfectly implemented) with our react/apollo apps (web and native) and in my opinion the overhead lies surprisingly more in the frontend side (writing data connectors is longer, but way more explicit, than using rest queries returning json)than on the backend (where you just declare resolvers, a thing you don't even need to do in nodejs) and handle permissions.

[kej]

>to control very easily who can fetch what where it's fetched (permissions)

This is a piece of GraphQL I haven't been able to get my head around. Could you elaborate or point me to a good explanation of how this is implemented? Everything I found when I looked into GraphQL previously was something like "you control access to individual resources in your business layer" but never explained how.

[sgdesign]

In order for GraphQL to return a result when you ask for field “foo”, you need to define a resolver function for that field. Whatever that function returns will be returned to the client.

Inside that function you can write any code you’d like, including permissions code.

[t_fatus]

as sgdesign said, you can write your own resolver function (which allows you to retrieve a particular field deep in the nested graph of graphql). It's very easy to create decorators to handle the usual permission cased on the field level.

[t_fatus]

One important thing to note: performance-wise, both in front-end when used with apollo, and in backend (you need to handle nested queries smartly) a good implementation of a REST api would probably be faster / lighter, but it should be largely enough for any web-app / web-service used by human beings ;)

[alexchamberlain]

Citation needed; what is your evidence for such an assertion?

[t_fatus]

Graphql and apollo add some overhead to your queries, both in your client and your API. And since you're still performing a POST query with each graphql query it's kinda logical to see that pure / well designed REST can outperformed graphql (if you know exactly what you want to return you don't have to run through the graphql schema / node / resolver to get the value your looking for)