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

41–50 of 111 posts

Re: Relay Modern: Simpler, faster, more extensible

#41

Post by josephsavona »

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…

Hi! I'm Joe from the Relay team.

Good questions! It isn't quite as straightforward as you might expect - the interconnected nature of graph-like data means that strategies that work for HTTP don't necessarily apply.

For example, storing per-field expiration times could incur additional memory overhead (you might end up with an object per field instead of per record). Storing per-record expiration times is tricky since the same record can have different fields fetched at different times. And a simple max cache size + LIFO/LRU/etc evication strategy means that the cache might evict a record that is still referenced by a view.

This type of TTL/expiration is something that we're continuing to explore.

Re: Relay Modern: Simpler, faster, more extensible

#42

Post by josephsavona »

RaitoBezarius wrote: post #36
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) ?

In general yes, garbage collection in Relay Modern is meant to help constrain growth of memory usage during the course of a session. This is where the declarative nature of GraphQL is helpful; unlike Redux which is accessed via arbitrary selector functions, Relay knows (via queries, fragments, etc) which parts of the cache may still be referenced and can evict records that aren't.

Re: Relay Modern: Simpler, faster, more extensible

#43

Post by josephsavona »

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…

Thanks for the feedback!

> but there's no mention of subscriptions or client-side state control

The blog post didn't cover all the new features, but both of these use-cases are supported in Relay Modern - https://facebook.github.io/relay/docs/new-in-relay-modern.ht...

GraphQL Subscriptions are supported: applications must inject a network layer that provides support for connecting to the server and receiving subscription updates. Local state is supported via client-only extensions to the schema, combined with an imperative update API. More docs coming soon :-)

Re: Relay Modern: Simpler, faster, more extensible

#44

Post by ilovecaching »

mjmahone17 wrote: post #40
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...

So are you saying that

http://facebook.github.io/relay/docs/graphql-relay-specifica...

no longer applies to Relay Modern? I can use any schema and Relay will just work?

Re: Relay Modern: Simpler, faster, more extensible

#45

Post by mjmahone17 »

ilovecaching wrote: post #44
mjmahone17 wrote: post #40

Earlier quoted context omitted.

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...

So are you saying that http://facebook.github.io/relay/docs/graphql-relay-specifica... no longer applies to Relay Modern? I can use any schema and Relay will just work?

Yes, mostly: if you don't meet the first requirement (having some sort of root field that allows you to refetch an object), you'll have trouble using, for example, RelayModern's RefetchContainer. If you don't meet the second requirement (a description of how to page through connections), you'll need to define how to paginate through connections as part of your component's logic (if that matters to you). And the third requirement: you no longer need to use Relay's imperative mutation API. You can simply describe a specific mutation to refetch, including all of the fields (i.e. via a fragment) that you want fetched every time you send that mutation (fat queries are gone in RelayModern).

Re: Relay Modern: Simpler, faster, more extensible

#46

Post by djmashko2 »

josephsavona wrote: post #43
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…

Thanks for the feedback! > but there's no mention of subscriptions or client-side state control The blog post didn't cover all the new features, but both of these use-cases are supported in Relay Modern - https://facebook.github.io/relay/docs/new-in-relay-modern.ht... GraphQL Subscriptions are supported: applications must inject a network layer that provides support for connecting to the server and receiving subscrip…

I'm excited to build an example with Relay Modern and the websocket subscriptions transport, should be really cool!

Re: Relay Modern: Simpler, faster, more extensible

#47

Post by leebyron »

StreamBright wrote: post #6

Is there any great libraries to implement the backend for GraphQL? I think the benefits of using GraphQL on the frontend are pretty obvious, however last time I checked I had trouble of finding good documentation or implementation on how to serve GraphQL requests from the backend point of view.

There are many great libraries for backends available in many different languages. Some resources to find one:

http://graphql.org/code/

https://github.com/chentsulin/awesome-graphql

Re: Relay Modern: Simpler, faster, more extensible

#48

Post by leebyron »

johntran wrote: post #29
jankassens wrote: post #3

Hey, 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 t…

Hi, I'm Lee from the GraphQL/Relay team

1. Reactiflux Q&A is a great idea, perhaps someone who organizes that can help set that up.

2. We're a pretty small team and our primary focus is building great software for Facebook and the larger community, so unfortunately our ability to focus on answering questions is relatively limited. Many people on the team occasionally hop into StackOverflow to answer questions, but we definitely can't make any guarantees about answering them all or answering them in a certain amount of time.

You can run relay-compiler as part of your webpack config as a pre-compile step. Also, if you want to run relay-compiler while you're iterating on your code, pass --watch and it will rerun whenever a file is saved.

Re: Relay Modern: Simpler, faster, more extensible

#49

Post by leebyron »

cainlevy wrote: post #24
foota wrote: post #20

Earlier 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?

Hi, I'm Lee from the GraphQL/Relay team

This technique of persisting the queries (and fragments) to the server at build time predates Relay - we've been using it on our iOS and Android apps since 2013.

At build time these clients submit their query strings to the server and get a small identifier in return which they can use at runtime to reference the whole query. This definitely means that old queries need to be kept around as long as the clients that use them are still active. Since iOS and Android apps seem to last forever, we're still getting traffic today from just about every version of our native apps we've ever shipped, even from 2012 and 2013. Because of this we decided to not bother with garbage collecting persisted queries, in terms of all the other data Facebook retains, persisted GraphQL queries is a grain of sand in a desert. However, with a bit more work, you could easily keep a hit counter per persisted query and go remove any persisted queries which had no recent hits.

Re: Relay Modern: Simpler, faster, more extensible

#50

Post by leebyron »

vidar wrote: post #39

Maybe I am way off base but "Colocation of data and view" reminds of awful PHP with SQL interspersed with HTML and CSS. Am I wrong?

Hi, Lee from the GraphQL/Relay team here

You're not off base at all! It's very similar to that. I think it's important to extract what was good and bad about this old website pattern.

The good is that within a single PHP file you could see both the logic for requesting data (SQL) AND the logic for rendering that data. This colocation was part of what made the early web take off, it was a great developer experience.

The bad is that these interspersed SQL statements were immediately invoked and blocking, which led to utterly awful performance.

One of the core ideas of Relay is that we wanted to bring back that developer experience of colocation while not only retaining good network performance, but actually creating opportunities for network optimization. When you see GraphQL in your Relay code, that is not a blocking immediately invoked network request. It's a description of a part of data needed. Relay aggregates these GraphQL fragments together to submit in few network requests in a non-blocking way to achieve the network performance we expect from modern mobile applications.

Post reply on HN