<story><title>GraphQL: A Retrospective</title><url>https://verve.co/engineering/graphql-a-retrospective/</url></story><parent_chain><item><author>ergothus</author><text>I haven&amp;#x27;t yet had much luck in finding a GraphQL review that addresses my general concerns (I&amp;#x27;m frontend).&lt;p&gt;1) GraphQL almost always means everything is POST, removing CDN and browser caching of GET-like requests is gone (and ServiceWorker caching just got much more complicated, nigh-impossible if CORS is involved).  Everyone says &amp;quot;oh, clients can do better caching&amp;quot;, as if that&amp;#x27;s not true without GraphQL.  Still, the caching I mention might be trivial and mostly worthless.  I&amp;#x27;d just like to see some actual inspection of the issue.&lt;p&gt;2) The models I&amp;#x27;ve seen work well if your frontend is largely a thin skin over the services with minimal business logic of their own.  (this isn&amp;#x27;t GraphQL directly, but the client libs that use it, but those exist because talking GraphQL without them is more effort). 
 Which is, of course, what we really want.  Business logic in the front end is always a painful idea.  But it also definitely happens, for real business reasons - are we making those cases harder?  How much so?  With REST we have a lot more flexibility, it seems, even if we choose to avoid using most of it.</text></item></parent_chain><comment><author>013a</author><text>The caching story in GraphQL sucks. Its pretty good with frontend frameworks like Apollo, but that&amp;#x27;s not a solution to the whole problem. Sure it works for your website&amp;#x2F;app (if you&amp;#x27;ve got one), but it does nothing to offer caching for a generic API.&lt;p&gt;Its easy to argue that the main advantage of GraphQL is to reduce overfetching fields on the data you need for your views. That&amp;#x27;s a great advantage. But how much of the performance advantage gained from this is offset by the substantially reduced backend cacheability of these requests? I would guess a ton, especially with highly complex views that require lots of database pulls.&lt;p&gt;That isn&amp;#x27;t to say simple caching strategies aren&amp;#x27;t still possible (you can encode GraphQL requests into GETs and just cache that url at the CDN layer, this is part of the spec AFAIK). But when you have an open API serving many users, where you can&amp;#x27;t predict what fields they&amp;#x27;re going to ask for (or even the ORDERING of those fields in their request, which would change the request body despite the response being the same!), this has to be a problem that crops up pretty quick.&lt;p&gt;There&amp;#x27;s no HTTP-level solution to this. I doubt there&amp;#x27;s any solution that would work well enough to be worth implementing. Which leads me to believe that its an intrinsic problem in GraphQL; the more freedom you give clients to request whatever they want, the harder it becomes to guarantee performance for the requests they&amp;#x27;re making. And GraphQL gives clients all the freedom in the world.&lt;p&gt;Oh, and don&amp;#x27;t even get me started about the fact that because GraphQL stitches together essentially depth-unlimited data from your data graph in one request, there&amp;#x27;s no way to express different TTLs on each item returned, on the backend &lt;i&gt;or&lt;/i&gt; the frontend. If you&amp;#x27;ve got data that could TTL for 24 hours, but another piece of data that TTLs for 60 seconds, you essentially have to specify the cache-control to account for the smallest TTL.&lt;p&gt;Overall, I think GraphQL is fine. But I also believe what we&amp;#x27;ll slowly discover is that &amp;quot;Company X&amp;quot; simply fucked up their REST API, then will look to GraphQL to solve all their problems. And it might solve some of them, but then they&amp;#x27;ll have an even more complex system in place with even harder problems. Facebook can solve those problems; us small shops can&amp;#x27;t. Better hope Facebook shares their solutions with the world.</text></comment>
<story><title>GraphQL: A Retrospective</title><url>https://verve.co/engineering/graphql-a-retrospective/</url></story><parent_chain><item><author>ergothus</author><text>I haven&amp;#x27;t yet had much luck in finding a GraphQL review that addresses my general concerns (I&amp;#x27;m frontend).&lt;p&gt;1) GraphQL almost always means everything is POST, removing CDN and browser caching of GET-like requests is gone (and ServiceWorker caching just got much more complicated, nigh-impossible if CORS is involved).  Everyone says &amp;quot;oh, clients can do better caching&amp;quot;, as if that&amp;#x27;s not true without GraphQL.  Still, the caching I mention might be trivial and mostly worthless.  I&amp;#x27;d just like to see some actual inspection of the issue.&lt;p&gt;2) The models I&amp;#x27;ve seen work well if your frontend is largely a thin skin over the services with minimal business logic of their own.  (this isn&amp;#x27;t GraphQL directly, but the client libs that use it, but those exist because talking GraphQL without them is more effort). 
 Which is, of course, what we really want.  Business logic in the front end is always a painful idea.  But it also definitely happens, for real business reasons - are we making those cases harder?  How much so?  With REST we have a lot more flexibility, it seems, even if we choose to avoid using most of it.</text></item></parent_chain><comment><author>xiaomai</author><text>Point 1 wasn&amp;#x27;t a problem for adopting GraphQL for us because our end-points are very dynamic so we set no-cache headers on everything anyway.  That said, clients like Apollo will let you issue GET requests instead of POSTs for queries if you prefer.&lt;p&gt;In regards to point 2: GraphQL definitely doesn&amp;#x27;t make it harder to implement front-end logic.  I&amp;#x27;m not sure how to back up this claim because it&amp;#x27;s not apparent to me why one would think that GraphQL complicates this.</text></comment>