I still love GraphQL, but much of the love comes from using tools like PostGraphile which generates the API for you based on your database schema. I then add my own Javascript plugins as necessary. Going back to REST and hand writing everything gives me the shivers, how much time am I spending just translating data A to data B?
Authorization: I do it in the database using roles, row level security and column level security. It works well and I defer everything to PostgreSQL's security controls, it feels like the right place to do it and I don't have to worry about it going out of fashion, PostgreSQL is here to stay. Anybody else who talks to the database directly is also subject to the same authorization rules, which is nice.
Introspection: this should really be disabled on production services. Only enable it for development.
N+1 problem: I don't really have a problem with N+1 because PostGraphile converts the request into an efficient query. In other cases this problem presents itself in REST too and the article proposes hoisting N+1 queries to the controller, but that's just really moving the problem around, and you can do this with GraphQL too.
The other problems, yeah sure they are present and a worry if you're running some highly visible/very loaded public API.
Agree with this 100%, Postgraphile is awesome. I started a new project recently and was writing “REST” APIs because I’d been reading that people were put off by GraphQL, but it was a complete pain - instead of exposing my data and querying it as needed, I had to try to guess up front what I should expose in what object. It was the bad old days all over again, writing adhoc code on the server to meet the needs of the client… switching back to GraphQL - and postgraphile - was a relief.
As someone who has used GeaphQL extensively, I really don’t understand most of the complaints, which seem like they’d be common to any complex API surface. Sure you can write a query that triggers a server bug, but that happens with REST too. Yes, your server needs to be hardened against these queries… so what?
And security is hard, granular security doubly so. If you need to do field level authorisation then the problem is that you need a policy engine, not a different query technology.
Authorization: I do it in the database using roles, row level security and column level security. It works well and I defer everything to PostgreSQL's security controls, it feels like the right place to do it and I don't have to worry about it going out of fashion, PostgreSQL is here to stay. Anybody else who talks to the database directly is also subject to the same authorization rules, which is nice.
Introspection: this should really be disabled on production services. Only enable it for development.
N+1 problem: I don't really have a problem with N+1 because PostGraphile converts the request into an efficient query. In other cases this problem presents itself in REST too and the article proposes hoisting N+1 queries to the controller, but that's just really moving the problem around, and you can do this with GraphQL too.
The other problems, yeah sure they are present and a worry if you're running some highly visible/very loaded public API.