I'm learning Ruby on Rails coming from Node.js/express and had a few design questions. I used React.js for the frontend in my Node apps and I'm planning on continuing to do so in my Rails apps.
What I was doing in Node.js
Have all requests starting with
/ be handled by a "view router". This essentially serves all the HTML and any injected JSON. For example:
mywebsite.com/profile will serve HTML of the user's profile.
Have any requests starting with
/api be handled by an "API router". This had the REST API routes to access resources.
GET mywebsite.com/api/profile serves the JSON for the profile.
The React app loaded in
profile.html for example would make an HTTP request to
GET mywebsite.com/api/profile and populate the view. (Of course, I could've just injected the profile via EJS, but this is an example use case)
Note that both these routers were running on the same server/IP
What I'm thinking of doing with Rails
I'm planning to build more complex apps that have both a web client, and native mobile clients. This means that I will need a stateless REST server. I read this guide about generating an "API only" Rails app which got me thinking about making the REST API its own server, maybe under
api.mywebsite.com and have all the views be served from
mywebsite.com. The former would be an API only Rails app, and the latter would be a normal Rails app that serves views.
Also, as a side question, I was reading the rails-react Doctrine and was having trouble finding some downsides. If someone with knowledge of it can provide the other side of the story, it would be much appreciated!
For an app that could potentially get complicated and have to scale, is decoupling the REST API and the View a good idea? What do companies like Twitter and Github (both use or used to use Rails I believe) do?