GraphQL Introduction
facebook.github.io
GraphQL Introduction
1–10 of 53 posts
Re: GraphQL Introduction
#2What are the alternatives to using something similar to GraphQL and Relay now? I've found Transmit [0], but what are the other alternatives? Has someone tried to integrate BreezeJS [1]? Also, any news about the upcoming Falcor [2]?
[0] https://github.com/RickWong/react-transmit
[1] http://www.getbreezenow.com/
[2] https://www.youtube.com/watch?v=WiO1f6h15c8
P.S. Also, GraphNoQL [3] came out quickly after the announcement, but there's been no progress ever since.
Re: GraphQL Introduction
#3As an ex-Facebook employee, I can't wait for this to be released to the public. It is hard for me to overstate how much this infrastructure makes building products a joy, not to mention the tremendous developer and server efficiency that can be attained. I miss having the GraphQL stack so much when working on my own stuff.
The client application should drive the decisions about what data to fetch. After all it's the client that knows what it is actually going to be doing with the data, not the server. Current approaches like having a "fields" option on a REST endpoint are at best a hacky approximation to this.
Re: GraphQL Introduction
#4The reasons they list in favour of GraphQL vs REST and Ad HOC APIs are really convincing. Being a developer for an API that powers multiple mobile applications and a website this looks really interesting and would solve a lot of problems we have right now. Unfortunately I know it would probably take too much time to re-implement all our backend and clients to even think about using this in a near future.
Re: GraphQL Introduction
#5As an ex-Facebook employee, I can't wait for this to be released to the public. It is hard for me to overstate how much this infrastructure makes building products a joy, not to mention the tremendous developer and server efficiency that can be attained. I miss having the GraphQL stack so much when working on my own stuff. The client application should drive the decisions about what data to fetch. After all it's the…
I'm curious to learn how API response caching is affected by GraphQL. In a REST setup, there's a possibility that API responses can be cached. But if the response structure is dictated by the client, it seems like responses might differ and not be cacheable.
Re: GraphQL Introduction
#6It's like there's a calculated trickle of info to keep us interested as they prep it for release.
Good job, it works.
Re: GraphQL Introduction
#7Excuse me for being unreasonably giddy but I've been eager as hell for this to be released for a time. I have grown to adore React and React Native and really enjoyed Flux. Facebook dev hitting on all cylinders!
Re: GraphQL Introduction
#8As an ex-Facebook employee, I can't wait for this to be released to the public. It is hard for me to overstate how much this infrastructure makes building products a joy, not to mention the tremendous developer and server efficiency that can be attained. I miss having the GraphQL stack so much when working on my own stuff. The client application should drive the decisions about what data to fetch. After all it's the…
+1. Having gotten used to GraphQL I was shocked how hard it was to build something REST-ish at another org.
Re: GraphQL Introduction
#9If you can't use GraphQL due to some reason then there is an alternate - http://www.getbreezenow.com/breezejs
Re: GraphQL Introduction
#10As an ex-Facebook employee, I can't wait for this to be released to the public. It is hard for me to overstate how much this infrastructure makes building products a joy, not to mention the tremendous developer and server efficiency that can be attained. I miss having the GraphQL stack so much when working on my own stuff. The client application should drive the decisions about what data to fetch. After all it's the…
I'm curious to learn how API response caching is affected by GraphQL. In a REST setup, there's a possibility that API responses can be cached. But if the response structure is dictated by the client, it seems like responses might differ and not be cacheable.
In practice it wouldn't make much sense to cache whole query responses to GraphQL queries because your hit rates would be too low due to the variability of the queries. You end up pushing a lot of the caching to the client. That's not really a big issue because if you're writing something like a Android or iOS app because you already need to be caching lots of data on the client-side to make the app responsive.
On the server you end up caching at lower levels in the stack. For example a query for user(id: 123456) {id, name} is going to need data from a key-value store containing user info. That access can easily be cached with something like memcache, saving load on the database. Cache-invalidation problems are also much easier to solve at these layers.