If you're going down the road of a React based SPA on top of a Rails API (and I'd question hard if you'll really benefit from that) do yourself a favour and just treat them as entirely separate applications. The backend deploys as you'll be used to with Rails, and the front-end can be built locally and then pushed to anywhere that'll serve some static HTML.
^^^ This. Unless you're building a CMS with a large and complicated administration UI, an SPA is probably overkill and will needlessly complicate your development process.
>>If you're going down the road of a React based SPA on top of a Rails API (and I'd question hard if you'll really benefit from that)
Why would you question it? At least my understanding is that there would be a noticeable performance benefit, since building HTML views on the server can contribute 150-300 ms to the overall responsiveness (or so I've read). I feel like React views would be a lot snappier.
Done right yes, it will feel a bit snappier, and you can integrate offline support without a huge amount of extra complexity on top of your SPA.
Sadly the trade-off currently is that your frontend is going to be far more complex to build than if you just rendered some HTML from Rails. You end up needing to duplicate your model layer in the frontend, debugging is harder because now the bugs are on the client side, which you have no access to after the fact, and integration testing becomes a very real challenge.
These are all surmountable problems, but they're not trivial, and in my opinion they're not worth it for a few hundred ms of response time, especially when you can get close to the speed ups offered with some judicious use of caching, Turbolinks, and a thin layer of JavaScript in the places it makes most sense.
