Having worked with a lot of Javascript frameworks aimed at creating web applications/SPAs (used Cappuccino to build a wireframing tool, Backbone.js to build a dashboard for a payments provider, React/Relay to build a phone calling tool and events platform, and now React/Apollo to build a peer-to-peer texting tool), I can say that React/Apollo/GraphQL is my new go-to stack for new JS projects. It's a pleasure to work with, and a lot of the pain points of creating large apps with JS in the past are handled very well. Congrats to the Apollo team!
After working with Apollo for a couple weeks on a non-trivial side project, I'm particularly happy with how unopinionated the library is. While it's super hip to complain about JS fatigue these days, Relay just wanted to make too many decisions. In that sense, it's a pro and a con: Relay will make more decisions for you, but will present difficulty if you've already made some of those decisions yourself.
Apollo's using Redux is great. The model and API are well understood so it's easy to bring developers on board. Relay seems to follow the same principles, but does them in its own way.
Relay is also opinionated about your server's responses. I know that the cursor pattern with edges and nodes is great for performant pagination, but then our schema has to conform to that spec and I really don't enjoy spending time explaining why we can't just get that user's photos, we have to get that user's photos' edges' nodes. Graph theory has a place, but it's not that close to the frontend, IMO.
More than anything, it seemed very easy to get up and running with Apollo. After reading lots of Relay docs, it still took a lot of experimentation and effort to get this running to begin with. I am very happy with Apollo's docs.
Before we started building Apollo Client, we actually tried Relay, but found it difficult to adopt, so we started a community effort to build a more flexible GraphQL client. Our main goals were to make incrementally adoptable, compatible with all view layers and easy to understand/debug.
While Apollo is easier to adopt and use, it's still under active development, so it's not as stable as Relay, and hasn't been optimized for performance the way that Relay has.
/disclaimer/disclosure/ - when you disclose something, it's a disclosure. (Sorry, personal bugbear, along with e.g. / i.e. confusion. Both are rampant on HN! :) )
I started a new Ember.js project recently and got frustrated with Ember Data and JSON API. In my experience, it's the weakest part of Ember by far. Out of curiosity, I tried wiring up Apollo Client to my backend instead. Turned out to be very easy to get going.
So far I like apollo-client and GraphQL much more than Ember Data. I get full control over what data is being loaded on each route and only fetch exactly what's needed. Mutations with explicit arguments are also much better than the blob.save() / save-everything style encouraged by ember-data.
With client-side resolves in the next release, this integration should get even better. Hopefully they'll also switch to using GETs for non-mutation queries to enable some much better caching options.
I spent a day or so with relay and kept being blocked by mysteries or tired out from the amount of code you need to set up for a mutation. Branched and tried it with Apollo and everything has been pretty easy going.
Merging Fragments in the style of relay were my main concern with Apollo but they do have this now.
All in all much more flexible and readable than relay.
Do you plan to make an integration with Meteor ? My main frustration with Meteor have been than it is tied to mongo (and not a relational db). I see Apollo as a way to plug Meteor with any data backend. If I'm not mistaken, that was the original sales pitch of Apollo.
So my question is: should I have high hopes of being able to work with Meteor and Postgres with the help of Apollo?
A lot of people are doing that already! You can use Meteor as the build and deployment system for your app, and use Apollo for data. The main remaining blocker is the accounts system, since it is still tied to a particular MongoDB schema. We're working with people in the community on some ideas about how to make Meteor Accounts database-agnostic, so once that is possible it will truly be possible to build a Meteor app on top of any backend.
Can I find any moderate-size app that uses Meteor with Appolo and Postgres as an example? The Meteor guide and tutorials, as well as most well-known Meteor open source apps (wekan, telescope...) use mongo collections.
And since Meteor is a full stack framework, I would love to see a guide about how to best structure an app with Meteor and Apollo (I'm in the camp where I don't like to fiddle around with what's the best js stack. I'm happy to have the framework authors decide that for me, and get down writing my goddamn app)
It's meant to be part of a decoupled stack where you can pick and choose different options for UI, backend, etc. We're constantly working towards having clearer integrations and patterns. If you just want to get a thing built without making decisions and putting in some work for integration, I'd just go with the built-in Meteor stuff for now.
I've been wanting to try out vue.js and have a GraphQL endpoint. Apollo seems like a Relay alternative that's not tied to React. Can anyone compare the two (Vue.js+Apollo and React+Relay)?
The name is completely unrelated to its function; I thought this was NASA's code. Imagine my disappointment when I saw a javascript library for working with GraphQL!
Thanks - we went through a ton of different names, and almost all of them had some sort of collision. We try to mention GraphQL up front on all of the content to avoid extended confusion :]
I probably should have included the fact that it's a JS GraphQL client in the title, but I wasn't sure if that would violate HN's "editorializing" rule.
On the bright side, we apparently got a few people who thought it had something to do with NASA. Muahaha!
