Relay Modern Support?

[tanekim88]

Hi, I think a lot of people would rather opt in Relay Modern instead of Apollo, since Relay Modern is optimized for performance. I understand Apollo used to dominate Graphql client before Relay Modern officially released few weeks ago, but now the game is changing. Would you mind giving us a choice for Relay Modern when creating a project? Also, I think Relay Modern should be the default choice, and Apollo an alternative, since Apollo is more of a general purpose client that targets other frameworks as well, while Relay Modern is optimized for mostly React framework

[leebenson]

A community PR for Relay Modern is in the works here.

I'd like to see a show of hands of for Relay Modern demand before committing to an 'official' kit. I use Apollo in production, and it's pretty solid. Relay Modern is newer, and is slightly more opinionated in how it fetches data. It also introduces a build step that isn't needed in Apollo, which would require some Webpack changes.

If there's a strong demand for preferring one over the other, I'm open to making changes. I'd rather not support both, though, because they both ultimately do the same thing.

Open to community suggestions.

[Extra-lightwill]

I agree with above. Relay is pretty much purpose-built for React (even though the new version allows for integration with other view libraries). Obviously the guys at Apollo have done an incredible job but it's not a library written by Facebook so there may be challenges when APIs update. Relay Modern also seems to address a lot of the complexity that existed in Classic.

[zachlendon]

I'd prefer to use Apollo or at least let their be a choice. One could argue that Apollo is simpler but less feature rich from an adoption perspective, which has worked well for the implementation I've been involved with where we are using Apollo. Relay Modern is also newer from an OSS end of things at least and while that might well match the more cutting-edge nature of this project there has been a stability to Apollo which helps adoption of it.

[mnpenner]

I have no strong opinion one way or the other. I've only just integrated Apollo because Relay Modern hadn't released yet. I'm finding subscriptions to be a bit tedious to implement in Apollo, and the documentation is weak. I'm getting a warning that I should start using GraphQLTransportWSClient but that doesn't even exist yet.

So for me, I want:

1. ease of development, not a lot of boilerplate code
2. subscriptions/real-time updates
3. good client and server support

I understand ReactQL focuses on the client, but unless there are some good libraries to help out with the server (like apollo-graphql-express-server), then it isn't of much use.

Apollo does caching out of the box. Relay makes this little comment about caching, but then doesn't tell you how to do it:

This example could be extended with additional features such as request/response caching

This guy says its not documented yet.

IMO, Relay Modern seems a bit too new yet. I think I'd wait a bit for the community to flesh out more of the problems. Apollo seems more batteries-included, which I like.

[leebenson]

Thanks for everyone's thoughts so far.

@mnpenner - did you see the GraphQL server example in the examples repo?

It's a simple but relatively complete demo for adding Apollo's Koa-based GraphQL server to your existing ReactQL project.

If you want to dig a bit deeper and add SQL to the mix, I posted a video on YouTube a while back that is still relevant today.

Neither of these examples use subscriptions yet, but they're a starting point to bolt-on subscription middleware like these.

I'll eventually explore subscriptions a little deeper and post an example. For now, the combination of the above should hopefully get you started.

---

My concern with Relay at this point is the lack of documentation. It's new, so it's understandable, but it makes it tough to support Relay Modern as the de facto lib when fundamental pieces such as store (de|re)hydration is missing from the docs, and functionality hinted at in doc snippets isn't yet quantified with a documented API.

Those pieces have been supported for a while in Apollo, so it's territory that's easier to deem 'stable'.

Having to trawl through disparate git issues in Relay to figure out whether something had landed, or was currently in a state of flux, is what led to the decision to use Apollo in the first place. IMO, it just needs a little time to mature, then it might be worth a re-visit.

[scf4]

@mnpenner

I'm finding subscriptions to be a bit tedious to implement in Apollo, and the documentation is weak. I'm getting a warning that I should start using GraphQLTransportWSClient but that doesn't even exist yet.

It seems it's much worse with Relay (facebook/relay#1655), but take a look at apollographql/subscriptions-transport-ws#169

@tanekim77

Relay Modern is optimized for performance

Apollo is more of a general purpose client that targets other frameworks as well, while Relay Modern is optimized for mostly React framework

Specifically in which ways? From what I've read it seems Relay Modern has only just caught up to some optimizations which Apollo has had for a year, such as persisted queries.

