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/.

1.	Dagster: The Data Orchestrator(medium.com) 23 points by schrockn 5 years ago \| 3 comments
2.	Dagster 0.6.0: Scheduling and Production Execution/Monitoring(medium.com) 6 points by schrockn 6 years ago \| 0 comments
3.	Bigslice – Go-based, serverless cluster computing(bigslice.io) 16 points by schrockn 6 years ago \| 1 comment

user:	schrockn
created:	July 7, 2011
karma:	74