<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>barrkel</author><text>If you have separation between front and back end, then the back end team can elect to serve REST APIs which only permit selecting, filtering, grouping and pagination that they know they can support within defined latency bounds for a given traffic level.&lt;p&gt;Thing get more problematic when there&amp;#x27;s vertical ownership for a feature, where the UI needs just a few extra things and you end up with a REST response which is fatter and fatter, in the interest of avoiding round trips and client-side joins.&lt;p&gt;The problem with killing correct queries that take too long is that it shows up as intermittent failure that&amp;#x27;s dependent on server load and data cardinality. You might not find it in testing and it ships a bad experience to the customer before bugs are found. Whereas APIs which can&amp;#x27;t be so easily misused make it much harder to ship bugs.</text><parent_chain><item><author>strken</author><text>I&amp;#x27;m not sure this is any more or less of a problem for REST APIs. &lt;i&gt;What if your engineers change $client&amp;#x2F;$server and the new version makes really expensive queries?&lt;/i&gt; Well, ask them not to do that, then when some of them inevitably ignore you, start to review their code, terminate long-running queries, batch or pool fanouts so they don&amp;#x27;t take anything down, monitor new releases and roll back if anything breaks, etc.&lt;p&gt;If you&amp;#x27;re providing an external API like GitHub does, then that&amp;#x27;s a different story and I agree.</text></item><item><author>BiteCode_dev</author><text>The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming.&lt;p&gt;That&amp;#x27;s a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the  less you can actually map the cartesian product of all request params.</text></item><item><author>DanielHB</author><text>GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything.&lt;p&gt;It allows teams to work with less communication overhead. It solves more of a human problems than a technical problems, if someone think there is no value in that and bare metal performance is paramount that person never worked in a big org.&lt;p&gt;&amp;gt; RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.&lt;p&gt;In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple.&lt;p&gt;Unfortunately GraphQL way of working is very different from normal REST APIs and often requires more complex server-side caching. The N+1 problem needs to be figured out upfront for every data-storage system used in the backend.</text></item><item><author>atsjie</author><text>Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article.&lt;p&gt;In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That&amp;#x27;s where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time debugging, this is true for any codebase.&lt;p&gt;But GraphQL has everything in it to make such problems even harder. And both these projects had clear signs of &amp;quot;learning-on-the-go&amp;quot; with loads of bad practices (especially for the N+1 problem). Issue descriptions were much vaguer, harder to find in logs and performance issues popped up in the most random places (code that had been running and untouched for ages).&lt;p&gt;Fun fact; in both these projects the original devs who set it up were no longer involved. Probably spreading their evangalism further elsewhere.&lt;p&gt;RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.</text></item></parent_chain></comment><story><title>After 6 years, I&apos;m over GraphQL</title><url>https://bessey.dev/blog/2024/05/24/why-im-over-graphql/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>jerf</author><text>There&amp;#x27;s a lot of relevant differences between REST &amp;amp; GraphQL. It is possible to construct a REST endpoint that simply can&amp;#x27;t do any of those things, and such construction is a mid-level developer task at best. For instance, pagination of &amp;quot;all posts ever&amp;quot; is not uncommon, and clients won&amp;#x27;t be shocked to deal with it. GraphQL is enough harder to characterize the performance of that it definitely qualifies as a change in quantity that is itself a change in quality. Hypothetically, both approaches are vulnerable to all the same issues, but GraphQL is far &lt;i&gt;more&lt;/i&gt; vulnerable.</text><parent_chain><item><author>strken</author><text>I&amp;#x27;m not sure this is any more or less of a problem for REST APIs. &lt;i&gt;What if your engineers change $client&amp;#x2F;$server and the new version makes really expensive queries?&lt;/i&gt; Well, ask them not to do that, then when some of them inevitably ignore you, start to review their code, terminate long-running queries, batch or pool fanouts so they don&amp;#x27;t take anything down, monitor new releases and roll back if anything breaks, etc.&lt;p&gt;If you&amp;#x27;re providing an external API like GitHub does, then that&amp;#x27;s a different story and I agree.</text></item><item><author>BiteCode_dev</author><text>The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming.&lt;p&gt;That&amp;#x27;s a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the  less you can actually map the cartesian product of all request params.</text></item><item><author>DanielHB</author><text>GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything.&lt;p&gt;It allows teams to work with less communication overhead. It solves more of a human problems than a technical problems, if someone think there is no value in that and bare metal performance is paramount that person never worked in a big org.&lt;p&gt;&amp;gt; RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.&lt;p&gt;In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple.&lt;p&gt;Unfortunately GraphQL way of working is very different from normal REST APIs and often requires more complex server-side caching. The N+1 problem needs to be figured out upfront for every data-storage system used in the backend.</text></item><item><author>atsjie</author><text>Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article.&lt;p&gt;In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That&amp;#x27;s where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time debugging, this is true for any codebase.&lt;p&gt;But GraphQL has everything in it to make such problems even harder. And both these projects had clear signs of &amp;quot;learning-on-the-go&amp;quot; with loads of bad practices (especially for the N+1 problem). Issue descriptions were much vaguer, harder to find in logs and performance issues popped up in the most random places (code that had been running and untouched for ages).&lt;p&gt;Fun fact; in both these projects the original devs who set it up were no longer involved. Probably spreading their evangalism further elsewhere.&lt;p&gt;RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.</text></item></parent_chain></comment><story><title>After 6 years, I&apos;m over GraphQL</title><url>https://bessey.dev/blog/2024/05/24/why-im-over-graphql/</url></story>