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

101–110 of 111 posts

Re: Relay Modern: Simpler, faster, more extensible

#101

Post by andrewingram »

acjohnson55 wrote: post #97
andrewingram wrote: post #83

Earlier quoted context omitted.

I feel you're being disingenuous here. They're just talking about automatic cache eviction, which wasn't possible/trivial with the previous version of Relay.

I agree with you. But given the announcements own terminology, I think the misunderstanding is understandable.

I think the terminology is fair, given that I believe it uses a reference-counting mechanism to determine whether cached data is currently being used by a mounted component. But it's not quite as crazy as "JavaScript's GC sucks, we're inventing our own".

Re: Relay Modern: Simpler, faster, more extensible

#102

Post by theprotocol »

gavinpc wrote: post #96
theprotocol wrote: post #81

Earlier quoted context omitted.

I still firmly believe riot.js ( http://riotjs.com/ ) is the best "react-like" tool even though it's almost entirely unknown (sadly) and its website/PR/general presentation is a bit janky. It's essentially a very very tiny, minimally opinionated structural layer that lets you build html components (called "tags") using almost entirely vanilla JS. It inverts the JSX paradigm: where JSX is "html in the middle of your c…

Several points of agreement here, and now I'll have to check out Riot (which I remember seeing around here a while ago). But I think that > html in the middle of your code is selling JSX a bit short. Tooling and coupling aside (and I agree those are strikes against it), JSX creates a pair of mutually-recursive , formally-defined languages, which you can switch between freely and frictionlessly. I've never seen this b…

Thanks for the insightful response. I think you make a compelling case, and it's something I'll be thinking about (I've gone back and forth regarding what to think about JSX).

In the specific use case of React and Riot, I feel like it's more natural to have markup be the main structure and code to complement it, rather than the other way around, but I don't feel that strongly about it and I find React's approach is still not too bad (imho of course).

I tend to get a bit of an "overly academic" or "cargo cultish" sort of vibe from designs I consider overwrought, and I had a little bit of that sentiment about React back when I worked it, but really it was not a very strong feeling and I'm convinced React is pretty great.

The one that really gives me that vibe is Angular. No offense to anyone who likes/uses Angular, but I view it as a criminal case of abstraction run amok.

Re: Relay Modern: Simpler, faster, more extensible

#103

Post by marcosscriven »

Struck by this para:

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

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

Firstly, what query could be 10k lines? Secondly, if you're defining the query just by an id, how is that then any different to a fixed REST endpoint or stored procedure?

Re: Relay Modern: Simpler, faster, more extensible

#104

Post by naked-ferret »

marcosscriven wrote: post #103

Struck by this para: "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. The teams realized that if the Gr…

This is the most hilarious part of the post. I'm glad someone else caught that too!

Re: Relay Modern: Simpler, faster, more extensible

#105

Post by acjohnson55 »

marcosscriven wrote: post #103

Struck by this para: "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. The teams realized that if the Gr…

A 10k line query is pretty easy for me to imagine. In GraphQL, every property you want on every object is a line, since you query by property, not by object. In an interface with a whole bunch of widgets, I can imagine it really adding up.

It _is_ pretty much like a stored procedure. But I don't think that's inherently a bad thing at all. The procedures are effectively version controlled right within your application code, and I'm guessing they're persisted at deploy-time.

Re: Relay Modern: Simpler, faster, more extensible

#106

Post by marcosscriven »

acjohnson55 wrote: post #105
marcosscriven wrote: post #103

Struck by this para: "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. The teams realized that if the Gr…

A 10k line query is pretty easy for me to imagine. In GraphQL, every property you want on every object is a line, since you query by property, not by object. In an interface with a whole bunch of widgets, I can imagine it really adding up. It _is_ pretty much like a stored procedure. But I don't think that's inherently a bad thing at all. The procedures are effectively version controlled right within your application…

But I thought the headline feature of GraphQL was that the client could choose the shape of the response, hence all those properties. Even then, ten thousand properties seems a huge amount, even for a rich single page app.

If you end up putting that on the server anyway, you're back to fixed responses, no better than a REST API.

Re: Relay Modern: Simpler, faster, more extensible

#107

Post by acjohnson55 »

marcosscriven wrote: post #106
acjohnson55 wrote: post #105

Earlier quoted context omitted.

A 10k line query is pretty easy for me to imagine. In GraphQL, every property you want on every object is a line, since you query by property, not by object. In an interface with a whole bunch of widgets, I can imagine it really adding up. It _is_ pretty much like a stored procedure. But I don't think that's inherently a bad thing at all. The procedures are effectively version controlled right within your application…

But I thought the headline feature of GraphQL was that the client could choose the shape of the response, hence all those properties. Even then, ten thousand properties seems a huge amount, even for a rich single page app. If you end up putting that on the server anyway, you're back to fixed responses, no better than a REST API.

I guess you mean like a RESTish "super-endpoint", that aggregates a whole bunch of data? Because operationally, it would be really different than making a thousand idiomatically REST queries over a hypermedia API.

If so, there's still a huge difference. In the REST super-endpoint world, you have to modify your API service to suit the desires of individual clients. In GraphQL, the client controls the shape of the query. The detail that the client is sending that query at deploy-time, instead of request-time, doesn't change that.

This also recognizes that queries tend to be parametric, but not fully dynamic. That's kind of built-in to Relay, since the fragments are statically attached to React components.

It's more akin to HTTP caching, to me.

Re: Relay Modern: Simpler, faster, more extensible

#108

Post by voxmatt »

rattray wrote: post #59
voxmatt wrote: post #23

Earlier quoted context omitted.

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

Because I use Typescript! Joking aside though (although, let's be honest, there is some straight-up selfishness: I use TS and if Facebook did, my life would be easier), I think adding types to Javascript is a huge win no matter how its accomplished and it just so happens that TS seems to be gaining more community support than Flow. Flow's support is almost exclusively from the React community because of Facebook. If Facebook would switch to TS, the whole community could coalesce around one standard. That would have huge benefits.

Re: Relay Modern: Simpler, faster, more extensible

#109

Post by josephsavona »

Meai wrote: post #80

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.

Hey! I'm Joe and work on the Relay core team.

These are good questions: why does Relay Modern have garbage collection? Is that just a fancy name for cache eviction?

Let's put aside naming for a moment. Relay stores GraphQL data in normalized form, as a map of global identifiers to records. Each record has an identifier, type, and map of fields to values. Relationships between objects are expressed as fields that "link" to other records. These links are expressed as data structures - an object such as `{__ref: }` - as opposed to direct references to the objects.

Using object references would mean that Relay could in theory let the JS runtime do garbage collection: except that the runtime would only see a cyclic graph of objects for which (typically) at least one root object had a persistent reference (the record corresponding to the root of the graph). In other words, it would do its job and retain all records in memory since they would all be (in)directly referenced from the root object, which would have to be referenced by Relay in order to access the data.

Relay, however, has more knowledge than the JS runtime does about how this data can be accessed: it can analyze the currently active queries against the object graph to determine which records are required to fulfill those queries. This is what the garbage collection feature does: remove records that may not be referenced by any active query.

Note that this has some aspects in common with standard garbage collection in programming language runtimes. There is a mapping of identifiers (memory addresses) to values. Each value may contain links (pointers) to other records (blocks of memory). Because the graph has cyclic references, standard cache eviction strategies - LIFO, LRU, etc - don't necessarily apply as they might evict data that is still referenced.

I hope this helps shed some light on this feature. Questions and suggestions (PRs) welcome!

Re: Relay Modern: Simpler, faster, more extensible

#110

Post by aj0strow »

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 read architecture.md in the runtime package and it looks perfect for binding websocket updates into components. I was really hoping for the following example:

* create a stand-alone relay store

* query and subscribe to changes, print to console

* imperatively push updated records into store

* see updated data in console

I assume this is possible, but maybe it's not? Or you need a graphql server or container component?

Post reply on HN