Hacker News Reader

Comment by drdaeman | Hacker News Reader

Bleeding edge may look really charming, but it's really easy to get a cut.

It has a lot of niceties and advantages over traditional REST-like APIs, but... Last time I've looked (just a few months ago), the libraries weren't exactly mature-looking, e.g. prone to n+1 queries issue.

Good thing is, there are a lot of people who can experiment and improve things. Sad thing is, if you aren't such lucky, GraphQL may be not exactly something you'd want today.

View on HN

In a typical client-server application, regular ol' REST is also vulnerable to the N+1 problem. Only difference: it's N+1 network requests, which introduces a worse user experience than N+1 database queries (or whatever you use to define your GraphQL resolvers).

Your argument is basically fear, uncertainty and doubt. Any concrete points?

> Last time I've looked (just a few months ago), the libraries weren't exactly mature-looking, e.g. prone to n+1 queries issue.

This point seems perfectly concrete.

the n+1 comes from the execution module of the reference implementation if you use the "default/simple" logic. But this is just a reference/general purpose implementation. No one said you can not create smarter resolvers that inspect the AST or even create your own execution module. It's possible :) and it works.

Indeed - but there's very little in the way of good examples on how to do that effectively and in a resilient manner, last time I checked.

I find this strange, because this has been a solved problem with graphql-js for about 18 months now, and provided as a core feature in other implementations such as Sangria in Scala. I've written about this particular problem, calling out solutions that exist in different languages:

https://dev-blog.apollodata.com/optimizing-your-graphql-requ...

The ecosystem is rather new, but the folks from Apollo have been doing amazing work. Between graphql-tools, graphql-server and Apollo Client most of the big chunks are done for you. (including very bleeding edge stuff like subscriptions)

The one big unsolved issue right now is Authorization, i.e. how do you handle permissions? (everything else, like authentication, you can handle with the server itself or there's tooling for it)

I'm collaborating with the Apollo folks on some possible solutions, if you're interested read this issue and chime in: https://github.com/apollographql/graphql-tools/issues/313

So, been thinking about this one for a couple of years and think it's probably a mistake to make GraphQL responsible for permissioning for anything other than a quick MVP. It's a concern that should pervade your stack rather than being "decloaked" at the outer edges. It's the responsible for your underlying data layer to determine what a user permitting user is allowed to do. Additionally, there are many approaches to permissioning that exist for good reasons, and appearing to bless one approach would feel short-sighted.

I agree that there are reasons you may want GraphQL to handle permissions initially, but much like libraries that map your types to database table, it'll be a solution you walk away from quite early on. It'd feel strange for it to be built into graphql-tools itself, which is concerned with building an executable schema, but I could see it being a relatively useful library that's essentially just a bunch of resolver decorators.

You are definitely not wrong. In our case the benefits have far outweighed the harshness from the bleeding edge. But for sure we have had to do a thing or two that I would rather not. Adding auth into graphQL, extending built in type classes are examples.

Reply on news.ycombinator.com