10 ms·

Learn Relay – A comprehensive introduction to Relay and GraphQL

124 points by schickling 10y ago

Jungberg 10y ago
Looks like a really well made introduction. I have been considering Relay for a while now. Will try it out. I especially like that I get a real GraphQL server to play around with. Thanks!
- schickling 10y ago
  Thanks Jungberg! One of the most common hurdles for frontend developers getting started with Relay (or GraphQL in general) is that you need to build a GraphQL backend first before you can do your first query and start building. That's why we've tried to make this as easy as possible by including a GraphQL server directly into the guide. Have you also seen the integrated GraphiQL and data browser?
  - acemarke 10y ago
    I've skimmed some of the GraphQL discussions and chatter, but my main question is actually much more on the server side. I'd love to see guides that cover setting up GraphQL APIs on top of existing datasets. Preferably more than just "use the official Node GraphQL library" or that PostGraphQL thing. In my case, we've got a bunch of Python services that currently offer up JSON APIs. I'd like to know what sort of changes and efforts would be needed to set up GraphQL endpoints for our systems. I think I've seen that there's a Python GraphQL library, but a lot more "how-to" info on the server side of things would be great.
    - e1g 10y ago
      Perhaps http://graphql.org/blog/rest-api-graphql-wrapper/ http://graphql.org/blog/rest-api-graphql-wrapper/ might be useful. Also the Apollo team has a good blog with many articles on the overall GraphQL architecture https://medium.com/apollo-stack https://medium.com/apollo-stack
    - morgante 10y ago
      Graphene is the Python library you're probably thinking of, and it's quite easy to work with and has pretty decent docs: http://docs.graphene-python.org/en/latest/ http://docs.graphene-python.org/en/latest/
    - sorenbs 10y ago
      I think there is a great opportunity in using GraphQL as a unifying entry point to legacy systems. In fact, when I talk to people at meetups and conferences, this is a topic that is almost always brought up. Companies that might have previously considered https://apigee.com https://apigee.com or one of their competitors now ask themselves whether they should rather adopt GraphQL instead. When thinking about building a GraphQL entry point there are 3 main areas you will have to consider: Performance, Authorization and Complexity. GraphQL is designed to be backed by arbitrary storage, so it would actually be feasible to have a bunch of GraphQL resolve functions that just call out to existing REST endpoints. To make this performant you need to implement a proper batching mechanism like DataLoader in node or Sangrias Deferred Resolver. If your existing api has automatically generated docs in a format like swagger you might even be able to generate the entire GraphQL schema from this :-)
- welder 10y ago
  Was just about to say the same thing after watching the video. Here is the relevant part showing the sandbox: https://youtu.be/EQcUmSEkr2Q?t=1m14s https://youtu.be/EQcUmSEkr2Q?t=1m14s
- morgante 10y ago
  You might also want to consider Apollo. [0] It's a really well-made GraphQL client that I found easier to use than Relay. [0] http://dev.apollodata.com/react/ http://dev.apollodata.com/react/
  - schickling 10y ago
    Very good point, morgante! One important thing to note here, is that Relay and Apollo are taking different approaches. Relay provides a great framework which works excellent for a lot of use cases and provides the most convenient and robust solution for that. In some cases you want to "break out" of that framework and be more in control how data is fetched or mutated. In that case Apollo is a fantastic choice as well. Especially in combination with Redux. Fun fact: We're actually using both - Relay AND Apollo - in our dashboard at Graphcool. Feel free to take a look at the source here: https://github.com/graphcool/dashboard https://github.com/graphcool/dashboard On a side note: We're already working on a similar project but focussed on Apollo. If you're interested in getting involved, we're still looking for collaborators: https://github.com/learnapollo https://github.com/learnapollo
