<story><title>How and why GraphQL will influence the Sourcehut alpha</title><url>https://sourcehut.org/blog/2020-06-10-how-graphql-will-shape-the-alpha/</url></story><parent_chain><item><author>WhatIsDukkha</author><text>I don&amp;#x27;t understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you)&lt;p&gt;It seems like exactly the ORM solution&amp;#x2F;problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs.&lt;p&gt;ORM suffer from being at beyond arms length from the query analyzer in the database server.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Query_optimization&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Query_optimization&lt;/a&gt;&lt;p&gt;A query optimizer that&amp;#x27;s been tuned over decades by pretty serious people.&lt;p&gt;Bad queries, overfetching, sudden performance cliffs everywhere.&lt;p&gt;Graphql actually adds another query language on top of the normal orm problem. (Maybe the answer is that graphql is so simple by design that it has no dark corners but that seems like a matter of mathematical proof that I haven&amp;#x27;t seen alluded to).&lt;p&gt;Why is graphql not going to have exactly this problem as we see people actually start to work seriously with it?&lt;p&gt;Four or five implementations in javascript, haskell and now go. From what I could see none of them were mentioning query optimization as an aspiration.</text></item></parent_chain><comment><author>baddox</author><text>GraphQL is quite similar to SQL. They’re both declarative languages, but GraphQL is declaring a desired data format, whereas SQL is declaring (roughly) a set of relational algebra operations to apply to a relational database. GraphQL is really nothing like an ORM beyond the fact that they are both software tools used to get data from a database. You might use an ORM to implement the GraphQL resolvers, but that’s certainly not required.&lt;p&gt;I wouldn’t expect the performance issues to be much more problematic than they would be for REST endpoints that offer similar functionality. If you’re offering a public API, then either way you’re going to need to solve for clients who are requesting too many expensive resources. If you control the client and the server, then you probably don’t need to worry about it beyond the testing of your client code you would need to do anyway.&lt;p&gt;As far as query optimization goes, that’s largely out of scope of GraphQL itself, although many server implementations offer interesting ways to fulfill GraphQL queries. Dataloader is neat, and beyond that, I believe you can do any inspection of the query request you want, so you could for example see the nested path “Publisher -&amp;gt; Book -&amp;gt; Author -&amp;gt; name” and decide to join all three of those tables together. I’m not aware of any tools that provide this optimization automatically, but it’s not difficult to imagine it existing for some ORMs like those in Django or Rails.</text></comment>
<story><title>How and why GraphQL will influence the Sourcehut alpha</title><url>https://sourcehut.org/blog/2020-06-10-how-graphql-will-shape-the-alpha/</url></story><parent_chain><item><author>WhatIsDukkha</author><text>I don&amp;#x27;t understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you)&lt;p&gt;It seems like exactly the ORM solution&amp;#x2F;problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs.&lt;p&gt;ORM suffer from being at beyond arms length from the query analyzer in the database server.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Query_optimization&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Query_optimization&lt;/a&gt;&lt;p&gt;A query optimizer that&amp;#x27;s been tuned over decades by pretty serious people.&lt;p&gt;Bad queries, overfetching, sudden performance cliffs everywhere.&lt;p&gt;Graphql actually adds another query language on top of the normal orm problem. (Maybe the answer is that graphql is so simple by design that it has no dark corners but that seems like a matter of mathematical proof that I haven&amp;#x27;t seen alluded to).&lt;p&gt;Why is graphql not going to have exactly this problem as we see people actually start to work seriously with it?&lt;p&gt;Four or five implementations in javascript, haskell and now go. From what I could see none of them were mentioning query optimization as an aspiration.</text></item></parent_chain><comment><author>kevan</author><text>Seems like you&amp;#x27;re looking at this through the lens of a single system that could submit a query to a single database and get all the data it needs. From that perspective GraphQL is definitely an extra layer that probably doesn&amp;#x27;t make sense. But even then there&amp;#x27;s still some value in letting the client specify the shape of the the data it needs and having client SDKs (there&amp;#x27;s definitely non-GraphQL ways to achieve these too).&lt;p&gt;My impression is GraphQL starts to shine when you have multiple backend systems, probably separated based on your org chart, and the frontend team needs to stitch them together for cohesive UX. The benchmark isn&amp;#x27;t absolute performance here, it&amp;#x27;s whether it performs better than the poor mobile app making a dozen separate API calls to different backends to stitch together a view.</text></comment>