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/

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

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

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?

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.

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 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 :-)

Perhaps 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

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/

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