GraphQL has a very specific cross-functional advantage: it provides a spec for data access, to cut down novel design (of APIs) by backend and frontend. If Back

GraphQL has a very specific cross-functional advantage: it provides a spec for data access, to cut down novel design (of APIs) by backend and frontend. If Backend have few data entities, or the requirements are extremely clear, your team is not likely to get the full spectrum of benefits. If you have a large number of existing Backend data entities, or expect a large number to be created - GraphQL is a very handy spec. But if the Frontend/Product are EXPLORING how use the data, and unsure exactly how to best utilize the data types, OR they are supporting many permutations of APIs, GraphQL is a game changer. Write a python decorator to generate resolvers... - and BOOM, Backend and Frontend will never have to negotiate over a rigid & novel API contract again. The other stuff, like introspective documentation, sophisticated Frontend state management, and so on are great conveniences, but are not the point. As far as HTTP2 and Frontend goes, I'm excited as it solves a fundamental networking problem. And theoretically saves us from having to bundle. But this is not what I personally consider a big Frontend problem. In most large webapps with network-connected components, you don't want each component to make a discrete network call and pump its data straight into the component. Often you will want to use the response and update a global state, to ensure nothing is out of date. This encourages you to colocate your network logic, with some facilities for this. The GraphQL ecosystem ticks this box. Additionally network requests are a complicated flow, due to APIs having different semantics, needing to shunt value objects through promise/callback chains and the need to covering various edge cases. This encourages codification of network logic, which again, GraphQL does a great job of. This is of course quite complicated stuff, and if you don't need the Frontend magic - you can just put your GraphQL query on a fetch, and use it like a REST endpoint. And of course - if you don't really need the spec, I'd say think very hard before adding GraphQL. That said, big fan of HTTP2 (although last I looked, the perf envelope created by plotting no. of connections against speed, the shape told me "don't rely on this yet").