I can’t emphasize this enough: Apollo is plain standard GraphQL. As such, there is nothing custom about it. You can run it anywhere, and it’s going to be compatible with any server that correctly implements the GraphQL spec.
In fact, Apollo Client is currently the only client that fully supports the GraphQL spec, and we will make sure that it always supports the spec. If you want to stay as flexible as possible and as close to the standard as possible, there is no better choice than Apollo.
Very true and much appreciated! I have an Elixir based server (running Absinthe) and Apollo Client works seamlessly!
Scaphold’s subscriptions example currently uses Apollo: https://github.com/scaphold-io/graphql-subscriptions-realtime-starter-kit
We’re also working with Graphcool to add support for GraphQL subscriptions, using a standard transport that everyone can agree on.
We’re carefully making everything we do as standard and decoupled as possible, so that everyone can work together on it. For example, someone could implement Relay support for the subscriptions transport we’re designing if they wanted to.
I wonder how much is Apollo ready for offline apps? I’m about to develop a mobile app with RN and offline capabilities is a must to this project. Someone can to clarify this ?
Thanks in advance!
Advanced offline capability is currently a bit of a research topic for sophisticated GraphQL clients. With Apollo, you can store data offline and use it without the network using something like redux-persist, but it doesn’t have any features about intelligently refetching data when you come back online, or queueing up mutations etc.
So really it depends exactly how much stuff you want to do while offline. If it’s just looking at data you loaded before, then it definitely supports that. If you want to allow the user to edit that data and later sync it to the server, you’ll need to put in some work to make it happen.
Thanks @sashko for the answer. At this time, I think I’ll need just to read some data offline and automatically read (fetch) some data when the clients back online. There is any docs regarding this topic for Apollo I can go check out ?
Have you seen https://realm.io? It has awesome offline capabilities for mobile (including react-native support) . I’m wondering about the feasiblility of integration with Graphql or Apollo stack as the technologies seem to conflict in some areas. @aislan @sashko
Correct me if I’m wrong but I didn’t think Relay supported pub/sub/reactive updates?
It doesn’t out of the box. There are some add-on packages people have created, and there is some confusion about what might be in the next version of Relay but I’m 90% sure it also won’t include built-in subscriptions support.
Yeah I don’t know if they would work together right now, but that’s definitely something to explore for the future.
it’s 2017… why are we still talking about subscriptions? this real-time tech is so syntax heavy and non-performant at scale. why are new/amazing cutting edge dev-facilitators like Apollo moving forward with old tech? it makes no sense to me… Deepstream.io uses data-sync and uWebSockets which is so next-gen compared to subscriptions, hell, even firebase’s real-time data-binders are better than subscriptions… firebase maybe not be that performant at scale, but at least it’s light on syntax compared to pub-sub. To be clear, I’m not making the case for firebase, but rather, the case for pure data-sync!
Interesting! Can you point us to any documentation about data-sync?
We considered a lot of different approaches and subscriptions are actually quite a good solution for a variety of cases. We have a lot of experience with what people run into when introducing a more replication-based approach, and I think both have their place.
Long-term, we want to have all approaches as an option - data synchronization for live queries, static queries, and subscriptions.
However, I reject the claim that subscriptions are inherently not scalable - in fact they give you a lot more control over scalability than the alternative.
Facebook just released Relay Modern: https://code.facebook.com/posts/1362748677097871/relay-modern-simpler-faster-more-extensible. I’d like to see a real comparison between Relay Modern and Apollo.
I haven’t looked at Relay Modern beyond your link (thank you) and its terrible name. A comparison would be interesting.
If I had to guess (and isn’t that what forums are for!), they “borrowed” heavily from Apollo. And I’m sure Relay Nuevo has new ideas that Apollo will borrow back.
The bottom line, for me, is that MDG is extremely capable with outstanding communication, and I feel like they largely have the developer’s best interest at heart. Therefore, I’m not interested in deep diving Relay pt 2. I have confidence that any good Relay advances will translate to Apollo in short order, and I get to support MDG in the process.
Wait, since you think MDG is has our best interest at heart, you’ve lost interest in other, completing tools? 
Not to mention, completing tools that complete the React stack and are being pushed hard by Facebook – React/Redux/Relay.
Remember, one of the reasons we were told to move away from the Blaze stack – Blaze/Tracker – and to React was the fact that Facebook had “hundreds” of engineers working on it full time-- and MDG could not (or didn’t) want to complete with that sort of effort.
This turned out to be true, Facebook is about to release a completely rewritten React framework (v16) with React Fiber and tons of other features and perf improvements – all the while keeping the API almost the same.
Do you think Relay Modern (another complete rewrite) has any less commitment and effort behind it from Facebook?
I have other things to do with my time than deep dive the latest and greatest… like build things. (I don’t mean that with attitude) If Relay Better gains a large footprint, I’ll consider a refactor. But until then, my only interest in it will be academic.
I don’t know what their commitment is or isn’t. I do know that Facebook could never touch another line of open source code and it wouldn’t make one bit of difference to Facebook as a company. I know that’s not true of MDG.
RethinkDB and Horizon bit me badly. As developers, I think that we should support the ones doing the best work. Therefore, Apollo gets my benefit of the doubt and I look forward to being an Optics customer.
Man, that’s what we all said when were were told to move from Blaze to React. Look how that turned out.
I just learned React/Redux (everyone was right, awesome frameworks!) and am now planning to migrate from Blaze.
That’s what we said of Facebook, then MDG stopped supporting Blaze/Tracker and moved to a React + Apollo focus. And again, not to undercut your point too much, but Facebook just doubled down on both React and Relay with a complete rewrite – there’s no way they’re standing still – their “hundreds” (or thousands even?) of engineers won’t let them.
I guess Blaze was before your time. 
But you just said yourself you haven’t even seen Relay Modern, how do you know for sure?
Also, I’m not here to promote Relay Modern over Apollo – I don’t know either tech yet (but these two are next on my list). They both look interesting and I think it’s worth while to explore both options.
A nice writeup from Apollo on the differences. Lee Bryon approved too.