[enraged_camel]

Yeah, I actually know both Rails and React, and have built stuff with them separately. I understand they would talk to each other using JSON and don't need to be "aware" of each other.

The main thing that I find confusing is the build/deployment process of a Rails application that uses React as the front-end. For example, let's say that I develop a Rails/React app and want to deploy it. Do I run webpack first to transpile the React app to "regular" JavaScript, then git commit, then push to Heroku? Or does Heroku do that for me? Also, how does the Rails asset pipeline come into play? Any special configurations? Etc.

[jon-wood]

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.

[pault]

^^^ 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.

[enraged_camel]

Ah, gotcha. Thanks, that makes sense.

>>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.

[jon-wood]

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.

[reitanqild]

Meh.

Mostly JS frontends are just for annoying grumpy oldtimers like us here at HN.

Seriously: unless you have a serious good reason for depending on JS in the frontend then keep it to progressive enhancements: autocomplete etc.

[pault]

Webpack and the asset pipeline overlap in responsibility, so you probably want to stick with one or the other. There may be some edge cases that I don't know about where you might want functionality from both, though.

I personally use webpack and transpile/bundle all the javascript and styles into a `build` directory that gets served by nginx.

For my side projects, I use a really simple express server with a single handler for all routes that pre-renders the react app and sends it down to the client for rehydration. After that, the client takes over and sends requests directly to the api server (rails in this case). Your boilerplate setup is an nginx reverse proxy that forwards all requests to /api/* to the rails server, and everything else goes to the express server.

For easy reproduction, you can use a docker cluster with a configuration something like this:

    version: "2"
    services:
      www:
        image: "nginx:1.10.1"
        restart: "always"
        volumes:
          - "./node/dist:/usr/share/nginx/html/dist"
          - "./nginx/default.conf:/etc/nginx/conf.d/default.conf"
        ports:
         - "8080:80"
        links:
          - "app:app"
          - "api:api"
        container_name: "react-rails_www"
      app:
        build:
          context: "."
          dockerfile: "Dockerfile-node"
        image: "username/react-redux:0.0.1"
        volumes:
          - "./node:/home/app/src"
        ports:
          - "3001"
        container_name: "react-rails_app"
        command: "npm start"
      db:
        image: "postgres"
        container_name: "react-rails_db"
      api:
        build:
          context: "."
          dockerfile: "Dockerfile-rails"
        command: "bundle exec rails s -p 3000 -b '0.0.0.0'"
        volumes:
          - "./rails:/home/app/src"
        ports:
          - "3000"
        depends_on:
          - "db"
        container_name: "react-rails_api"

And your nginx conf:

    server {

      listen 80;
      server_name localhost;
      charset utf-8;

      location /dist {
        alias /usr/share/nginx/html/dist;
      }

      location /api {
        proxy_pass http://api:3000;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-NginX-Proxy true;
      }

      location / {
        proxy_pass http://app:3001;
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-NginX-Proxy true;
      }

    }

This is a good reference boilerplate for setting up react and webpack with pre-rendering on the server: https://github.com/colinmeinke/universal-js