Searched the article for the word "join", no hits. Strange: this is my personal top counter-argument to use GraphQL.
On my current project, we're using Graphana with Postgresql on the server and Apollo on the client. You create a new table in database, click a couple of buttons in Graphana admin panel, and the client now can query those tables, without a single line of code on the server! This part is awesome.
What is much less awesome though, is when you have a normalized database, and entities with many layers of links, and your client can generate GraphQL queries with so many crazy joins that will take your production database 30 seconds to complete — all while accessing public data, with no authentication required. So far, I haven't seen anybody figuring it out to DDoS our server, and every time this happens with real production queries, I get a fun index writing task.
However, just being able to run into database perfomance limitations by writing code on the client seems wrong. There's always going to be weird joins that we won't optimise for, and sooner or later there will be determined DDoSers who will figure it out and will be able to spam our server much more effectively with each query. I'm not yet sure what's the right way to alleviate this problem is, it's just strange that no one is talking about it.
Edit: I think I have been proved wrong by lukeramsden's comment below; or at least I should research this more before having an opinion on this matter.
A good page for this is Postgraphile's "Production Considerations" page [0]. Under "Denial of Service Considerations" it talks about a few solutions, such as statement timeouts, persisted queries, or query analysis. Choosing what to use may be quite project specific but there are available solutions.
Thanks for this! Immediately forwarded it to my team chat, this is incredibly useful. Turns out that they already researched these options and just haven't invested any time in them because it hasn't been a real production issue, so I probably should take my criticism back.
(Author here) If you want efficient database JOINs using GraphQL I'd always opt for Hasura. They've done a fantastic job solving this problem. This will almost always use the most efficient SQL you can get. If you want to extend this Schema you can use something like Schema stitching and you're good to go.
Will hasura also help with the indexes, the most efficient SQL is usually the one which utilizes the indexes properly which still need to be setup to accomodate for each and every client side queries.
Besides hasura would have been great as a library but it's another api server you need to maintain on top of your existing one.
I think it would be a nice feature @tanmaigo should add to Hasura if it's not alredy there. Hasura could automatically detect slow queries and suggest indexes.
That's exactly what I'm using though! And for the most part, it's an awesome tool. But it still can't magically make resulting SQL query faster than it can be without tweaking the database itself.
On my current project, we're using Graphana with Postgresql on the server and Apollo on the client. You create a new table in database, click a couple of buttons in Graphana admin panel, and the client now can query those tables, without a single line of code on the server! This part is awesome.
What is much less awesome though, is when you have a normalized database, and entities with many layers of links, and your client can generate GraphQL queries with so many crazy joins that will take your production database 30 seconds to complete — all while accessing public data, with no authentication required. So far, I haven't seen anybody figuring it out to DDoS our server, and every time this happens with real production queries, I get a fun index writing task.
However, just being able to run into database perfomance limitations by writing code on the client seems wrong. There's always going to be weird joins that we won't optimise for, and sooner or later there will be determined DDoSers who will figure it out and will be able to spam our server much more effectively with each query. I'm not yet sure what's the right way to alleviate this problem is, it's just strange that no one is talking about it.
Edit: I think I have been proved wrong by lukeramsden's comment below; or at least I should research this more before having an opinion on this matter.