In my company, we recently had a discussion about falcor and graphql. There were benefits to both sides, but at the end of it, Graphql won out.
Here are some of the reasons why:
- Falcor is not a standard or a language, its a large javascript library with conventions for manipulating data.
- GraphQL on the other hand, is a full blown query language, that is _standardized_. This means, that implementations in other languages (other than JS) will have to follow standards
- GraphQL has a very high rate of adoption, and has many libraries in other languages.
- GraphQL is backed by FB, which has a track record of releasing only things that have been tried and tested.
- That's because Netflix doesn't put any of resources into evangelizing. However it's still a valid point: if Netflix drops Falcor it's dead. I'd argue that if Facebook drops Relay/GraphQL it'd suffer a pretty sharp decline too.
- Falcor is backed by Netflix which has a track record of great open source too. Netflix was using Falcor internally for a long time before it was open sourced: if it can survive at Netflix scale it can survive at your scale too.
I'm not terribly concerned at how quickly people adopt Falcor; by all means adopt the one that suits you and your use cases. I just see a lot of bad reasons and misinformation of why not to adopt Falcor. It's a great library that would benefit a lot of users. It's a joy to consume too as a UI developer.
I think your use of the term "standardization" is slightly out of place here. When you say "standard", I think of something like IEEE 802.3 or FIPS 202.
But what do you really mean by "standardized" in this context? Is there a known consortium of companies that provides its stamp of approval on correct implementations of GraphQL? If not, what prevents me from implementing GraphQL incorrectly in, say, OCaml?
Definitely, but a spec without an implementation is even worse. It's like saying "we're not invested in this idea enough to implement it". Huge red flag in my view.
A standard doesn't `prevent` you from doing anything, it just says this is the accepted criterion, gauge or yardstick of implementing something and by which that implementation will be judged. It can be established by an authority or custom.
You can run off and disobey it if you want, your implementation will just be non-standard.
My whole gripe with OP is that he/she used the existence of a "standard" for GraphQL as an advantage over competing solutions. I can write up a fancy document and call it a "standard", but that doesn't mean shit in the real world unfortunately.
This excerpt from Wikipedia might explain it better:
"The existence of a published standard does not imply that it is always useful or correct. [...] The people who use the item or service (engineers, trade unions, etc.) or specify it (building codes, government, industry, etc.) have the responsibility to consider the available standards, specify the correct one, enforce compliance, and use the item correctly. Validation of suitability is necessary."
In other words, when the GraphQL "standard" is accepted and endorsed by (for instance) Microsoft, Google, and Amazon as well, we can start listing standardization as an advantage that GraphQL has over other competing solutions.
Falcor is a very interesting approach, and as others have mentioned GraphQL is very similar. I can't go into any details, but we have been using Falcor on my team as the basis for our own work. We are gradually moving away from it though as it has become clear it is great for Netflix's use-case but less so for a more generalised solution. Particularly when you throw in streaming data.
I have a sneaking suspicion that the open sourced version of Falcor also isn't the version used internally. This is certainly true of their Prana (a sidecar used to allow a node app to talk to the rest of the Netflix stack). And the repo has had a massive slowdown and basically ground to a halt in the past year - https://github.com/Netflix/falcor/graphs/contributors.
So saying that, I'd have reservations about recommending it for other developers to use. The concepts are great, but GraphQL is more widely supported and discussed. Also the Falcor docs could use some serious work for clarity.
Though I also believe there are better ways to declaratively describe your data requirements against a graph than either Falcor or GraphQL.
I'm not sure how great it is for Netflix's use case but it is important to realize how very different Netflix's use case from most web apps. In general, Netflix data is read only. The only data an end user sends to Netflix that he/she cares about is current position (which certainly works most of the time but doesn't seem enormously reliable) and ratings (which you probably won't know or care if they aren't quickly or accurately updated).
If you're writing a truly interactive system where, for example, you expect multiple devices to be active on the same account working in sync then Netflix isn't paving these paths.
Falcor extensions like streaming are up at https://github.com/graphistry/falcor , which we slowly contribute back to the Netflix one. We've been loving UWS+falcor on the server talking to falcor in the client, and even smoother with node-opencl & webgl bookending them.
Supporting streaming in such a system is tricky. I think David Nolen in Om.Next wants to explicitly support it. He mentioned it in some talks, but I cant find much about it.
> Though I also believe there are better ways to declaratively describe your data requirements against a graph than either Falcor or GraphQL.
Om.Next used Datomic Pull Syntax, it seems really powerful. Im not sure how it compares to Falcor or GraphQL.
Our approach is being influenced by Om.Next, though I personally don't have a great deal of knowledge of it.
I'm a fan of Elm, and it and Om.Next share some significant concepts I believe, so that's been guiding a lot of my thinking with regards to this stuff.
Over at Graphistry, we've been contributing to a lot of core Falcor development over the last year, e.g., Falcor+React integration and, quite recently, streaming data support. It brought a lot of sanity to our single page app workflow, and as a GPU<->GPU client/cloud visual analytics company, it has been one of our trusted tools for letting our small team deliver technology experiences that even the big companies cannot. Examples below :) At this point, we believe we've gone firmly past what we could have done with Falcor alternatives. We have not been vocal about it, but it's been unlocking a lot for us, and we've been in turn making sure it helps build out enterprise-level features (e.g., api-first) while still delivering our beyond-native experiences.
If any of this sounds cool, and especially if you are in the bay area, we have ~3 immediate developer openings -- build@graphistry.com :) Come work with one of the Falcor and Rx leads, one of the original reactive web framework developers, and more :)
I've watched Jafar talk about Falcor. Didn't know about it before since GraphQL is so dominant in the space.
If you're just getting into these, the major difference is the verbosity and the learning curve.
With GraphQL you need to know a lot about the schema and the types (which can be a good thing as well), with Falcor you don't and there's no easy way to code types (at least that I know of).
Whatever you choose though, I do encourage you to choose one. I have seen many APIs fail on performance because they send too much data down the wire just because one of the consumer needs it.
Sending redundant data feels wrong but responses can (sometimes) be cached and messages compressed. I thought that the main advantages to Falcor or GraphQL was around reducing network calls and querying multiple data sources from one endpoint.
If the same type and structure of data is requested with only variations in which fields consumers are actually using, isn't traditional REST still a good/better fit?
To me, the biggest benefit of adopting GraphQL was its strong-type system, which made communicating API specs between the client and server much more transparent
The reduction in network calls is an incidental bonus - most of the time you won't see it.
It's being in developer preview forever issues seat there with no response for long time. Unlike FB Netflix is dedicating 0 resources to help with its adoption. I think majority of people who originally wrote the thing left too.
I think giant corporations' peddling CSS and JS libraries maybe have a lot more developers than they really need to keep ... usually one ... website moving.
Consider also how many first-party Netflix clients exist for so literally thousands of different devices. TVs / consoles / set-top boxes / mobile / computers, each with at least a few platforms...not counting internal tooling.
Falcor, conceptually, is a really great and exciting idea. However it seems either too disconnected from existing tooling / too theoretical. Meanwhile, I've been working on an Open Source Firebase alternative for a few years now, and I decided to go ahead and implement (what, in obviously IMHO) is a better version of the idea.
Recently somebody combined it with webcomponents/polymer, which is pretty awesome. Here is an example they use for realtime IoT temperature data viz, you drop in `<gun-ui-lcd parent="livingroom" prop="temperature"></gun-ui-lib>` and it automatically tells the system to ONLY load `temperature` from the `livingroom` database. More info, along with a cool animated gif showing the example off in action, is here: https://github.com/Stefdv/gun-ui-lcd#syncing .
This makes it easy to bind with React, or Angular, or VueJS, or others. The important thing to note is, like Falcor, it only loads the 1 property, not the full document. If you want to show another item, it is trivial to just add `...get('alice').path('age').on(age => ui.show('#age', age))`.
I've already made a prototype which automatically generates the loading the properties based off of a plain HTML template. Hopefully I'll have it published in the next couple months. Meaning all you have to do is add a property to your HTML, and it automatically binds realtime updates of data to that view! (No writing JS).
Fragment queries load exactly what you want, with automatic smart caching etc. out-of-the-box, and give you robust controls when you want to get deeper into cache control, API generation, middleware, etc. I suggest taking a closer look.
For the above example, we'd write React+Falcor along the lines of
//vanilla react
const myReactComponent =
props => <h1>`Hello, ${props.name} and ${props.petName}`</h1>;
//falcor live query + binding to react component
const myView = Container(
myReactComponent,
`{users['alice']: {name, pet: {name, age}}}`);
Whenever any individual field in the server model updates, we get the update, and Falcor+React takes care of batching, incremental renders, etc.
I wrote a pretty big app in falcor, using react-redux-falcor for the client. Overall its was a good experience.
I haven't really gone back to check out graphql thoroughly, although I will say since I started my falcor project the community around graphql has grown a good deal faster than the falcor community.
I haven't worked on my falcor backed app in a couple months but last I worked there were still some rough edges and small bugs with falcor and it hadn't made it to a 0.1.0 release yet and there wasn't a lot of info from netflix about when it would get there.
If I was going to start a new app right now I'd take a longer look at graphql, despite really liking the development experience of falcor because of the community / long term outlook.
The GraphQL site is way better in terms of getting across what it is and how you'd use it. The only reason I finally realized that Falcor was a parallel tech was I had recently implemented a GraphQL service and ran through the tutorials.
I spun up a Falcor system at my last startup. We had this legacy REST API where the payloads had gotten quite large. A user contains a follower list, which in turn contains other users, which in turn contain other entities, etc. It was a mess, and quite slow.
The plan was to have a new REST API without these nested entities. Yes, that means you have to make lots of little calls to the REST API, but since a payload now represented one thing only, server-side caching was vastly simplified. And, we had a Falcor router which essentially batched these calls between the client and server.
So the the client hits the Falcor router, which in turns calls the REST API over localhost, in parallel, several times. As the front-end evolved, the REST API no longer had to try to restructure its responses to cater to the new views. The incoming batch calls would just change. This in my view was the true win of the whole deal.
It worked beautifully! The fly in the ointment was that there were/are no Java or Swift clients for Falcor, so while our Angular app was humming along happily in Falcor La-La land, our mobile clients were still talking to the legacy REST endpoints. We tried standing up some clever Falcor-like batching endpoints for the mobile folks, but they understandably wanted to stick to their fat endpoints.
Meanwhile, Netflix has repeatedly stated that iOS and Android client software is not on the horizon. They've actually gotten really quiet on the Falcor front in the last year. I think the team is under-resourced at the moment, unfortunately.
I notice sometimes that interestingly-connected, yet tangential topics can appear on the front page of Hacker News at the same time from time-to-time - often right next to one another at my viewing. In this case, I see Falcor and Microsoft's Graph Engine next to one another at this point in time. Is there serendipity there?
I've been enamored with Falcor since it was introduced, but I couldn't fathom how the server side would work to produce the JSON Graphs without a lot of painful data reshaping of relational data. It always seemed to me that a graph database would best serve as the backing store for Falcor.
Does anyone have experience backing a Falcor-driven app with a graph database? What was that like? Would Microsoft Graph Engine pair nicely with Falcor for building a user-facing web app? I'm scared of graph databases because I fear they'd necessarily be slow or not scale horizontally compared with NoSQL.
What about fine grain permissions such as a certain user can only see public fields of other users or you can only change your vote after 10 minutes? Opening up the data model may work in many cases but seems like it just brings up other paradigms in its place.
> such as a certain user can only see public fields of other users
In Graphql, the solution is usually to return `null` for restricted field. This is arguably better security than raising unauthorized exception, since attacker can't differentiate having no permission to having no data.
> You can only change your vote after 10 minutes
This in done in mutable action, which can have permission check inside.
> Falcor lets you represent all your remote data sources as a single domain model [...] You code the same way no matter where the data is, whether in memory on the client or over the network on the server.
Kinda surprised there hasn't been much associated discussion given the number of submissions, but I know GraphQL has had a much higher profile. My personal limited exposure to Falcor has been via David Nolen when discussing influences on Om.
GraphQL's higher profile comes primarily from it's association with React which has tremendous mindshare at the moment.
What's interesting is that, as a lead UI Engineer at Netflix while Falcor was being developed, much of what we were prototyping towards our new UI framework bore a lot of similarities to React. We were definitely behind them on implementation (and I don't really think we would have done as well) and I was happy when Netflix went down the React path.
Still, it's very interesting that a lot of similar ideas were coming out of both places.
Paul did a great job adding React support to Falcor ~half a year ago, and all our development now uses that. Really great for keeping it easy for our designer.
I have and I very much enjoyed it. For me, it was also a journey of learning ClojureScript which I've had a lot of fun with. That said, I don't do full-time development anymore so my hands on programming chops are probably waning.
Here are some of the reasons why:
- Falcor is not a standard or a language, its a large javascript library with conventions for manipulating data.
- GraphQL on the other hand, is a full blown query language, that is _standardized_. This means, that implementations in other languages (other than JS) will have to follow standards
- GraphQL has a very high rate of adoption, and has many libraries in other languages.
- GraphQL is backed by FB, which has a track record of releasing only things that have been tried and tested.