Reputation: 376
My server side is rails and I'm using react-rails with server side rendering (prerender: true). Recently started using relay with react-router-relay but with that, server side rendering is no longer possible, as apparently fetching the data involves communicating with the graphql server which involves timeouts, etc which are not available when server rendering. So I guess there must be a way to pre-inject the data into the relay store on the server side to avoid calling graphql. I found this library: https://github.com/denvned/isomorphic-relay-router, but I cannot use it as it is not compatible with the use of react-rails (e.g. I don't have app.get anywhere in my app so there is no place to use that match function mentioned there). Any idea on how to make this work?
Upvotes: 0
Views: 570
Reputation: 5148
We ran into a similar problem. See our implementation of how we got it to work with rails. Although I would not recommend doing it...
Check this out: https://github.com/brandfolder/rails-graphql-relay
UPDATE:
We ran into a number of issues with the blocking nature of ruby. To get around this we had to hack together a solution wherein we were shelling out to node as part of our app.
What we did instead is build 3 applications:
1) A JSONAPI compliant public API that encapsulates all of our business logic. https://api.brandfolder.com/v2/docs built on https://github.com/brandfolder/jsonapionify
2) A GraphQL server that speaks to our JSON API. Note: I highly recommend express-graphql (node). Because of the asynchronous/non-blocking nature of node, express-graphql is able to make multiple calls to our API at once, rather than blocking in ruby. https://github.com/brandfolder/graphqlify
3) A App that serves our React/Relay application. This is simply an asset pipeline with browserify to serve up our react code. This also contains the code to handle our server side rendering using ReactDOMServer. [private repository]
This is probably a more complex example than you are looking for, but this allows use to run a highly available performant production application. IN your case, you could easily get away with having 2 apps, the GraphQL server and the front end code. This will allow the front end to compile without having to worry about a backend blocking GraphQL server in ruby.
Upvotes: 4