sorenbs 10y ago
Hey! We found it to be very difficult to get started with Relay. At Graphcool we are building the dashboard, a core component of our product with Relay, so we had to become experts. Now we have turned this into (what we hope to be) a compelling getting started tutorial. We would love to get some feedback, and if you have any questions about Relay or GraphQL in general I'm happy to answer. :)
tiglionabbit 10y ago
I'll read this when I get the chance. Perhaps I'll give Relay another chance. I also found Relay a nightmare to understand. Everything is overcomplicated and messy, which is probably why they're talking about Relay 2.0 already. I was a bit frustrated when I found that this blog post was the most helpful piece of information I could find on Relay, and it tells you to just use FIELDS_CHANGE everywhere and ignore the rest of the mutation config features: http://blog.pathgather.com/blog/a-beginners-guide-to-relay-mutations http://blog.pathgather.com/blog/a-beginners-guide-to-relay-m... . Some things that make Relay frustrating: * Pointless restrictions on what you're allowed to do at the "root" require you to do everything under a "viewer" subnode instead. * Relay "Routers" are completely pointless and should be removed. * Mutation configs are totally confusing, and they're tightly coupled to the server-side implementation of the mutation. We have a compile step where the client inspects the schema that was generated by the server. Why can't we generate the mutation configs as well? I know there's probably not enough declarative information readily available, but there should be. * Relay mutations are only allowed to have one input field and one output field in the GraphQL definition. This is a pointless incompatibility between Relay and non-Relay GraphQL endpoints. Falcor also exists, and is much simpler, though it has its upsides and downsides: * You're not allowed to pass any arguments other than the standard from/to pagination arguments. Want to implement faceted search? Too bad. It's "Not a querying language", for some reason. * It has something called "calls" which are basically the same thing as Relay's mutations but you have a little less control over how cache invalidation is handled than you do with mutation configs. There's no RANGE_ADD, for example. To add/remove items in a list you have to invalidate the entire list. Maybe that's OK though? But it sure is annoying if you're trying to move an item from one list to another on the client side and don't need to wait for the server to catch up. * No built-in support for optimistic updates yet. One thing I see in common between React and Falcor is they are both rather complex ways to collaborate with yourself while ignoring events from the outside world. In other words, it's a lot of work to not have pubsub. I guess this is because pubsub doesn't scale? But in the mean time, I'm tempted to play around with Horizon instead.
- djmashko2 10y ago
  Have you checked out Apollo Client? It's an alternative to Relay that works with all GraphQL servers and brings in a lot of the simplicity of Falcor: http://dev.apollodata.com/ http://dev.apollodata.com/ It includes features like optimistic UI, easy ways to invalidate cache after mutations, arbitrary pagination models, and more. (Disclaimer: I work on Apollo)
scottmf 10y ago
Awesome. Do you have anything regarding server implementation?
- schickling 10y ago
  Thanks for your feedback scottmf! We're mostly working with frontend developers and trying to simplify their workflows as much as possible. One of the first and most important steps are great learning resources. That's why we're focussing for now on frontend technologies such as Relay, Apollo, ... We'd be more than happy to share some insights on what we've learned while building Graphcool. The best way going forward will be following our blog: https://blog.graph.cool/ https://blog.graph.cool/ Also, feel free to join our Slack in case you have any questions: https://slack.graph.cool/ https://slack.graph.cool/
robinricard 10y ago
Disclaimer: I'm a contributor to Apollo [0], an alternative client to Relay. This is a great initiative! I remember struggling to learn Relay, I love it though, used it in some toy apps and will use it in some upcoming projects that I have. However I have a few issues with Relay: the main one is that it overall discourages people from starting with GraphQL. From creating a Relay-compliant GraphQL server to adding it to your app, Relay forces you to good conventions that, unfortunately, requires you to learn about its concepts and makes it super difficult to ramp up fast. For anyone interested in working with Relay and GraphQL in general, I would advise you to start first with just learning GraphQL, without Relay and its constraints. You'll see that much of the issues you may have with GraphQL may come from actually trying to comply to Relay. Once you are okay with GraphQL, then, you can move to learning Relay. Finally, I want to insist on the fact that GraphQL is just a specified language that can be consumed by any client you need/want. Relay is made by Facebook, for Facebook, which is a cool thing but may be a bit too much for your simple app or may not be adapted if you are migrating a legacy app to GraphQL (which was my case). That's why you should take a look to alternative clients as well (Apollo [0] for instance ;-) )! [0] http://dev.apollodata.com/ http://dev.apollodata.com/
- schickling 10y ago
  Thanks Robin! I've love what you guys are doing at Apollo! I've just answered a similar question below, so I'll just copy the most important bits here as well: One important thing to note here, is that Relay and Apollo are taking different approaches. Relay provides a great framework which works excellent for a lot of use cases and provides the most convenient and robust solution for that. In some cases you want to "break out" of that framework and be more in control how data is fetched or mutated. In that case Apollo is a fantastic choice as well. Especially in combination with Redux. Fun fact: We're actually using both - Relay AND Apollo - in our dashboard at Graphcool. Feel free to take a look at the source here: https://github.com/graphcool/dashboard https://github.com/graphcool/dashboard On a side note: We're already working on a similar project but focussed on Apollo. If you're interested in getting involved, we're still looking for collaborators: https://github.com/learnapollo https://github.com/learnapollo
  - 10y ago