I wouldn't say being purpose-built for React is a big plus when both clients have separate core and React packages. Any React-specific optimizations could be implemented in Apollo just as much as Relay.

I understand Apollo used to dominate Graphql client before Relay Modern officially released few weeks ago, but now the game is changing.

According to whom? Can you give a single solid reason why Relay Modern is a better choice besides it being new and shiny and made by Facebook?

Apollo only recently reached 1.0. and it has better docs. I'd say it also has many more features but it's so difficult to figure out what Relay does/doesn't support that I just don't know.

@Extra-lightwill

Obviously the guys at Apollo have done an incredible job but it's not a library written by Facebook so there may be challenges when APIs update.

What kind of challenges? I'm quite sure the Apollo team has worked with Facebook on some of the GraphQL API (e.g. subscriptions) so I really don't see that happening.

I'm not opposed to using Relay Modern if it's better, but can we judge the clients on their own merit rather than simply assuming the Facebook version is better?

[Extra-lightwill]

@scf4 I'm by no means an expert, just speculating. I'm also aware that the Apollo team and Relay team are in contact so this may not be an issue in the future. Ofc, there's going to be tradeoffs whichever is chosen. I'm equally not opposed to using Apollo if that is deemed the better choice.

[tanekim88]

@scf4 I think that we are at a too early stage to judge Relay Modern, and the best approach for now is to wait and see. However, what remains true is that Facebook will continue to invest on Relay Modern to be optimized for React Framework, and it will eventually become a stable release that is likely to outperform Apollo on React framework at the cost of having opinionated and inflexible implementation. Apollo is a general purpose client that tries to be more flexible and less opinionated than Relay Modern in order to cater to many other frameworks -and rightfully so. With that in mind, it is likely that it will not be able to get as optimized for React framework as Relay Modern would in a long run.

[leebenson]

If either framework has optimisations over the other, they'll likely relate to data handling/caching and not necessarily be reflected in React or other upstream UI providers. Both frameworks simply feed props into a React component; they each have exactly the same access to React's surface API, so FWIW I'm not aware of any means by which Relay could offer 'deeper' integration than Apollo or any alternative.

The bigger concern some enterprises will have (or indeed, smaller dev shops) is that Relay and React sprung from the same parent, and therefore both the library APIs and the long-term future of each stack piece fall under a common purview. Apollo will always be secondary to that (unless they take the GraphQL spec, and start doing proprietary things with it.) That gives some users confidence in the long-term than any second tier can't really compete with, which is a benefit I definitely don't to understate.

For ReactQL specifically, I think we currently have something that works well. Given that the two libs have close feature parity, and Relay is very new and missing key documentation, I don't think there's an immediate impetus to switch. I've not seen evidence of solid SSR support yet either, although I suspect those features are further along in disparate Github threads than the doc currently confirms.

I remain open to the idea of switching down the line - so long as the APIs don't change so drastically that the components we're building in our projects today require a significant rewrite. For the most part, Relay vs. Apollo is currently just a case of switching a few kit pieces and re-jigging the Webpack config, so I don't foresee too much of an issue. I certainly wouldn't let one choice over another put you off from starting a project today in Apollo.... it's ultimately just React components expecting props, and whatever upstream mechanism that provides them is an implementation detail that can easily be refactored.

[scf4]

Good points, Lee. I think Relay has some optimizations with shouldComponentUpdate, and I also like the sound of how it ensures components properly declare the data they need, but I have no idea what it's like in practice.

It'd be interesting to see some perd benchmarks.

[Extra-lightwill]

Perhaps it's worth tracking the Relay issues that are relevant to this conversation (e.g. SSR support / store hydration etc.) in this thread? Then re-assess once both frameworks can be deemed 'stable'.

[leebenson]

@Extra-lightwill - sure, good idea.

---

Tracking Relay features:

• SSR support
• Store (de/re)hydration
• Custom stores / attaching Redux or alternatives to a common store

---

Feel free to chime in with posts to appropriate issues, documentation added or other features that should be tracked.

[leebenson]

With kit v2.0 introducing a built-in Apollo server and use of apollo-local-query, integration with the Apollo stack is deeper than ever-- so I see less of an impetus to switch to Relay beyond the argument that it's "from Facebook".

I'll leave the tracker (above) open for the community to fill in, if there winds up being compelling demand later down the road, or a real reason to switch. For now, I'll close this thread. Feel free to add additional commentary/discussion, and I'll re-open if/when a compelling reason to reinvestigate presents itself.