3 ms·

And sometimes with nested GraphQL queries it just grind the db to a halt. It may be a good idea to convert it to SQL and optimized it by hand. Great tool. Pe

• praveenweb 6y ago
  In a production app, you would limit the query depth or have an allow-list to prevent arbitrarily nested queries.
  • andrewingram 6y ago
    Back in 2017 when I was doing a lot of work on optimising GraphQL, I briefly looked into how likely it was that a UI would actually end up requiring a query with problematic performance characteristics. The answer seemed to be “not very”. I had to come up with a deliberately contrived UI to find a realistic query that was more than 4 relationships deep. Most were around 3 (though double-nested connections were fairly common within this). The more common problem was around overall data size, where the bottleneck was JSON serialisation overhead and network transfer size. Query whitelisting is the winning approach for 1st party APIs. If you’re opening things up to third parties, e.g. the Github API, complexity analysis becomes the more valuable solution.