What do you think?
What about Falcor? Falcor: One Model Everywhere
Falcor is the innovative data platform that powers the Netflix UIs. Falcor allows you to model all your backend data as a single Virtual JSON object on your Node server. On the client you work with your remote JSON object using familiar JavaScript operations like get, set, and call. If you know your data, you know your API.
Falcor is middleware. It is not a replacement for your application server, database, or MVC framework. Instead Falcor can be used to optimize communication between the layers of a new or existing application.
Personally I am not a fan of FB so tend to steer clear of anything it puts out (I also think much of their ātechā would become abandonware at their whim).
while REST is designed to act in a similar fashion to the semantic Web - allowing us to have agile, changing, and versionless APIs
It seems to me that REST is almost the opposite of this. If a REST API needs to change, you have almost no way to know if it breaks clients of that API, as a result you generally see REST APIs get poorly versioned in the wild.
note, GraphQL does support multiple content-types as well, although JSON is listed as the preferred format - a preference that REST avoids
Iāve literally never seen a rest API that was anything other than XML or JSON, except for the odd text blob.
one thatās lost in GraphQL is HATEOAS
Iāll grant that Hypermedia is nice but, is it really that bad to us a client API is your data querying patterns arenāt by nature restful?
but in the strict sense of being tightly coupled to the serverās architecture and underlying models
No it doesnāt. GraphQL doesnāt force you to serve straight database tables any more that REST does or doesnāt.
The article also totally ignores the use case of api discovery which GraphQL greatly facilitates.
GraphQL is great if you need to pull tree or graph shaped data in one call. REST is great if you want single resources and really low complexity. You can also do both.
1 Like
So weāre two, Iām totally going to check Falcor! Never heard about it before!
Iām particularly encourage with doing both. 
Doing common REST JSON API by default makes you more resource focused, which is good when youāre starting something new.
But is very common to, while your app grows, have some very complex structures that will be nice to dispose with just one API call. Thatās where GraphQL-like ideas comes into play!
1 Like
I hate FB also. A lot. Canāt stand the pictures of that pimply Zuckerberg (am I going off topic and too far moderator, should I cut out everything that looks like an emotion?). But I have an amoral approach. Good techniques have been found out to produce evil, and good lateron. As byproduct letās say. Nature is immoral.
Btw I have not much looked into graphql myself, Iām just a bit mistrusty upfront with every hype + there is at least absynthe here. Iām afraid that I will have to think about this myself sometime. Iām a bit lazy. 
3 Likes
3! 
Grrr, nice. Thanks for your input.
Iām no fan of their business, but the tech thatās widely used is solid, and has broad community participation. If they axed React tomorrow, thereās still alternative implementations in Preact, Inferno, and a few others. GraphQL has an alternative in Apollo. I think if the tech is good, itās ok to use it.
2 Likes
I think @akitaonrails sums things up well on his blog:
Fragmentation is no stranger to the Javascript world. But itās a different kind of value generation. Facebook, Google, Microsoft, they all want to be the thought-leaders in the fast evolving Millenials generation. Itās a long term strategy. And one of the elements of this game is the Browser. But not only in terms of Chrome vs Firefox vs IE, but also on how applications are implemented.
Facebook came up with React. Google came up with Polymer and Angular. The Node guys went through a power struggle with Joyent which almost resulted in further fragmentation but they settled for the Node Foundation.
Apple went all on war against Adobeās Flash and then only now Google is turning them off in Chrome, but they are all looting on the consequences for all the attention it brings in the Web Development communities.
Apple wants native to succeed and Swift to be the one language to lead it all. Google has conflicting strategies because they want native Instant Apps to succeed but if it fails, plan B continues to be for them to dominate HTML5/CSS3 based web apps with Angular. Facebook donāt want to have their fate being decided by the power struggle between Apple and Google.
Itās a complex power struggle unfolding, and you can see that itās not about technical prowess, itās not about value generation. Itās about ego, influence and power. Very fitting for the YouTuber generation. And the web technologies are being held hostage in this siege, if you haventās noticed.
2 Likes
Whooooooa! Thatās a huge statement!! Totally explain all the thoughts I have but couldnāt express well. Thanks @akitaonrails. I think youāre totally right.
2 Likes
GraphQL is literally just a spec, a detailed description of a data fetching technique. Anyone is free to build their own implementation of that spec. No one is ācontrollingā anything. https://facebook.github.io/graphql/
3 Likes
And god forbid different companies develop different approaches to solve hard problems (for themselves).
1 Like
I just donāt buy Akitaās presupposition that competing technologies are a bad thing, or somehow a slur against the ecosystem. We are all after all here in a form for yet another server language. I firmly believe that the competition is good and sorts the good ideas from the bad. The marketplace for ideas has chosen React and Angular 2 for complex client side frameworks for the time being. They may only be a local maximum, but new ideas are a great thing. If php and java folks hadnāt jumped ship to Ruby 10 years ago, there would be no Akitaonrails.
Coming back on topic, I view GraphQL this way as well. It is a competing idea that will have to live or die in the marketplace of mindshare and ideas.
I agree that competition is good, but Iām suspicious of the motives and sentiment behind some of those companiesā decisions.
4 Likes
The GraphQL is just an another tool in your tool belt from which you choose what fits best for your project. As far as I know it was developed by FB mainly to solve their problems with bad network speeds and high latencies. Instead of multiple requests to retrieve related data, the GeaphQL lets them fetch what they need in a single request. I havenāt chosen the GraphQL for any of projects Iāve been working on. It wouldāve added more complexity than benefit. Typically I design a special endpoint to retrieve properly shaped JSON payload for the UI (or whatever consumer) needs. This is relatively easy with Phoenix templates.
1 Like
As much as I hate, like really really hate Facebook as a company, their devās are awesome people and I speak with them on an almost daily basis in group chats. The code they put out they have to fight to get out. As much as I do not like Reactās design and think it is flawed, it itself has no ties to Facebook whatsoever and indeed has been forked a number of times now. Same with Flow and ReasonML and GraphQL and even their JSX engines. GraphQL is really just defined as a spec, similar to SQL, to allow doing ācallsā to a remote web service in as few requests and as constrained as possible while being open to change in the future (that REST cannot support) while also being entirely introspectable (REST definitely does not do in any standard form). The introspectability and built-in documentation and the fact it minimizes round-trips (unlike the incredibly verbose REST styles) is a major boon. I actually have not even exposed GraphQL to a front-end yet, but I use it in the backend of my project to generate reports, get data, all through a nice and unified interface that I could easily use remotely or from other languages or more, it is quite a nice setup and has no dependency on Facebook or anything they make. 
6 Likes
As for that article, wow I rarely read an article so wrongā¦ >.>
1āGraphQL does not offer information hiding
Uh, GraphQL is mostly like an RPC except you can customize what you send and what you receive. The:
By design, a developer who integrates against GraphQL needs to know the names of the fields to access, their relation to other objects and when to retrieve them.
is entirely wrong. The calls in my system are not direct database calls, not a single one, but rather call in to modules to do work and get results back. There is not field access, there is no needing to know relation to other objects, it is use like ācalling a functionā and stating that you want the result to be in āsuch n suchā format, and you get back a very nice and descriptive error if the server cannot fullfill the format you want, which means you do not introspect the API to see āhowā it could work first, it is self-descriptive with documentation, unlike REST in which you may never know what format you get it back in, no documentation in the system, no introspection, no knowing what is optional and may not be sent back or knowing what to send in the first place.
Why is the number 1 section talking about GraphQL like it is SQL, it is nothing of the sort, it is much more like RPC with a definable return type.
Thinking about it, it seems more like a modernized ASN1 spec, which I am entirely for considering the utter hell ASN1 is. ^.^;
It also creates a strong coupling between the API provider and all its clients. If the data model changes in some way, all the API clients will have to update their code in numerous places. This could very easily be avoided if GraphQL provided a way to version requests, but it doesnāt.
Uh, what? GraphQL does not depend on the data model at all, you can change the back-end data model all you want and can keep your calls the same. And versioning is as simple as just adding a version="blah" binding to the call if you do not want to default to the latest (for the pattern I use).
2āGraphQL is not versioned
Oy, I just spoke of thisā¦ It is as versioned as a, well, ASN1 call is, or a REST call with a query argument, or whatever you wish. I have a version field on my endpoints that just defaults to 1.0.0 and I bump it up as semver for each update, it is pretty trivial to doā¦
3āGraphQL responses cannot be safely cached
Also, uhhh wut?
Have they not seen Relay? It is aside the spec that adds to the spec more abilities, one of those is indeed caching via trivial key lookups, it is fantastic and adds all sorts of abilities in regards to that.
This article seems like it was made by someone whoās never implemented a GraphQL endpointā¦ >.>
9 Likes
I donāt have nothing against GraphQL as it open spec, and there are many implementations.
GraphQL is some kind of BFF https://www.thoughtworks.com/insights/blog/bff-soundcloud
Only one drawback , there is no real time update.
I would like to define query and if data was changed on server side I would get update without asking.
I personally like PouchDb <ā> Couchdb sync model.
https://pouchdb.com/
1 Like
/me coughs: http://graphql.org/blog/subscriptions-in-graphql-and-relay/
Absinthe for Elixir is in the process of adding support for it right now too (already supports the Relay spec too)! ^.^
4 Likes
Yeah, the most generous thing I can think to say about it is that the author clearly hasnāt done a lot with GraphQL. Or read much of the spec. Or used a tool like GraphiQL to explore an API.
Everything else I was going to say, you already said.
1 Like
