<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><parent_chain><item><author>hansonkd</author><text>Its gross because it is a waste.&lt;p&gt;An engineer had to spend time to make that specific API for that page instead of the frontend consumer using what was already defined and get all the resources with one call and 0 backend engineer needed for that new page.</text></item><item><author>ComputerGuru</author><text>&amp;gt; With internal REST for companies I have seen so many single page specific endpoints. Gross.&lt;p&gt;Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page&amp;#x2F;widget&amp;#x2F;dialog of one app. It’s the nature of things at times.</text></item><item><author>hansonkd</author><text>REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them.&lt;p&gt;Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don&amp;#x27;t want to have to create a backend ticket to add related resources to a call.&lt;p&gt;With internal REST for companies I have seen so many single page specific endpoints. Gross.&lt;p&gt;&amp;gt; There have been different opinions about structuring REST calls but those aren&amp;#x27;t going to cause any real forward progress for the industry and are inconsequential when it comes to business outcomes.&lt;p&gt;You could argue almost any tech solution in a non-pure tech play is largely in consequentially as long as the end goal of the org is met, but managing REST APIS were a huge point of friction at past companies.&lt;p&gt;Either it goes through a long review process to make sure things are structured &amp;quot;right&amp;quot; (ie lots of opinions that nobody can sync on) or people just throw up rest endpoints willynilly until you have no idea what to use.&lt;p&gt;GraphQL is essentially the &amp;quot;Black&amp;quot; for Python Syntax but for Web APIs. Ever seen engineers fight over spaces vs tabs, 8 vs 4 spaces, whether a space before a colon? those fights happened a lot and then `black` came out and standardized it so there was nothing to fight over.&lt;p&gt;GraphqL makes things very clear and standard, but can&amp;#x27;t please everyone.</text></item><item><author>matt_s</author><text>&amp;gt; RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.&lt;p&gt;REST API&amp;#x27;s are a proven solution for the problem of other apps, including front-ends, needing data from a data store. Using JSON is much improved over the days of XML and SOAP. Beyond that there haven&amp;#x27;t been advancements in technology that cause fundamental shifts in that problem space. There have been different opinions about structuring REST calls but those aren&amp;#x27;t going to cause any real forward progress for the industry and are inconsequential when it comes to business outcomes.&lt;p&gt;There are so many developers out there that can&amp;#x27;t stand plugging in proven solutions to problems and just dealing with the trade-offs or minor inconveniences. Nothing is going to be perfect and most likely a lot of the software we write will cease to be running in a decade.</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><author>pavel_lishin</author><text>On the other hand, it may take that engineer less time to create a page-specific endpoint than it would be to create something more generic that might serve other purposes (that may never come to pass), which may also involve talking to other teams, checking what future plans are, etc.&lt;p&gt;And that&amp;#x27;s assuming it&amp;#x27;s a new endpoint; if there&amp;#x27;s an existing endpoint that does &lt;i&gt;almost&lt;/i&gt; what&amp;#x27;s necessary, they may need to check in with that team about what modifications to the endpoint would be acceptable, etc.&lt;p&gt;Single-page endpoints aren&amp;#x27;t &lt;i&gt;great&lt;/i&gt;, but often times they&amp;#x27;re acceptable because they end up being a half-day task instead of a week-long slog.</text></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><parent_chain><item><author>hansonkd</author><text>Its gross because it is a waste.&lt;p&gt;An engineer had to spend time to make that specific API for that page instead of the frontend consumer using what was already defined and get all the resources with one call and 0 backend engineer needed for that new page.</text></item><item><author>ComputerGuru</author><text>&amp;gt; With internal REST for companies I have seen so many single page specific endpoints. Gross.&lt;p&gt;Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page&amp;#x2F;widget&amp;#x2F;dialog of one app. It’s the nature of things at times.</text></item><item><author>hansonkd</author><text>REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them.&lt;p&gt;Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don&amp;#x27;t want to have to create a backend ticket to add related resources to a call.&lt;p&gt;With internal REST for companies I have seen so many single page specific endpoints. Gross.&lt;p&gt;&amp;gt; There have been different opinions about structuring REST calls but those aren&amp;#x27;t going to cause any real forward progress for the industry and are inconsequential when it comes to business outcomes.&lt;p&gt;You could argue almost any tech solution in a non-pure tech play is largely in consequentially as long as the end goal of the org is met, but managing REST APIS were a huge point of friction at past companies.&lt;p&gt;Either it goes through a long review process to make sure things are structured &amp;quot;right&amp;quot; (ie lots of opinions that nobody can sync on) or people just throw up rest endpoints willynilly until you have no idea what to use.&lt;p&gt;GraphQL is essentially the &amp;quot;Black&amp;quot; for Python Syntax but for Web APIs. Ever seen engineers fight over spaces vs tabs, 8 vs 4 spaces, whether a space before a colon? those fights happened a lot and then `black` came out and standardized it so there was nothing to fight over.&lt;p&gt;GraphqL makes things very clear and standard, but can&amp;#x27;t please everyone.</text></item><item><author>matt_s</author><text>&amp;gt; RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.&lt;p&gt;REST API&amp;#x27;s are a proven solution for the problem of other apps, including front-ends, needing data from a data store. Using JSON is much improved over the days of XML and SOAP. Beyond that there haven&amp;#x27;t been advancements in technology that cause fundamental shifts in that problem space. There have been different opinions about structuring REST calls but those aren&amp;#x27;t going to cause any real forward progress for the industry and are inconsequential when it comes to business outcomes.&lt;p&gt;There are so many developers out there that can&amp;#x27;t stand plugging in proven solutions to problems and just dealing with the trade-offs or minor inconveniences. Nothing is going to be perfect and most likely a lot of the software we write will cease to be running in a decade.</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><author>RVuRnvbM2e</author><text>That backend engineer wrote a single SQL query that joined some tables, ensured indices were used, and always executed in &amp;lt;1ms.&lt;p&gt;In graphql land you&amp;#x27;d be doing multiple SQL queries, &amp;quot;joining&amp;quot; in the API layer, and spending 50ms per API call.</text></comment>