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

51–60 of 111 posts

Re: Relay Modern: Simpler, faster, more extensible

#51

Post by leebyron »

pducks32 wrote: post #21

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.

Hi, Lee from the GraphQL/Relay team.

To clarify a bit: we've removed fields from and changed our database schema repeatedly over the years. In fact we've migrated between entire database technologies multiple times over.

What we haven't done is remove fields from our GraphQL API when those fields are still in use by shipped iOS, Android, or web apps.

GraphQL gives us a layer of abstraction to create consistency from the point of view of client apps while allowing iteration of backend services.

Re: Relay Modern: Simpler, faster, more extensible

#52

Post by leebyron »

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…

Whoa, awesome write up!

This is a pretty good distillation of some differences, but I just wanted to reiterate that I'm more excited about the similarities. Having options for what tools to use along with GraphQL is a great thing, and even better is when the best ideas make their way into many of them.

Re: Relay Modern: Simpler, faster, more extensible

#53

Post by linkmotif »

mjmahone17 wrote: post #45
ilovecaching wrote: post #44

Earlier quoted context omitted.

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…

Did you mean "declarative mutation API"?

Re: Relay Modern: Simpler, faster, more extensible

#54

Post by jankassens »

RaitoBezarius wrote: post #33
jankassens wrote: post #3

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

Thanks Jan, what are the remaining pain points to your opinion with the usage of Relay in a modern web app?

We've moved from runtime generation of queries to 100% of queries generated at compile time to remove a large chunk of computation out of runtime. Some APIs got more complicated to use than I'd like to. For example, pagination currently requires developers to write an explicit query to fetch more entries. Now with performance in good shape, I want to focus on improving the developer experience again in a way that doesn't sacrifice runtime speed. For example for pagination, we should in most cases be able to synthesize a query at compile time instead of asking for an explicit query.

Re: Relay Modern: Simpler, faster, more extensible

#55

Post by linkmotif »

voxmatt wrote: post #22
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?

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

> Plus, ultimately, Relay is backed by Facebook and used in Facebook applications, in production, so it's not going anywhere.

That's why I went with a Relay too. But I have a feeling that Relay will not be long for this world. I just feel it in my bones.

Re: Relay Modern: Simpler, faster, more extensible

#56

Post by staticassertion »

cies wrote: post #34
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. 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++/Ja…

Last time I looked at reason it was totally new and there was no tooling etc. I got little support from the gitter or whatever it was.

Have things changed? It really interested me at the time.

Re: Relay Modern: Simpler, faster, more extensible

#58

Post by voxmatt »

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…

Awesome!

Re: Relay Modern: Simpler, faster, more extensible

#59

Post by rattray »

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.

Why?

Post reply on HN