Facebook has said that they never remove a property from their databases which seemed nuts to me but with Relay and GraphQL it makes a lot of sense. Why have the need for versioning when the client can request whatever they need.
Relay Modern: Simpler, faster, more extensible
21–30 of 111 posts
Re: Relay Modern: Simpler, faster, more extensible
#22What are the differences between Apollo and Relay Modern at this point? Why/when should you choose one over the other?
The learning curve for Apollo is a bit shallower for two reasons: (1) they have GraphQL libraries that allow you to implement a Relay-like client on top of an existing GraphQL end point (Relay requires some custom fields); and (2) better documentation.
We went with Relay, however, because it is, in my experience, more robust and more polished. The way that Relay handles fragment composition and defers component rendering, along with data masking, is much nicer and more... holistically considered(again, in my opinion). Using Apollo can feel a bit like patchwork sometimes.
Plus, ultimately, Relay is backed by Facebook and used in Facebook applications, in production, so it's not going anywhere.
Re: Relay Modern: Simpler, faster, more extensible
#23Exciting to see! I've been waiting on this since we decided to use Relay for our application about 6 months ago. Relay is amazing but quite an investment (especially mutations). I'm a bit worried, however, that Relay Modern has focused a bit too much on the internal needs of a massive application like Facebook at the expense of fleshing out some of the rough spots of working with Relay. Simpler, more explicit mutatio…
Follow-up (didn't see the updated docs). Looks like there is some support for client-side state through "Client Schema Extensions" — excited to play with this.
I do also hope that this iteration brings with it better docs — that's the one area where I've looked over at Apollo longingly. On many occasions I've discovered unknown patterns in stack overflow answers that aren't documented anywhere (credit where it's due: the answers are often by members of the Relay team).
And one final tangent: the day when Facebook gives up on flow and adopts Typescript will be a glorious, glorious day.
More here: https://facebook.github.io/relay/docs/new-in-relay-modern.ht...
Re: Relay Modern: Simpler, faster, more extensible
#24I'd be interested to read an analysis of how this compares to the backends-for-frontends pattern. Also, it seems like Relay Modern reintroduces API versioning, but automates it behind a compiler step. Is that a fair characterization? Does the server have to implement some kind of tracking and pruning for unused fragments, or is it expected that the fragments will accumulate at a non-threatening rate and never need pr…
I wouldn't say so, this has none of the maintenance implications that versioning does.
Oh? Seems like you still want to support old client versions, which means retaining the fragments that they reference. The question then is what implications that has on a server -- do old fragments need to be eventually garbage collected?
Re: Relay Modern: Simpler, faster, more extensible
#25Congrats! Relay is what really sold our iOS-only native team to move to React Native. Very excited to migrate to modern version at some point in the future. ( http://artsy.github.io/blog/2017/02/05/Retrospective-Swift-a... )
is emission the only react-native app artsy has built/open sourced?
Re: Relay Modern: Simpler, faster, more extensible
#26Earlier quoted context omitted.
I wouldn't say so, this has none of the maintenance implications that versioning does.
Oh? Seems like you still want to support old client versions, which means retaining the fragments that they reference. The question then is what implications that has on a server -- do old fragments need to be eventually garbage collected?
That is fair, I hadn't thought of that. I would argue the difference is perhaps the ease of tracking the different versions and their usage and the ease of collecting versions. Plus the client can fall back to submitting the full query.
Re: Relay Modern: Simpler, faster, more extensible
#27What are the differences between Apollo and Relay Modern at this point? Why/when should you choose one over the other?
Hi, I'm from the Apollo Client team.
We're going to write some more content in the coming days or weeks about the differences, but here are some of my main thoughts based on following along during Relay Modern development:
1. Relay uses a build process to generate code for queries. That allows some better performance optimizations and static typing out of the box. However, it prevents you from doing anything which requires arbitrary knowledge of the queries at runtime. It also means that if, for some reason, you can't use the build tooling, you can't use Relay. That's actually the original reason we started working on Apollo instead of using Relay ourselves. Apollo works with regular GraphQL ASTs at runtime, so you can use and write tools to work with those queries in any way you like. While it's not something all apps need, we've found some situations where this is desirable, especially for developers building companion libraries.
2. Relay doesn't have as many facilities for updating the store and working with mutation results. Apollo Client has a unique way to use GraphQL fragments and queries to read and write to/from the store, the most recent of which is described here: https://dev-blog.apollodata.com/apollo-clients-new-imperativ...
3. The Apollo Store is a plain JavaScript object, which means it can be easily serialized, persisted, hydrated, etc. So for example doing server-side rendering where you also hydrate the state is super simple in Apollo. Part of this is because of Apollo's Redux heritage.
4. Developer tools - we think it's super important to understand exactly what is going on with your data, both inside your app and across the wire. That's why in addition to sticking to simple plain objects we worked on some developer tools for chrome: https://dev-blog.apollodata.com/apollo-client-developer-tool...
5. One thing we're really proud of is how different libraries in the Apollo ecosystem are owned and maintained by different organizations from the community. This might make the experience of using it a bit less polished, but means that you can easily contribute or start your own projects if you need some non-standard features.
However, it's also great to remark on the similarities, which I think show that the community and Facebook are converging on some common good ideas. In fact, a lot of the initial decisions on Apollo are based on talking to the GraphQL team at facebook about their experiences:
1. Fully static queries - both Apollo and Relay encourage you to write your queries in the GraphQL language, and avoid manipulating them in unpredictable ways. This is actually one of the ways Apollo diverged from the original Relay release and it's great that it's coming together. Read more here: https://dev-blog.apollodata.com/5-benefits-of-static-graphql...
2. Colocation of data with the view - both Apollo and Relay enable you to do this. This pattern was one of the best achievements of the original versions of Relay, and we think putting the queries and fragments right next to the UI is a great pattern.
Most importantly, though, it's super encouraging that the GraphQL community is gaining another great tool. The best part about GraphQL is the diversity of approaches to servers, clients, and tooling, and that they can all work together through the specification. Really excited to see this release, and I hope we can all learn from each other and make GraphQL a real pleasure to work with.
Re: Relay Modern: Simpler, faster, more extensible
#28Earlier quoted context omitted.
Congrats on the release. Could you summarize the pros and cons of picking Relay Modern vs Apollo Client?
Here is a detailed comparison between Apollo and Relay: https://www.graph.cool/docs/tutorials/relay-vs-apollo-iechu0... (Note: This article hasn't been updated for Relay Modern yet but the main points are still the same.)
I think the comparison is going to be pretty different for Modern because Relay Modern has some significant changes in the approach.
Re: Relay Modern: Simpler, faster, more extensible
#29Hey, Jan here together with Lee from the Relay team. Happy to answer your questions.
1. Could you two do a Reactiflux Q&A?
2. Are people on the Relay OSS team willing to answer StackOverflow-type questions on a certain time?
- I would want to be able to programmatically run relay-compiler. Every time I update my client-side code, webpack detects the change and then runs relay-compiler.
- And get help figure out some errors related to mutations I'm encountering. I wouldn't want to post these type of things as a GitHub issue because it could technically not be a bug.
Re: Relay Modern: Simpler, faster, more extensible
#30Hey, Jan here together with Lee from the Relay team. Happy to answer your questions.
Thanks Jan. Will there be support for websockets?
Hi, I'm Joe also on the Relay team.
Relay Modern (as with previous versions) supports an injectable network layer. This allows each application to customize how to communicate with its GraphQL server using whatever transport protocol is most appropriate (for example you might use HTTP for queries/mutations and WebSockets for subscriptions).