schrockn

7 ms·

1.
by schrockn 5y ago
Funny enough this post mirrors quite a bit of our thinking over at Dagster! https://dagster.io/blog/rebundling-the-data-platform
2.
Dagster: The Data Orchestrator(medium.com)
23 points by schrockn 6y ago|3 comments
3.
Dagster 0.6.0: Scheduling and Production Execution/Monitoring(medium.com)
6 points by schrockn 7y ago|0 comments
4.
Bigslice – Go-based, serverless cluster computing(bigslice.io)
16 points by schrockn 7y ago|1 comments
5.
by schrockn 8y ago
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&#x
6.
by schrockn 8y ago
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 tha
7.
by schrockn 9y ago
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.
8.
by schrockn 9y ago
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 serve
9.
by schrockn 11y ago
That sounds awesome. Are you developing this on github? I'd be curious to see what your integration looks like.
10.
by schrockn 11y ago
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 gr
11.
by schrockn 11y ago
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
12.
by schrockn 11y ago
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 ser
13.
by schrockn 11y ago
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. th
14.
by schrockn 11y ago
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.
15.
by schrockn 11y ago
Thanks!
16.
by schrockn 11y ago
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.
17.
by schrockn 11y ago
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.
18.
by schrockn 11y ago
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