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.
Relay Modern: Simpler, faster, more extensible
11–20 of 111 posts
Re: Relay Modern: Simpler, faster, more extensible
#12Hey, Jan here together with Lee from the Relay team. Happy to answer your questions.
Re: Relay Modern: Simpler, faster, more extensible
#13Is 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.
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
#14Hey, 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?
(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
#15Why/when should you choose one over the other?
Re: Relay Modern: Simpler, faster, more extensible
#16Also, 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
#17I'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
#18Is 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.
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
#19What are the differences between Apollo and Relay Modern at this point? Why/when should you choose one over the other?
(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
#20I'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…