Live data from Hacker News

Relay Modern: Simpler, faster, more extensible

code.facebook.com

11–20 of 111 posts

Re: Relay Modern: Simpler, faster, more extensible

#11

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.

Sangria over on the Scala side is really nice. http://sangria-graphql.org/

Re: Relay Modern: Simpler, faster, more extensible

#13

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's a reasonable set of language specific libraries listed here: http://graphql.org/code/

Also a common pattern is wrapping an existing REST API with a GraphQL proxy: https://github.com/graphql/graphql-js

Re: Relay Modern: Simpler, faster, more extensible

#14

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

Congrats on the release. Could you summarize the pros and cons of picking Relay Modern vs Apollo Client?

Here is a detailed comparison between Apollo and Relay: https://www.graph.cool/docs/tutorials/relay-vs-apollo-iechu0...

(Note: This article hasn't been updated for Relay Modern yet but the main points are still the same.)

Re: Relay Modern: Simpler, faster, more extensible

#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 pruning?

Re: Relay Modern: Simpler, faster, more extensible

#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 mutations is a wonderful improvement, as is more granular control over the cache, but there'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).

That all said, this is an impressive release and congratulations to the team. We're committed to Relay and hope this release grows the community.

Re: Relay Modern: Simpler, faster, more extensible

#18

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.

For frontend developers who want to get started quickly, you can also use a hosted GraphQL service such as Graphcool: https://www.graph.cool

This approach abstracts all of the implementation details away and lets you focus on your GraphQL schema + implementing your business logic.

Disclaimer: I'm one of the founders of Graphcool. Happy to answer any kind of questions!

Re: Relay Modern: Simpler, faster, more extensible

#19

What are the differences between Apollo and Relay Modern at this point? Why/when should you choose one over the other?

Here is a detailed comparison between Apollo and Relay: https://www.graph.cool/docs/tutorials/relay-vs-apollo-iechu0...

(Note: This article hasn't been updated for Relay Modern yet but the main points are still the same.)

Re: Relay Modern: Simpler, faster, more extensible

#20

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…

I wouldn't say so, this has none of the maintenance implications that versioning does.
Post reply on HN