The GraphQL stack: How everything fits together
&gt; GraphQL knows all of the data requirements for a UI component up front, enabling new types of server functionality. For example, batching and caching underlying API calls within a single query becomes easy with GraphQL.<p>And immediately after that the article spends two pages of text explaining how insanely complex the &quot;becomes easy with GraphQL&quot; really is, and offers no actual details on the &quot;easy&quot; part.<p>Oh, your client has to be cache aware. Oh, and there has to be a gateway that&#x27;s cache aware, and schema aware, and has to cache all responses... And invalidate them... But there are no tools yet. And then the graphql server should be cache aware. Oh, and your database layer should also cache all responses.<p>Caching is a hard problem, and there&#x27;s nothing in GraphQL to make it easier. Heck, exclusively relying on POST requests they deliberately remove the most obvious and the easiest part of the equation.<p>I love how the every next part, starts ,with a sentence that shows how complex caching with GraphQL is (emphasis mine):<p>&gt; With GraphQL, frontend developers have the capability to work with data in a much more fine-grained way than with endpoint-based systems. <i>They can ask for exactly what they need, and skip fields they aren’t going to use</i>.<p>I would love to see an explanation how GraphQL makes caching for this easy.<p>&gt; Schema stitching is a simple concept: GraphQL makes it easy to combine multiple APIs into one, so you can implement different parts of your schema as independent services. These services can be deployed separately, written in different languages, or maybe even owned by different organizations.<p>It&#x27;s called REST APIs and we&#x27;ve known how to do them since 2001.