Viewing profile — schrockn

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 …

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 opportunit…

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 se…

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…

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 …

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 ful…

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 yo…

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 …

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 e…

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 …