Relay Modern: Simpler, faster, more extensible

Struck by this para:<p>&quot;The native app teams discovered that using GraphQL came with the additional overhead of building queries by concatenating a bunch of strings and then uploading those queries over slow connections. These queries could sometimes grow into the tens of thousands of lines of GraphQL. Also, every mobile device running the same app was sending largely the same queries.<p>The teams realized that if the GraphQL queries instead were statically known — that is, they were not altered by runtime conditions — then they could be constructed once during development time and saved on the Facebook servers, and replaced in the mobile app with a tiny identifier. With this approach, the app sends the identifier along with some GraphQL variables, and the Facebook server knows which query to run. No more overhead, massively reduced network traffic, and much faster mobile apps.&quot;<p>Firstly, what query could be 10k lines? Secondly, if you&#x27;re defining the query just by an id, how is that then any different to a fixed REST endpoint or stored procedure?

Exciting to see! I&#x27;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).<p>I&#x27;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.<p>Simpler, more explicit mutations is a wonderful improvement, as is more granular control over the cache, but there&#x27;s no mention of subscriptions or client-side state control (using Redux on top of Relay is... doable, but not as elegant as one might hope for).<p>That all said, this is an impressive release and congratulations to the team. We&#x27;re committed to Relay and hope this release grows the community.

Congrats! 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.<p>( <a href="http:&#x2F;&#x2F;artsy.github.io&#x2F;blog&#x2F;2017&#x2F;02&#x2F;05&#x2F;Retrospective-Swift-at-Artsy&#x2F;#Better.Abstractions..Better.Developer.Experience" rel="nofollow">http:&#x2F;&#x2F;artsy.github.io&#x2F;blog&#x2F;2017&#x2F;02&#x2F;05&#x2F;Retrospective-Swift-a...</a> )

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.

It seems many people loved GraphQL, a powerful and elegant concept, but then had a rude awakening with Relay as an overly complex, unwieldy, buzz kill.<p>Node, edge, and viewer are terrible mistakes w.r.t. naming and usability. I&#x27;m sure it&#x27;s very intuitive for FB devs to think in these terms, but the words are specific to a problem domain and just don&#x27;t translate as well to the general case as other choices might have.

Hey, Jan here together with Lee from the Relay team. Happy to answer your questions.

Seriously, your own homegrown garbage collection inside the js runtime? I looked at React the first time it came out and aside from the insanity of using xml mixed with javascript or some kind of pseudo js, it was waaaay too complex. I dont know but it seems crazy to me to write applications like that, it makes xaml look decently simple.

What are the differences between Apollo and Relay Modern at this point?<p>Why&#x2F;when should you choose one over the other?

&gt; &quot;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&quot;<p>Could we go ahead and implement proper caching as HTTP would do: expiration date per field&#x2F;models, then eviction based on expiration dates? With an optional max cache size using LIFO, last used or the current model.<p>That way we don&#x27;t need to refetch data if the API is set up to cache. It&#x27;s sort of frustrating that staleness is just defacto ignored by UI right now.

My biggest gripe with the original Relay was that it didn&#x27;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 &#x27;simpler&#x27;, but I don&#x27;t see anything about relaxing the constraints on my graphql schema.

I&#x27;d be interested to read an analysis of how this compares to the backends-for-frontends pattern.<p>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 pruning?

I&#x27;m curious how this compares to Apollo Client 1.0 which was released this week

Still can&#x27;t see anything about making server-side rendering a first class citizen for relay :(.

I&#x27;ve been somewhat out of the Clojurescript loop recently, but this looks conceptually a lot like the om.next model (&quot;colocated queries&quot;).<p>Makes me curious how many people are using om.next in anger. It&#x27;s always seemed like a good idea (and now with some extra endorsement for the core principle), but judging by GitHub activity (which I realise isn&#x27;t a perfect measure), the project seems to have rather lost momentum.

I&#x27;m super excited about this release! Great work Jan, Lee, Joe and everybody else who was working on this! :)<p>At Graphcool (<a href="https:&#x2F;&#x2F;www.graph.cool&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.graph.cool&#x2F;</a>) we were using Relay since the very beginning. It has enabled us to build frontend products at an incredible speed and while staying confident about the data layer. For instance our entire console is written using Relay at its core. (It&#x27;s open-source btw: <a href="https:&#x2F;&#x2F;github.com&#x2F;graphcool&#x2F;console" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;graphcool&#x2F;console</a>)<p>PS: We&#x27;re also the authors of Learn Relay (<a href="https:&#x2F;&#x2F;www.learnrelay.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.learnrelay.org&#x2F;</a>) which we&#x27;ll update to Modern Relay soon!

I work at Facebook and had the chance to use Relay Modern for an upcoming product. Was really happy with the performance and collocation of data and view just amazing. Love it :) BTW I realized where Relay&#x27;s logo came from by chance while fiddling around with PowerPoint&#x27;s new Morph transitions... <a href="https:&#x2F;&#x2F;gfycat.com&#x2F;EnviousBothFinch" rel="nofollow">https:&#x2F;&#x2F;gfycat.com&#x2F;EnviousBothFinch</a>

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.

Edit: Nevermind, this has already been answered.<p>Anyone have insight on relay modern vs apollo?<p><a href="http:&#x2F;&#x2F;www.apollodata.com" rel="nofollow">http:&#x2F;&#x2F;www.apollodata.com</a>

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

Congrats on the release of Relay Modern guys! This has been a long awaited moment :)

How is it that they make an announcement like this without any actual code in it?

One of the things that I&#x27;ve noticed about the javascript community is that they&#x27;re re-inventing stuff from previous technologies - sometimes badly - but almost always with a willful ignorance of what has gone before.<p>While this doesn&#x27;t look like a bad idea - what they&#x27;ve done is to re-invent stored procedures. Back in the original object orientated wars this turned out to be a mixed blessing. You could get quite sharp performance, but reasoning about the application logic became harder. It might be nice if this kind of issue was at least acknowledged in the article.