I was looking at the discussion for Relay Subscriptions here and saw that their feature set matches much of what Apollo is attempting to solve. This made me curious, what benefits will Apollo have over this besides being framework agnostic?
From the link on goals of their new API:
Server rendering (or pre-fetching data on the server and rendering on the client).
Implementing real-time updates (subscriptions) in user-space.
Offline persistence.
Implementing your own alternatives to RelayContainer/RelayRenderer.
Apollo is flexible in a lot of really significant ways, many of which will become clear after we launch a new API we’re working on. Basically the idea is that it integrates with your existing workflow, and is easy to contribute to and extend.
The discussion you linked to does not say that Relay will support subscriptions, but rather that it will be possible to implement subscriptions in user space, meaning as an external package. Apollo has this support built-in, and it will integrate nicely with all of the different parts.
Besides, we already have all of the features that “should be possible with this new API” in Relay.
Either way, given how long Apollo and Relay have been around, I’d say it’s a pretty great achievement that we have about equivalence in features, and I expect that Apollo will gain cutting-edge features much faster starting from this point, especially because it’s more flexible and community-oriented.
Thanks for the quick response. One concern that I had when comparing the two is that if one wanted a GraphQL as a service provider that supported subscriptions there seem to many that would support the above when it comes out (yes, speculative at this point) such as scaphold, reindex, etc. which stay close to Relay API. Apollo seems to be something that would only have Galaxy which may be higher priced. We can’t compare scalability at this point but is there a Meteor “recommended” server setup for DB, etc? (If one wanted to setup similar services)
(Lack of free developer tiers is a big concern with any lock-in)
Relay is a performant, opinionated, React-specific GraphQL client built by Facebook for their mobile applications. It focuses on enabling the co-location of queries and components, and is opinionated about the design of your GraphQL schema, especially in the case of pagination. Apollo has an analogous set of features to Relay, but is designed to be a general-purpose tool that can be used with any schema or any frontend architecture. Relay’s coupling to a specific kind of schema and architecture enables some benefits but with the loss of some flexibility, which also lets the Apollo community iterate more rapidly and quickly test experimental features.
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.
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 ?
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
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!
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.
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?
Not to mention, completing tools that complete the React stack and are being pushed hard by Facebook – React/Redux/Relay.