schrockn's comments

Funny enough this post mirrors quite a bit of our thinking over at Dagster! https://dagster.io/blog/rebundling-the-data-platform

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!

That sounds awesome. Are you developing this on github? I'd be curious to see what your integration looks like.

Hi I'm Nick Schrock and I actually came up with the name. Graph in this context means social graph or more generally the conceptual graph of data in your application, which you can query. It doesn't mean that it is a formalized graph database in any sort of way, nor does it seek to be.

I understand the name causes a bit of confusion but the ship has kind of sailed on this one :-) I think people will get used to it if/when it becomes a widely known name.

That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation.

We model mutations as a function that can do arbitrary business logic followed by a client-specified query where the client can query data it knows must be updated in order for the view to reflection the state changes the mutation caused.

I think given the current state of the spec that's pretty accurate. However we really view GraphQL as the way that front-ends/client specify their data requirements. One way of fulfilling that is to dispatch the queries to the server as is. However if you view this as an API to data, which can include client software, this can get a lot more interesting, and allows you to use different transports, messaging protocols, etc

For example on iOS we used GraphQL to transition our persistence from Core Data to a propriety (client) storage engine.

resolve() takes the current field AST node as one of its arguments. Mappings to more complicated backends will demonstrate use cases of where this is needed. From that field AST you can arbitrarily descend into a ton of information, e.g. the subfields of the current field.

Hi I'm Nick Schrock one of the GraphQL developers at Facebook.

While GraphQL certainly shares some attributes with OData, we believe it is substantially different enough from Data that we aren't simply repeating the same mistakes.

There are a number of differences, but two in particular are striking.

1) Is that the GraphQL language is built with product developers in mind. This is a subjective/qualitative judgement, but we believe that it's just a much more elegant language, and that it is a more powerful platform for tool-building. We hope to prove this out in the coming months as both we and the community build tooling atop the language and the introspection system. 2) GraphQL is more constrained. A OData service has to support a huge number of operations that make it more of a generic querying service, rather than a highly structured way to expose application logic. We agree with you that often cover too much and without adequate performance guarantees.

In terms of complexity on the server side, I think this is a really legitimate question. Our answer is that although there is complexity, it is generally incurred on a much smaller set of core and tool developers. The average product developer who will just need to expose a capability via a GraphQL type and then consume it on the client will not find the system overly complex.

Thanks!

It is absolutely not that simple on the server, but we hope do to a lot of the heavy lifting for you via our open source release of code and spec in terms of lexing, parsing, and executing a query.

That's a great point. We definitely have designed it for first party clients in mind. This doesn't preclude use cases in the future, but for the short term, this is a nongoal.

Re: the risk of overfetching, this is certainly a risk. Like any tool, it can be misused. One of the motivations of Relay is in fact this very issue. By coupling the data-fetching with the view more tightly, we can more accurately track and fix overfetching earlier in the development cycle.

In terms of being not too expensive, an important attribute of the system is that the server publishes capabilities that clients selectively use. For example, we explicitly do not allow clients to send up arbitrary strings for filtering and query predicates and what not; servers have to explicitly expose those via arguments to fields. eventMembers(isViewerFriend: true) { ... } or similar formulations that are encoded in the type system. This prevents people from ordering inefficiently (e.g. large data sets without indexes).

Re: pagination. This is absolutely a core pattern that we are excited to talk about as we explain the system more. Broadly we handle pagination through call arguments, e.g. friends(after: $someCursor, first: 10) { ... } There's a lot of subtlety there which I won't go into until we dive into that topic deeply.