124 points by schickling 10y ago

Looks like a really well made introduction. I have been considering Relay for a while now. Will try it out. I especially like that I get a real GraphQL server to play around with. Thanks!

schickling 10y ago
Thanks Jungberg! One of the most common hurdles for frontend developers getting started with Relay (or GraphQL in general) is that you need to build a GraphQL backend first before you can do your first query and start building. That's why we've tried to make this as easy as possible by including a GraphQL server directly into the guide. Have you also seen the integrated GraphiQL and data browser?
- acemarke 10y ago
  I've skimmed some of the GraphQL discussions and chatter, but my main question is actually much more on the server side. I'd love to see guides that cover setting up GraphQL APIs on top of existing datasets. Preferably more than just "use the official Node GraphQL library" or that PostGraphQL thing. In my case, we've got a bunch of Python services that currently offer up JSON APIs. I'd like to know what sort of changes and efforts would be needed to set up GraphQL endpoints for our systems. I think I've seen that there's a Python GraphQL library, but a lot more "how-to" info on the server side of things would be great.
  - e1g 10y ago
    Perhaps http://graphql.org/blog/rest-api-graphql-wrapper/ http://graphql.org/blog/rest-api-graphql-wrapper/ might be useful. Also the Apollo team has a good blog with many articles on the overall GraphQL architecture https://medium.com/apollo-stack https://medium.com/apollo-stack
  - morgante 10y ago
    Graphene is the Python library you're probably thinking of, and it's quite easy to work with and has pretty decent docs: http://docs.graphene-python.org/en/latest/ http://docs.graphene-python.org/en/latest/
  - sorenbs 10y ago
    I think there is a great opportunity in using GraphQL as a unifying entry point to legacy systems. In fact, when I talk to people at meetups and conferences, this is a topic that is almost always brought up. Companies that might have previously considered https://apigee.com https://apigee.com or one of their competitors now ask themselves whether they should rather adopt GraphQL instead. When thinking about building a GraphQL entry point there are 3 main areas you will have to consider: Performance, Authorization and Complexity. GraphQL is designed to be backed by arbitrary storage, so it would actually be feasible to have a bunch of GraphQL resolve functions that just call out to existing REST endpoints. To make this performant you need to implement a proper batching mechanism like DataLoader in node or Sangrias Deferred Resolver. If your existing api has automatically generated docs in a format like swagger you might even be able to generate the entire GraphQL schema from this :-)
welder 10y ago
Was just about to say the same thing after watching the video. Here is the relevant part showing the sandbox: https://youtu.be/EQcUmSEkr2Q?t=1m14s https://youtu.be/EQcUmSEkr2Q?t=1m14s
morgante 10y ago
You might also want to consider Apollo. [0] It's a really well-made GraphQL client that I found easier to use than Relay. [0] http://dev.apollodata.com/react/ http://dev.apollodata.com/react/
- schickling 10y ago
  Very good point, morgante! One important thing to note here, is that Relay and Apollo are taking different approaches. Relay provides a great framework which works excellent for a lot of use cases and provides the most convenient and robust solution for that. In some cases you want to "break out" of that framework and be more in control how data is fetched or mutated. In that case Apollo is a fantastic choice as well. Especially in combination with Redux. Fun fact: We're actually using both - Relay AND Apollo - in our dashboard at Graphcool. Feel free to take a look at the source here: https://github.com/graphcool/dashboard https://github.com/graphcool/dashboard On a side note: We're already working on a similar project but focussed on Apollo. If you're interested in getting involved, we're still looking for collaborators: https://github.com/learnapollo https://github.com/learnapollo

sorenbs 10y ago

Hey! We found it to be very difficult to get started with Relay. At Graphcool we are building the dashboard, a core component of our product with Relay, so we had to become experts. Now we have turned this into (what we hope to be) a compelling getting started tutorial. We would love to get some feedback, and if you have any questions about Relay or GraphQL in general I'm happy to answer. :)

tiglionabbit 10y ago

