Are there any plans to release the Relay (client side) component of this?
Joe Savona says August.
GraphQL Working Draft
61–70 of 71 posts
Re: GraphQL Working Draft
#62I've been looking forward to this! One question; it appears as though the types and schema are passed with every request (eg https://github.com/graphql/graphql-js/blob/master/src/graphq... ) -- I assume part of the reason for this is versioning/sharing the schema, but is it always external, does the server ever know the schema a priori -- what's the thinking around this design decision? (It's a plausible idea! I'm ju…
Perhaps that code is a bit misleading. The schema itself is defined and provided by the server. The idea being that a server would build up it's type definitions, and then call into graphql's executor providing both the schema the server defined (in code) as well as the query the client provided (as a network request)
Re: GraphQL Working Draft
#63Earlier quoted context omitted.
I'd suggest that you be wary of going down the route of making your API too flexible. It becomes very difficult to scale up a service that provides flexibility. Imagine a simple case where you're storing hundreds of records of users, and providing the flexibility to order by any field on the user, and of course, you're paginating those results. Now, scale up; you're storing tens of millions of those same record... ho…
> Imagine a simple case where you're storing hundreds of records of users, and providing the flexibility to order by any field on the user... You don't have to allow ordering by any field. You can define a list of fields that you can order by, and only allow those. I don't see the problem with doing that. But if you must allow ordering by any field... > Did you just create database indexes to support each of those us…
This is a great sum-up of a point I often find myself making a lot when explaining GraphQL. GraphQL is only capable of doing exactly what the server-side developer lets it. Order-by is a really great example. We can sort by only the things that make sense to sort by, and often at Facebook we're sorting by heuristics like "sort my friends by how likely I am to send them a message" when loading the friends in a typeahead for chat, and this idea of "message send likelihood" is not exposed as a field.
Re: GraphQL Working Draft
#64How does this fit in/differ from Netflix's Falcor? https://twitter.com/falcorjs
They are attempting to solve similar problems: describing data needs on a client in a way that integrates well with how the data is used, and fulfilling those requirements efficiently.
Falcor uses some different primitives to accomplish the task, focusing on connecting together Observables, whereas GraphQL queries are written in a small query language.
Falcor is a super interesting project and we've gotten to swap notes a couple times.
Re: GraphQL Working Draft
#65I've been looking forward to this! One question; it appears as though the types and schema are passed with every request (eg https://github.com/graphql/graphql-js/blob/master/src/graphq... ) -- I assume part of the reason for this is versioning/sharing the schema, but is it always external, does the server ever know the schema a priori -- what's the thinking around this design decision? (It's a plausible idea! I'm ju…
It's passed to that function in the reference implementation, but a server would probably create a helper function that runs a query for a particular schema. For example, you can just pass a query to Facebook's GraphQL endpoint (without specifying a schema), and it will run the query on the Facebook schema.
This is also reasonable; but an example of how schema get created and discovered by a client would be a nice extension to the spec. :)
Re: GraphQL Working Draft
#66Why not have the query in JSON? Now you need a new parser. EDIT: Thanks for all the replies, all of them very good points, and clearly show that JSON is not the most elegant option for a complex DSL.
It's sad that you capitulated. I agree with your original point more. Is this thing really flexible, composable, and implementable? How long do we have to wait for people to provide solid implementations on top of all the popular programming language and database backends? Feels like SQL all over again. Someone will be writing layers on top of this in javascript in the frontend and ruby/python/javascript/etc. in the backend. Then we are in another ORM hell. (Perhaps I am being too pessimistic here, it could very well be great, but I have some serious reservations...)
Re: GraphQL Working Draft
#67How does this fit in/differ from Netflix's Falcor? https://twitter.com/falcorjs
They are attempting to solve similar problems: describing data needs on a client in a way that integrates well with how the data is used, and fulfilling those requirements efficiently. Falcor uses some different primitives to accomplish the task, focusing on connecting together Observables, whereas GraphQL queries are written in a small query language. Falcor is a super interesting project and we've gotten to swap no…
Awesome, thanks. I watched the Falcor presentation and had my mind blown; looking forward to a similar explanation of GraphQL.
Re: GraphQL Working Draft
#68Why not have the query in JSON? Now you need a new parser. EDIT: Thanks for all the replies, all of them very good points, and clearly show that JSON is not the most elegant option for a complex DSL.
MongoDB did JSON queries. After having useed it I don't think it's a good idea at all.
Re: GraphQL Working Draft
#69Earlier quoted context omitted.
I think you mean falling back to "FQL," the old SQL-like syntax, since Flux is more of a client architecture thing (paired with GraphQL). FQL has some holdouts in legacy code, but the vast majority of the iOS app is using GraphQL. There are a bunch of tools built around using it, and it's the "right way" these days. Maybe a year or more ago ago, the notifications tab was using FQL. It makes sense to convert things si…
I think the OP meant Flux. I also read about it being used to store things that are not being persisted.
Fair enough. In that case, yeah, GraphQL is about the server communication and doesn't specify a particular application architecture. There's usually some data you want saved locally and not persisted to the server, though that's not very common in facebook, since eg preferences are meant to work across devices.
Re: GraphQL Working Draft
#70Lee Byron is talking about it at React Europe right now, here's the live stream (which supports play back): https://www.youtube.com/watch?v=UclvvqNtNNo