Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Relay Modern: Simpler, faster, more extensible

code.facebook.com

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Relay Modern: Simpler, faster, more extensible

#31

Post by wincent »

voxmatt wrote: post #23
voxmatt wrote: post #17

Exciting 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:…

> I do also hope that this iteration brings with it better docs

The docs are very minimal this point with some definite gaps (we had a bit of a scramble to get them written in time for F8), but the point is well-taken: Relay docs need to get better. Luckily, the design of Relay Modern is simpler and easier to understand and explain; there is less (no?) magic involved, so we should be able to get the docs to a much better place now.

Re: Relay Modern: Simpler, faster, more extensible

#32

Post by mjmahone17 »

djmashko2 wrote: post #27
ianstormtaylor wrote: post #15

What 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 re…

From what I know of Apollo (which is a lot less than Relay, having worked on the RelayModern compiler), this comparison is pretty good.

(1) is true, for the most part, from the developer point of view. But when you're using the compatibility mode of RelayModern (i.e. sending out a legacy query that contains modern fragments), Relay does runtime query building from the Modern fragments.

(2) Relay allows you to define updaters for mutations, which lets you write client-defined data transformations. This may not be as complex as what's happening in the Apollo client, but I don't have the experience to say. See http://facebook.github.io/relay/docs/mutations.html#updating...

Edit: I'm Matt, and I work on a sibling team to Relay at Facebook, and helped build RelayModern's compiler.

Re: Relay Modern: Simpler, faster, more extensible

#34

Post by cies »

voxmatt wrote: post #23
voxmatt wrote: post #17

Exciting 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 day when Facebook gives up on flow and adopts Typescript will be a glorious, glorious day.

I foresee FB to skip TypeScript and go straight with ReasonML[0], as 25%[1] of the messenger code base supposedly is already converted to Reason.

And I think that is even more glorious development then FB going with TypeScript. :)

[0]: An easier to approach (for programmers coming from mainstream languages; like JS/C++/Java/C#) syntax on top of the OCaml language, and some new tooling. The tools integrate specifically well with BuckleScript (by JaneStreet) which provides the OCaml compiler with a JAvaScript compile target.

[1]: https://news.ycombinator.com/item?id=13980062

https://facebook.github.io/reason

https://github.com/vramana/awesome-reasonml (some links to example code in the last section)

Re: Relay Modern: Simpler, faster, more extensible

#35

Post by ilovecaching »

My biggest gripe with the original Relay was that it didn't work with any GraphQl schema, but only those that provided a bunch of features like pagination and retrieving any object by id. This no batteries included, high initial bar for using Relay really turned me off of the product. I see that Relay Modern claims to be 'simpler', but I don't see anything about relaxing the constraints on my graphql schema.

Re: Relay Modern: Simpler, faster, more extensible

#36

Post by RaitoBezarius »

tonyhb wrote: post #4

> "Relay Modern is designed from the start to support garbage collection — that is, cache eviction — in which GraphQL data that is no longer used by any views can be removed from the cache" Could we go ahead and implement proper caching as HTTP would do: expiration date per field/models, then eviction based on expiration dates? With an optional max cache size using LIFO, last used or the current model. That way we do…

Correct me if I'm wrong :

But, wouldn't "garbage collection" solve the problem of many React web apps of consuming too much RAM (e.g. when using Redux, you never expire some keys and throughout the application lifecycle, you never cease of accumulating data inside your stores which makes RAM consumption goes up) ?

Re: Relay Modern: Simpler, faster, more extensible

#37

Post by mjmahone17 »

cainlevy wrote: post #16

I'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…

There's just as much versioning for Relay Modern (from the server's point of view) as Relay Classic: so long as you have a client that sends a query string with old fields, your server needs to maintain support for returning those fields. So long as the field is nullable, you always can choose to "turn it off" server-side by always returning null.

In general, over time, as applications get more complex, the main queries you use will have more fragments. But we usually convert an entire query into a single ID (representing the entire query text, fragments and all). With each "version" of the query, fragments could be added, removed, or completely modified. Usually, your server shouldn't care what the specific fragment version is, but should be able to translate the fields the fragment asks for into a function that builds a response of that shape.

But one of the advantages of GraphQL in general (Relay included) is that you don't really need to version your API: so long as a field continues to exist in your schema, and continues to return the same type of object (even if that object adds new fields or interfaces), your old query/fragment will always receive the same shape. That may mean, over time, you "turn off" more and more fields by having them return as nulls to every client that asks for them, but you shouldn't think of it in terms of versions.

Re: Relay Modern: Simpler, faster, more extensible

#38

Post by josephsavona »

mjmahone17 wrote: post #32
djmashko2 wrote: post #27

Earlier quoted context omitted.

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 re…

From what I know of Apollo (which is a lot less than Relay, having worked on the RelayModern compiler), this comparison is pretty good. (1) is true, for the most part, from the developer point of view. But when you're using the compatibility mode of RelayModern (i.e. sending out a legacy query that contains modern fragments), Relay does runtime query building from the Modern fragments. (2) Relay allows you to define…

Agree that this is overall accurate, especially wrt to Relay Classic. For Relay Modern, however:

> 2. Relay doesn't have as many facilities for updating the store and working with mutation results.

Apollo and Relay Modern are about equal in this regard. Relay supports arbitrary writes to the store (either via an imperative API, via a fragment + payload, or a mix of the two), plus similar APIs for updating the store after a mutation or subscription update. This includes the ability to update client-only state.

> 3. The Apollo Store is a plain JavaScript object,

The Relay Modern store is also a plain object. There aren't currently any convenience functions for serializing/deserializing it, but this is something we're open to adding.

Overall I'd say the main differences is that Apollo has focused very much on easier onboarding and covering a wide variety of use cases (many view layer integrations, developer tooling etc), where Relay is more focused on performance and scalability (hence features such as ahead-of-time optimization, garbage collection, etc).

Either are appropriate depending on your specific needs. I'm excited to see so much iteration in this space!

Re: Relay Modern: Simpler, faster, more extensible

#40

Post by mjmahone17 »

ilovecaching wrote: post #35

My biggest gripe with the original Relay was that it didn't work with any GraphQl schema, but only those that provided a bunch of features like pagination and retrieving any object by id. This no batteries included, high initial bar for using Relay really turned me off of the product. I see that Relay Modern claims to be 'simpler', but I don't see anything about relaxing the constraints on my graphql schema.

You should be able to use Relay Modern with any valid GraphQL Schema. If you can't, it's a bug that you should create an issue for! To use your own schema, you just need to specify what it is during the relay-compile step: http://facebook.github.io/relay/docs/relay-compiler.html#set...
Post reply on HN