I'll read this when I get the chance. Perhaps I'll give Relay another chance. I also found Relay a nightmare to understand. Everything is overcomplicated and messy, which is probably why they're talking about Relay 2.0 already. I was a bit frustrated when I found that this blog post was the most helpful piece of information I could find on Relay, and it tells you to just use FIELDS_CHANGE everywhere and ignore the rest of the mutation config features: http://blog.pathgather.com/blog/a-beginners-guide-to-relay-mutations http://blog.pathgather.com/blog/a-beginners-guide-to-relay-m... . Some things that make Relay frustrating: * Pointless restrictions on what you're allowed to do at the "root" require you to do everything under a "viewer" subnode instead. * Relay "Routers" are completely pointless and should be removed. * Mutation configs are totally confusing, and they're tightly coupled to the server-side implementation of the mutation. We have a compile step where the client inspects the schema that was generated by the server. Why can't we generate the mutation configs as well? I know there's probably not enough declarative information readily available, but there should be. * Relay mutations are only allowed to have one input field and one output field in the GraphQL definition. This is a pointless incompatibility between Relay and non-Relay GraphQL endpoints. Falcor also exists, and is much simpler, though it has its upsides and downsides: * You're not allowed to pass any arguments other than the standard from/to pagination arguments. Want to implement faceted search? Too bad. It's "Not a querying language", for some reason. * It has something called "calls" which are basically the same thing as Relay's mutations but you have a little less control over how cache invalidation is handled than you do with mutation configs. There's no RANGE_ADD, for example. To add/remove items in a list you have to invalidate the entire list. Maybe that's OK though? But it sure is annoying if you're trying to move an item from one list to another on the client side and don't need to wait for the server to catch up. * No built-in support for optimistic updates yet. One thing I see in common between React and Falcor is they are both rather complex ways to collaborate with yourself while ignoring events from the outside world. In other words, it's a lot of work to not have pubsub. I guess this is because pubsub doesn't scale? But in the mean time, I'm tempted to play around with Horizon instead.

djmashko2 10y ago
Have you checked out Apollo Client? It's an alternative to Relay that works with all GraphQL servers and brings in a lot of the simplicity of Falcor: http://dev.apollodata.com/ http://dev.apollodata.com/ It includes features like optimistic UI, easy ways to invalidate cache after mutations, arbitrary pagination models, and more. (Disclaimer: I work on Apollo)

scottmf 10y ago

Awesome. Do you have anything regarding server implementation?

schickling 10y ago
Thanks for your feedback scottmf! We're mostly working with frontend developers and trying to simplify their workflows as much as possible. One of the first and most important steps are great learning resources. That's why we're focussing for now on frontend technologies such as Relay, Apollo, ... We'd be more than happy to share some insights on what we've learned while building Graphcool. The best way going forward will be following our blog: https://blog.graph.cool/ https://blog.graph.cool/ Also, feel free to join our Slack in case you have any questions: https://slack.graph.cool/ https://slack.graph.cool/

robinricard 10y ago

Disclaimer: I'm a contributor to Apollo [0], an alternative client to Relay. This is a great initiative! I remember struggling to learn Relay, I love it though, used it in some toy apps and will use it in some upcoming projects that I have. However I have a few issues with Relay: the main one is that it overall discourages people from starting with GraphQL. From creating a Relay-compliant GraphQL server to adding it to your app, Relay forces you to good conventions that, unfortunately, requires you to learn about its concepts and makes it super difficult to ramp up fast. For anyone interested in working with Relay and GraphQL in general, I would advise you to start first with just learning GraphQL, without Relay and its constraints. You'll see that much of the issues you may have with GraphQL may come from actually trying to comply to Relay. Once you are okay with GraphQL, then, you can move to learning Relay. Finally, I want to insist on the fact that GraphQL is just a specified language that can be consumed by any client you need/want. Relay is made by Facebook, for Facebook, which is a cool thing but may be a bit too much for your simple app or may not be adapted if you are migrating a legacy app to GraphQL (which was my case). That's why you should take a look to alternative clients as well (Apollo [0] for instance ;-) )! [0] http://dev.apollodata.com/ http://dev.apollodata.com/

schickling 10y ago
Thanks Robin! I've love what you guys are doing at Apollo! I've just answered a similar question below, so I'll just copy the most important bits here as well: One important thing to note here, is that Relay and Apollo are taking different approaches. Relay provides a great framework which works excellent for a lot of use cases and provides the most convenient and robust solution for that. In some cases you want to "break out" of that framework and be more in control how data is fetched or mutated. In that case Apollo is a fantastic choice as well. Especially in combination with Redux. Fun fact: We're actually using both - Relay AND Apollo - in our dashboard at Graphcool. Feel free to take a look at the source here: https://github.com/graphcool/dashboard https://github.com/graphcool/dashboard On a side note: We're already working on a similar project but focussed on Apollo. If you're interested in getting involved, we're still looking for collaborators: https://github.com/learnapollo https://github.com/learnapollo
- 10y ago