I'd check out Apollo for these use cases. They allow a client GraphQL schema to be sourced from a bunch of different places, including (I believe) local-only state, REST APIs, and others. See https://www.apollographql.com/docs/link/links/rest.html
Nick Schrock here, one of the GraphQL co-creators. I agree with a lot of the criticism in terms of the difficulty of implementing GraphQL backends. I think there's a big opportunity for folks to build vertically integrated toolkits that deal with N+1 issues, integrate DataLoader natively and so forth. Good versions of these would deal with a lot of issues described here in greenfield GraphQL backends. I talked about this at the GraphQL Europe keynote last month (https://www.youtube.com/watch?v=zMa8rfXI6MM).
Current greenfield implements are typically stacked on ORMs like Django and RoR, and the impedance mismatch is real. Personally I abide by the dictum that ORMS are "Vietnam of computer programming" and should be avoided at all costs for anything that will grow beyond a small app. GraphQL was not originally implemented on top of an ORM, but instead an object model built on key-value + edge store internal to Facebook.
In terms of other criticisms in this thread:
1) Exceptions: The default behavior in graphql-js (mimicked in other language implementations) of swallowing native exceptions by default was probably a mistake in hindsight. Whenever I've played with GraphQL using different toolsets the first thing I change is to add a wrapper function which checks for errors and then rethrows the initial exception that caused the GraphQL error for use in testing and CI/CD contexts.
2. Caching: Personally I've always been confused about the concern with leveraging HTTP-level caching. While a clever hack, with any real app with any sort of even mildly dynamic behavior you don't want to do this. Staleness will be interpreted, rightly, as bugs by your users. If you want to replicate the behavior the most straightforward way would be to use persisted queries (described here https://blog.apollographql.com/persisted-graphql-queries-wit...) combined with HTTP GETs. With persisted queries you can encode the entire request in the query string, which should get you the HTTP-level caching you want.
3. Docs: Quite confused about this one. While particular implementations of GraphQL can be problematic the documentation of the core language (which I am not responsible for) is superb. See http://graphql.org/ and https://www.howtographql.com/.
Great job. Awesome to see all the focus on documentation and conceptual explanations. Clear messaging and spreading understanding are just as important as the tech.
This is a super exciting release and I'm really excited to see the community go in this direction, specifically the ability to add more sophisticated, custom capabilities to the server. GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics.
It is also surreal to see GraphQL go from the first prototype system I wrote five years ago to where it is today. I'm so impressed with the players in the community and its humbling to see so many people take the ecosystem to new heights.
Congratulations to the whole Graphcool team on this awesome milestone!