21–30 of 84 posts
I keep hearing people say things along the lines of, "Relay looks great, but I don't want to store my data in a graph". My impression is that GraphQL has nothing to do with graphs, really - it's a bit more like SchemaQL if anything. Could someone from the facebook team clarify about the name?
Are there still problems with GET requests not allowing very much data in the request? Will I have to send this as a POST, or is that all 200x?
If you look at facebook's Relay implementation the graphql queries are indeed sent as POSTs. https://github.com/facebook/relay/blob/master/src/network-la...
Pretty off topic, sorry, but I found it pretty interesting that all of the 9 comments posted here so far have a question in them.
How about optimistic over-fetching? On Facebook it's very annoying to wait earlier comments to load when they are fetched like 10 at a time, and there's 5 second latency on every request. Why not fetch everything with a single request (even when they aren't displayed in the current view)?
Want the specification for graphql already released? Are these just the official announcements, after the technical previews?
https://github.com/lukemurray/EntityQueryLanguage
Super early days as I haven't had too much time on it, and now GraphQL has specs etc. I might support more of it's syntax.
I actually build .NET expression so you can execute things against any LINQ provider - in-memory, Entity Framework, or some other ORM
How about optimistic over-fetching? On Facebook it's very annoying to wait earlier comments to load when they are fetched like 10 at a time, and there's 5 second latency on every request. Why not fetch everything with a single request (even when they aren't displayed in the current view)?
responsibility of the client, no? to dictate how many results to return.
I'm not too familiar how this works, but maybe it's enough to query the additional data in parent component or somewhere and it just works.
Earlier quoted context omitted.
responsibility of the client, no? to dictate how many results to return.
Ugh.. My comment was meant in the Relay thread, but anyway, it sounds like Relay/GraphQL is designed to not fetch anything that isn't actually rendered. In my own SPA apps, I very frequently over-fetch to reduce latency. I was hoping there would be a nice compatible way to manage this use case. I'm not too familiar how this works, but maybe it's enough to query the additional data in parent component or somewhere and…
In an attempt to help resolve this issue, I suggest that you think of it as ProductQL or ProductAPI instead.
It's not a storage layer. It's not really a query language. It's an alternative way to define an API that more closely matches the typical mental and product domains than REST.
It's critical to realize that you're implementing an API. GraphQL does not concern itself with sorting or fetching data as the name might lead you to initially believe. It has little to actually do with graphs (except they are more easily expressed). It is designed to be added on top of your application layer and business logic to provide a single, well defined API for your product and tools.
It primarily targets product developers. From the scheme/API side, it is up to the server developer to decide what to expose and how, based on the product and any technical considerations that need to be made.