[Whitecollar]

Beginner question, having heard rails is not a hot thing anymore and SPAs being the new hot stuff, where do you guys draw the line between a SPA and a server rendered web app? I can see the extreme side cases, the highly interactive web app vs content-heavy-but-not-that interactive web app.

But for example, github doesn't have complex interactions and is not content heavy (in the walls of text sense) but its doing just fine as a non-SPA and users seem to like it the way it is.

Would a site like github benefit much from being a SPA instead of being server side rendered with some JS on the top?

[bdcravens]

> Would a site like github benefit much from being a SPA instead of being server side rendered with some JS on the top?

I don't think so. Perhaps there could be some areas they could make the UI richer (say a dynamic code viewer that doesn't require page refreshes, etc)

However, bring it back to the beginning of your comment:

> having heard rails is not a hot thing anymore and SPAs being the new hot stuff

Github doesn't need to be a SPA, nor do most apps. I think many decisions are being made because it's "hot", but generally that's a very poor reason to choose something. (Though to be fair, there's probably many Rails apps that were built in Rails for that very reason)

SPAs carry an entirely new set of concerns. For months, I couldn't order a very important medication online from CVS because their specialty pharmacy site, written in Angular, was busted. I eventually figured out how to make it work by executing Javascript directly in the inspector.

[gglitch]

I don't have any feelings myself at all about whether everyone should learn to code, but I'm pretty sure I'm going to remember this anecdote next time someone brings it up.

[sotojuan]

You can have an SPA and still use Rails. Rails would just serve JSON instead of the HTML. Your JavaScript frontend would use that JSON to display stuff and handle actions. Plenty of companies do this.

Cannot speak about amount of junior/entry level jobs out there but in NYC Rails jobs are plentiful.

[enraged_camel]

Are there any recent, up-to-date and comprehensive tutorials that show how to use React with Rails while following the conventions of both frameworks? Every tutorial I've seen focuses on either one, but I haven't found one that focuses on both.

[JohnBooty]

There's a reason why you don't see specific Rails+React tutorials - since they're just communicating with each other other JSON, Rails doesn't need to know or care that it's React, Angular, or whatever on the other end.

The reverse is true for React, it doesn't care where the data's coming from.

You'd simply want to look for a Rails tutorial that focuses on building an API using Rails.

It's probably slightly easier to learn React first IMHO.

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

[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

[rhizome]

My sense is that SPAs are for unidirectional information architectures: click on something, then click on something in that something, and so on, ever forward.

They almost always fail in some way upon use of the back-button (e.g. both Twitter and FB, among many others). The endless page pattern always either doesn't back-button to the right place or uses a smelly hack to re-paginate the endless page.

[20years]

This is only my opinion so I would love to hear others input too. I think SPA apps are really good for mobile heavy services. Heavy web services such as github or most CRUD SaaS services are fine as a web app. You can still use front-end frameworks such as React or Angular with a Ruby on Rails back-end. Oftentimes that is overkill though for a basic CRUD SaaS app.