A couple of months ago, when I learned Ruby-on-Rails for the first time, I had to work on a collaborative project with a coding partner. We kept running into issues, as he had a different version of Rails and Buby setup for the project. I couldn't wrap my head around how to install the versions the project needed.

Here's the guide I wish I had. It also shows you how to switch the version of Ruby or Rails you're using, depending on the projects you're working on.

First, let's get the latest version of Ruby installed. To do this, we need to install a package called RVM - Ruby version manager. This package lets us install ANY version of Ruby on our Ubuntu machine and allows us to switch between versions.

All the code here will be run using the Ubuntu CLI/terminal.

Installing RVM

1. First, we need to install a pre-requisite. Open up your Ubuntu terminal and type the command:

sudo apt-get install software-properties-common

Next, we need to add the PPA (Personal Package archive). A PPA is how we get files distributed by developers that are yet to make it to the official Ubuntu package/app store.

It's also a way for developers to distribute the latest versions of their software while waiting for Ubuntu to test and publish that software in the official store.

sudo apt-add-repository -y ppa:rael-gc/rvm

The command above adds the PPA to the list of locations we can download packages from on our Ubuntu machine.

Next, let's refresh our list of packages by running:

sudo apt-get update

Finally, let's install RVM itself.

sudo apt-get install rvm

Now restart your terminal for your changes to take effect. Then, type rvm version and hit enter to check that rvm is installed. You should get a response like this:

rvm 1.29.10 (manual) by Michal Papis, Piotr Kuczynski, Wayne E. Seguin [[https://rvm.io](https://rvm.io)]

Installing Ruby

Now we can install the latest Ruby version which is 2.7.1. Run the command rvm install 2.7.1. Alternatively, you can run rvm install ruby which will install the latest stable version (this will install v2.7.0).

To see what Ruby versions you have installed, run rvm ls. To switch between Ruby versions, run rvm use <version_number> (for example, rvm use 2.7.1).

Installing Ruby-on-Rails

The latest version of Rails is at 6.03. Rails is simply a Ruby gem, and with Ruby installed we can install Rails! Run gem install rails to install the latest version of Rails.

Finally, to check that all went well, run rails -v. You should get Rails 6.0.3.2 back, as this is the latest version at the time of publishing this article.

You can now start your first Rails project by typing rails new myapp.

Hey, you're now on Rails!

As a junior Full-Stack developer, my main focus was the backend. I wanted to learn how to program my backend server to serve my web application.

But after learning the basics of the the backend, I learned that the frontend was just as important as the backend. And one way to increase the liveliness of your web application is by adding JavaScript.

JavaScript is essential to add interactivity to your web application. Of course, it has become far more than that now. It is a programming language that web browsers run. Many websites you have visited use some JavaScript code in their frontend.

You may have started using Ruby on Rails to build your web application and wondered how to add JavaScript to your code. In this article, I'll show you how to add JavaScript code to your Rails app.

Why JavaScript?

You may wonder why you even need JavaScript in your web application in the first place. In short, if you don't include any JS, then your web application's user experience will not be good.

Let's say you have a form that a user fills out and you want to do form validation. If the user submits the form without filling in the proper values, the page for the form has to reload again, hitting the server and coming up again for the user. That takes a lot of time and will probably annoy the user.

Of course you can sometimes get away with HTML form validation, but that's not always possible. Adding a simple script that checks the user inputs and notifies them that they should input the correct information is much better.

Of course this doesn't mean you can ignore server side validation, but that's for another article.

Another use case is loading files asynchronously, which you can do in JavaScript without reloading the whole page. You may have used some web apps that load more pictures and articles as you scroll down without having to refresh or change the page over and over again.

These and other use cases are great reasons to use JavaScript in your application. In fact, the demand for JavaScript has been increasing. You can even use it to write your backend.

But we love Rails, so we are going to stick with it for a while.

What we'll cover here

At the time of writing, the latest version of the framework is Rails 6, and it has brought some changes to the way you interact with JavaScript.

Prior to Rails 6, we had the asset pipeline to manage CSS and JavaScript files. But starting from Rails 6, Webpacker is the default compiler for JavaScript. CSS is still managed by the asset pipeline, but you can also use Webpack to compile CSS.

You won't find your JavaScript folder in the same place as you did in Rails 5. The directory structure for JavaScript has changed to the app/javascript/packs/ folder.

In that folder you will find the application.js file, which is just like the application.css file. It will be imported by default in the application.html.erb file when you create your new Rails app.

The application.html.erb file will be used by all views.

Adding a script that will be used by all views

If you want your JavaScript to be available in all views or pages, you can just put it in the application.js file:

require("@rails/ujs").start()
require("turbolinks").start()
require("@rails/activestorage").start()
require("channels")

console.log('Hello from application.js')

The first four lines are there by default. I have added a console.log statement to show you that the JavaScript will be available everywhere.

You can test this by viewing any page in your application and opening the developer console.

But you may not always want your JavaScript code to be loaded on every page. Instead, you can make the script available only when visiting a specific page.

Adding a script that will be used by a specific file

If you want your JavaScript to be available for only a specific view, then you can use the javascript_pack_tag to import that specific file:

<h1 class='text-center'>I want my JS here only</h1>

<%= javascript_pack_tag 'my_js' %>

console.log('Hello from My JS')

Remember that you need to add the file in the packs directory. The javascript_pack_tag should also refer to the name of the JavaScript file you created.

Now the script will only run when the specific view that includes the javascript_pack_tag is loaded in the browser.

Wrapping up

I hope this article helps clear up any confusion you might have when updating your app to Rails 6, or if you just got started with Rails.

You can follow me on Github if you want to learn more.

A complete guide to setting up a single-page Javascript App with React and Redux inside a Rails project.

Update (Mar 17, 2019): Added Typescript to the last step of this project.

This tutorial will show you how to create a single-page app with React (and Redux and Semantic UI) inside a Rails project.

This tutorial will also include:

• Redux
• React Router
• Reselect
• Redux Think
• Semantic UI

Side note #1. I saw this wonderful guide recently and it inspired me to write one for Rails.

Side note #2. Here is the finished tutorial. The commit history corresponds (kind of) with the steps in this guide.

Overview

To give you a sense of what we’re going to build and how things will work, see the 2 diagrams below.

Diagram 1: Handling the first HTTP request (i.e. requests from the browser to our Rails App)

The diagram below illustrates your React App inside your Rails project, and the path (solid black line) that the first request takes to return the React App back to the client (browser).

Diagram 1: How our project handles the first request from the client (i.e. browser)

Diagram 2: Handling subsequent HTTP requests (i.e. requests from our React App to our Rails App)

After the React App is loaded in the user’s browser, the React App will be responsible for sending requests to your Rails App (solid black line). In other words, once React is loaded, requests to Rails will come from Javascript code, and not the browser.

Diagram 2: How React interacts with Rails (HTTP requests will come from in the React App and not the browser itself)

Other Important notes before we start coding

• Think of your React App as being separate from your Rails App. The React App is strictly for the front-end and runs in the user’s browser. The Rails part is strictly for the back-end and runs on the server. The Rails App does not know anything about the React App except for when to return its static assets (Webpack compiled HTML, JS, and CSS).
• Once your React App is loaded by your browser, all the logic to make HTTP requests (retrieve data, and turn that data into a view) is done in the front-end (i.e. browser).
• Your Rails App effectively does not serve any views except for the one that serves your React App. In this tutorial, the only Rails view is /app/views/static/index.html.erb
• All /api/* paths gets handled by the Rails App, while all other paths gets handled by React inside the browser (after your browser has loaded the first request). For example, [http://your-app.com/something](http://your-app.com/something) will be sent to the Rails App, and then returned back to your React App (the HTML/JS/CSS that has already loaded in the browser), which will decide what to show on the screen.
• Considerations for building a single-page app. Not necessary for this tutorial but useful.
• React Component design patterns. Again, not necessary but useful.

System Requirements

FYI here’s my system config. Not saying you need this, but something similar will make this tutorial experience smoother.

• macOS 10.13.6 (High Sierra)
• Ruby 2.5.1
• Rails 5.2.1 (and Bundler 1.16.6)
• • gem install bundler -v 1.16.6
• Node 9.8.0

Finally, on to the code!

Step 1: Create a new Rails project with Webpack and React

Create a new Rails app. I’ve named mine rails-react-tutorial.

rails new rails-react-tutorial --webpack=react

See here for more info on the --webpack=react flag introduced in Rails 5.1.

Step 2: Make sure the Webpacker and React-Rails gems are installed

Check if the Webpacker and React-Rails gems are in your Gemfile. If the gems are not there, then add it:

Sometimes only Webpacker is added, and not React-Rails; not sure why …

Now run these commands to install everything.

bundle install

# This command might not be necessary.# If already installed, then it will# ask you to override some files.rails webpacker:install

rails webpacker:install:react  rails generate react:installyarn install

Now run rails server -p 3000 and visit [http://localhost:3000](http://localhost:3000) to make sure our project is working.

Pro Tip #1: run ./bin/webpack-dev-server in a separate window while coding to have any changes automatically build and reload the browser.

Pro Tip #2: If you get this error can’t activate sqlite3 (~> 1.3.6), already activated sqlite3–1.4.0 then add gem ‘sqlite3’, ‘~> 1.3.6’ to Gemfile. See this link for more info.

Step 3: Add a Controller class, and Route, to our Rails app

Add a new route to our Rails app. For this example, we will add GET /v1/things endpoint to `config/routes.rb``.

Our config/routes.rb file

This new route will require a ThingsController. Create a new app/controllers/v1/things_controller.rb file. Remember, it should be in the v1 folder because it belongs to our Rails API.

_Our /app/controllers/v1/thingscontroller.rb file

Our Things controller will return a hard-coded response for GET /v1/things.

At this point, you should be able to re-run rails server -p 3000 and visit [http://localhost:3000/v1/things](http://localhost:3000/v1/things).

Success!

Next, we will create a new React component.

Step 4: Generate a new React component

Create a HelloWorld React component that accepts a String parameter named greeting by running the following command:

rails generate react:component HelloWorld greeting:string

A file should be created: app/javascript/components/HelloWorld.js.

Our app/javascript/components/HelloWorld.js file

Step 5: Use our HelloWorld component

To use and see our new HelloWorld component we need to 2 things: create a view embeds this component, and add a route to point to this view.

To create a view, create the file app/views/static/index.html.erb and add the following:

“Hello” is being passed in as the “greeting” param for HelloWorld

For our new route, add the following line to our routes.rb file, and an empty StaticController to support it.

Adding a route to serve our new view that contains the HelloWorld component

Add this to app/controllers/static_controller.rb:

An empty controller

You should now be able to re-run rails server -p 3000 and visit [http://localhost:3000/](http://localhost:3000/v1/things) to see your new React component (remember to run ./bin/webpack-dev-server in a separate window to have an Javascript changes automatically get packaged by webpack).

Success! Our first rendered component.

Now that we have a React component that renders in our view, let’s expand our app to support multiple views with react-router.

Step 6: Add React-Router

First, run this command to add react-router-dom, which includes and exports all of react-router and some additional helper components for web browsing. More info here.

npm install --save react-router-domyarn install

This command should add the following line to your package.json file. Note, 4.2.2 was used here, but your version could be different.

Now let’s use React Router to make some routes for our React Front-End.

Step 6: Using React-Router

[react-router](https://github.com/ReactTraining/react-router) allows us to manage all our UI routes strictly with Javascript. This means that we will need a single “App” component that encapsulates our entire application. “App” will also use React-Router to present the correct “Page” component for the URL being requested.

To start, run this command to add an App component that will represent our entire front-end application.

rails generate react:component App

Next, open the file for the newly created React component, app/javascript/components/App.js, and add the following …

Our React App with 2 routes

Now change index.html.erb to point to our new App component.

The App component will encapsulate our entire front-end.

Lastly, edit your routes.rb to have Rails send all requests that are not for the API to our App component (via StaticController#index).

Our routes.rb now forwards all non-API and non-Ajax requests to our React App

We can now run rails server -p 3000 and visit [http://localhost/](http://localhost/) and [http://localhost/](http://localhost/)hello to see React-Router working (remember ./bin/webpack-dev-server enables auto-webpacking).

Next, we’ll need to install some additional dependencies before we can connect our React front-end to our Rails API.

Step 7: Adding Redux, Sagas, Babel Polyfill, and Axios

Now let’s add the following Javascript libraries for our front-end.

• Redux to manage the global state of our application.
• Babel-Polyfill to enable fancy Javascript features that might not otherwise be available on older web browsers.
• Reselect and React-Redux to make working with Redux easier.

To install everything, run the following:

npm install --save redux babel-polyfill reselect react-reduxyarn install

Now we will use these tools to set up a Redux State Store, then add some Actions and Reducers to use it.

Step 8: Set up Redux State Store

In this step, we will set up the Redux State Store for our app with the following template (we will add and remove “things” in the next steps).

{  "things": [    {      "name": "...",      "guid": "..."    }  ]}

First, create a configureStore.js file. This will initialize our Redux Store.

Code to initialize our Redux State, and our first Reducer!

Now import and use configureStore() in the App Component to create a Redux State and hook it up to our App.

Initializing the Redux State for our App

Now you have Redux installed in your app! Next, we will create an Action and a Reducer, and begin to write and read from our Redux State.

Step 9: Add an Action and a Reducer

Now that the App has a Redux State, we will add a <button> to HelloWorld that dispatches an Action (that we will define here) that will be received by the rootReducer().

First, add getThings() Action definition and import createStructuredSelector() and connect() into theHelloWorld Component. This maps parts of the Redux State, and Actions (i.e. dispatching getThings()) , to HelloWorld’s prop.

Next, add a <button> to HelloWorld that dispatches a getThings() Action (from ./actions/index.js) on every click.

HelloWorld component with all some new Redux helper code

After everything is added to HelloWorld, go to [http://localhost:3000/hello](http://localhost:3000/hello), open the Console, and click the “getThings” button to see your Action and Reducer functions being called.

Look at the console.log() output to see our Action being dispatched

Now that you can send an Action that can be received by a Reducer, let’s have the Reducer alter the Redux State.

Step 10: Have HelloWorld read React State and display “things”

Insert a List <ul> in HelloWorld and fill it with “things” from your Redux State.

HelloWorld with <ul> that reads “things” from our Redux State

To test if this is actually working, we can initialize with some “things” data. Once this is done, we can refresh the page and see it in our list.

Initialize our Redux State with some “things” to see if the front-end <ul> is reading it properly

Now that we have a simple Action and Reducer working, we will extend this so that the Action queries our Rails API and the Reducer sets the content of “things” with the API response.

Step 11: Install Redux-Thunk

We will need Redux-Thunk to allow async workflows (like an HTTP request) to dispatch Actions.

Install redux-thunk by running this command:

npm install --save redux-thunkyarn install

Now, let’s use Thunk in our Action!

Step 12: Use redux-thunk and fetch() to query API and set React State with results

First, let’s import redux-thunk in configureStore.js and install it our Redux Store so our App can handle “Thunk” Actions.

Need to install Redux Thunk as a Redux middleware in our App.

Now test that everything is working by starting the App and loading a page.

Next, let’s change the getThings() Action to return a function that performs the following (instead of returning the Action object):

1. Dispatch the original Action object
2. Make a call to our Rails API.
3. Dispatch a new Action getThingsSuccess(json) when the call succeeds.

For this step, we will also need to add the getThingsSuccess(json) Action.

Our new getThings() Action function that does a lot more than returning a simple object — thanks to Redux Thunk!

Of course, this does nothing to the Redux State since our Reducer is not making any changes. To fix this, change the Reducer to handle the GET_THINGS_SUCCESS Action and return the new State (with the response from the Rails API).

_Have our Reducer change the Redux State when GET_THINGSSUCCESS is dispatched

Now if you start your App, navigate to localhost:3000/hello and click the button, your list should change!

There you have it. A Rails API hooked up to a React+Redux App.

(Bonus) Step 13: Installing Redux Dev Tools

Maybe I should’ve put this step earlier, but Redux Dev Tools is essential for debugging the Actions your App is sending, and how those Actions are changing your State.

This is how you install it. First, install the proper extension for your browser (Chrome, Firefox).

Next, run the following to install the library.

npm install --save-dev redux-devtools-extensionyarn install

Now, use it to initialize your Redux State Store.

Install Redux Dev Tools in your App. You will need to do some extra modifications to turn this off in production mode.

After all this is done, you should be able to see a new tab, Redux, in your Chrome (or Firefox) dev tools, that lets you see which Actions were dispatched, and how each one changed the App’s State. The React tab will also show you all your components and their props and states.

Debugging React Components and Redux State/Actions gets 100x easier with this

Happy debugging!

(Bonus) Step 14: Semantic UI

Semantic is a great library for UI components that makes it really easy to build nice looking websites quickly.

To install this library, run the following.

npm install --save semantic-ui-css semantic-ui-reactyarn install

Add this to app/javascript/packs/application.js:

import 'semantic-ui-css/semantic.min.css';

And add this to app/views/static/index.html.erb:

<%= stylesheet_pack_tag "application", :media => 'all' %

Nice UI made easy!

(Bonus) Step 15: Using a Reasonable Directory Structure

This step is totally optional, and it has nothing to do with the function of the App. Just my opinion on how you should organize your files.

So as you can probably guess, stuffing your Actions into the same file as your Components, and having a single reducer for your entire App, does not scale very nicely when your App grows. Here is my suggested file structure:

app|-- javascript   |-- actions      |-- index.js      |-- things.js   |-- components   |-- packs   |-- reducers      |-- index.js      |-- things.js

(Bonus — Mar 17 2019 Update) Step 16: Install Typescript!

Typescript is just like Javascript but with types! It is described as a “strict syntactical superset of Javascript”, meaning that Javascript is considered valid Typescript, and the “type features” are all optional.

IMO Typescript is fantastic for large Javscript projects, such as a big React front-end. Below are instructions on how to install it, and a small demo of it inside our project.

First, run the following commands (taken from the Webpacker Readme):

bundle exec rails webpacker:install:typescriptyarn add @types/react @types/react-dom

Now, to see it in action, let’s rename app/javascript/reducers/things.js to things.tsx and add the following lines to the top of the file:

Lets add an interface to tell Typescript what “Thing” should be

After you add interface Thing , let’s use it by having const initialState use that type (seen in the screenshot above), and specify that thingsReducer return an array of type Thing (also seen in the screenshot).

Everything should still work, but to see Typescript in action, lets add a default case to thingsReducer and add return 1 . Since 1 is not a Thing type we will see the output of ./bin/webpack-dev-server fail with the following:

Type Thing being enforced in our code

And that’s it! You can now add Typescript .tsx files to your project and start using Types with your project.

Here’s a great overview of Typescript and why you should use it.

The End

You made it! You’ve made a Rails App that uses React and Redux. That’s pretty much it for the tutorial. I hope you had fun and learned something along the way.

If you build something with React and Rails, please do share it in the comments below — along with any questions or comments you may have for me.

Thanks for reading!

This post is co-authored by Hricha Kabir, my colleague at Altizon Systems. She was working on this task primarily. I had the chance to learn along the way.

_Photo by [Unsplash](https://unsplash.com/@rvruggiero?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Robert V. Ruggiero on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

We work on an IoT product focusing on manufacturing industries and build analytics reports. Most of the time, report design and information vary based on the user’s role who is going to consume it.

Example: A Director level person is interested in a consolidated report of a week, whereas a Department Head is interested in the statistics of a single day and Quality Manager is keen about shift data. If we further drill down the hierarchy, then the Production Manager will be the one who wants to look into live production data.

For live data, Production manager can open the Live Dashboard and monitor it, but the user who wants to see a consolidated report won’t prefer to login into Product and check out a report. Instead, they prefer scheduled email communication which will send a report based on scheduled time and repeat it forever until unless a user stopped this scheduled job.

So our task was to write a utility which periodically sends a particular report to a user via email on a daily basis or at a defined scheduled time. For scheduling, we use Sidekiq, but our main challenge was: how to execute/calculate the report on the server side (without opening a browser) and send it over email.

In all of our products, we use React for the front-end and it does the heavy lifting of rendering the report on the browser. To achieve attaching the same report in the email, we would have to design an HTML template for every report. That means we would have had 2 views of each report, one written in HTML and another in ReactJS.

This has following drawbacks:

1. The product code base will have duplicate code which violates the DRY principle for software development.

2. Increases the time for designing a report which impacts product delivery.

We decided to look at other possible solutions instead of writing the same code twice. And we came across following options and explored them one by one until we succeeded in achieving our goal.

1. Print Screen: Print the report using print screen and send it as an attachment.

2. FrontEnd Print Button: In report’s UI, add a Print Button which will convert react component into HTML/PDF page.

3. Ruby Gem: There is a ruby gem which can render a report component on the server side within Rails, generate its HTML and send it as an email body.

4. Server-Side Rendering with Node server: Use serverside rendering using ReactDOMServer and headless browser protocol to render HTML and JS and generate a pdf.

Now we will go through the details of each solution.

Print Screen:

It was the simplest solution we had and it requires user input. A user needs to be present with a system who will do a screen capture as an image and attach it over the mail. But this doesn’t scale. Also what if a user wants a report at a scheduled time or sent periodically?

Example: Every week at 8 pm. It’s not possible for a person to do this. This also suffers from the inability to fully capture a scrollable page, so we had to drop this idea.

FrontEnd Print Button:

After doing some search, we found out there are some browser extensions available which produce a full image of an opened page. Example: Full Page Screen Capture in Chrome. After adding this extension to the browser, we would be able to capture any screen in image(png/jpg) format.

Again this solution requires no development but suffers from some of the previous scaling and scheduling issues. At the same time, we would still need a user logged in to the browser to perform this action, which defeats the purpose of email delivery.

RubyGem:

Soon we realized that our solution cannot require browser interaction. We would need to use server-side rendering. So we started exploring Ruby Gems which support server-side rendering with React. We explored the following Gems

3.1 rails_react_stdio:

It is based on react-stdio which supports server-side rendering irrespective of server-side technology. It acts as a binary which will do the work of rendering react components. For rendering React Component on the server side we need to pass the file path of the react component and props if required. It will return a JSON response which will have the HTML code of the report. Further we can send HTML content over email.

Internally this gem uses popen3 for executing render command. But this means that react-stdio binary needs to be present in the docker container where our rails app is running.

This is not great from a point of view of maintainability and reproducibility. Additionally having large HTML content with charts can be slow to load so we preferred pdf attachment. Yet we gave it a try.

Example: For rendering a report which has the component TestComponent and the file path app/assets/javascripts/components/TestComponent.jsx

First, include the gem in Gemfile:

gem ‘rails_react_stdio’, ‘~> 0.1.0’

Now from the email scheduler call the gem method to render the report and get the HTML from the response. Then send this response to email.

email_body = RailsReactStdio::React.render(‘app/assets/javascripts/components/TestComponent.jsx’, {city: “Pune”})

We tried using the above method but had no success. Also the GitHub repo was not actively maintained, and all of its test cases were failing. So we decided to move forward without this.

3.2 react-rails:

The ReactJS community built this gem. It uses ExecJS for executing render-action of a react component on the server side. We just need to pass one flag ‘prerender’: true.

<%= react_component(‘Dashboard’, {name: ‘Example’}, {prerender: true}) %>

This prerendering process does not have access to the window or document so it does not load runtime JavaScript or CSS. We also use JQuery for a few things so it wouldn’t work as well.

There is an alternative: this gem has another class for server-side rendering, ExecJSRenderer, which helps in availing JavaScript to a component on the server side.

ExecJSRenderer Class has 2 methods: _beforerender and _afterrender, which gives access to the JavaScript required before and after component rendering. But it’d require a lot of changes in the existing code base for supporting server-rendering, in every controller. Apart from this, ExecJS doesn’t provide sandboxing as well as runtime error information. We were still looking for something better.

Server-Side Rendering with Node server:

Most of the ruby gems we explored internally created the node server and rendered react on the server side. So instead of using Ruby, we decided to directly use the node server and achieve this task ourselves.

4.1 ReactDOMServer based solution:

Here we use ReactDOMServer. It is the preferred solution for server-side rendering from the React team. We created a node server which calls the renderToString() method with a react component. It returns the rendered content which we combine with HTML and send over email.

Example:

server.get(‘/’, (req, res, next) => {
  /**
  * renderToString() will take our React app and turn it into a      string
  * to be inserted into our Html template function.
  */
  console.log(‘started’)
  const body = renderToString(<App />);
  const title = ‘Server side Rendering React Components’;
  var result = Html({ body, title })
}

The renderToString() method returns a string response. We pass this response to an HTML template and send the template over mail.

When we tested this out, an email was received as expected except all the images used in the report were broken. The email was not able to resolve the image source relative path.

To get the correct images in the email, we would either need to

• Store images in S3 and use the source URL in the report: So now we would be adding S3 image URLs in the email, and the email server would directly load images from the S3 server. It would require extra cloud space for storing images, and downloading from destination requires another network call from the email inbox.

Or

• Send base64 code of image in the mail: Instead of image URL, we can send the base64 code of an image. Although It increases network payload, many mail servers such as Outlook and Gmail block base64 images.

So we would still need to do something about this.

4.2 Puppeteer:

After exploring the above methods, we discovered Puppeteer Headless Chrome service. Puppeteer is a NodeJS library from the Google Chrome team, used in end to end testing. By default, it uses the Chrome/Chromium browser for the same. Essentially it simulates all the actions a user can perform in the browser. Example: Keyboard Input, Mouse events, Form submission etc.

The result of a puppeteer request can be an HTML page, Screenshot, or PDF. In case of HTML, it renders the full page on the server side along with all images, CSS, and JavaScript. Or a user can render a page on the server side and if required they can generate a screenshot or a pdf.

If we use this library with a Node server, we can schedule a task within Sidekiq which would make a request to this server, render a report, and send it over email. Puppeteer also has a rich set of APIs which support in sending customizing headers in the request which help us in authenticating a background request.

This is exactly what we needed!

So the overall request lifecycle inside puppeteer should look like this:

1. It launches the browser

2. Creates a page on the browser

3. Authenticate with the Report Application server

4. Opens the report URL that the user wants and returns the rendered page content

5. Based on the user’s requirement, stores HTML of the rendered page or takes a Screenshot or generates a PDF.

We can use either the default browser (gets downloaded when we install puppeteer) or we can give a specific browser version. If we give a specific browser version, then we will have to make sure that puppeteer APIs are compatible with the given browser.

All of the above can be achieved using the following steps.

1. Install puppeteer:

It downloads the default Chrome/Chromium browser. So If we want to launch the default browser and install puppeteer:

npm install puppeteer

2. Serve a Request:

Build a server which will receive a request and implement a request lifecycle and return the desired result.

The following is the code snippet we use for generating a pdf of a given page URL.

const puppeteer = require(“puppeteer”);
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.emulateMedia(“screen”);
await page.goto(‘https://www.google.com', {
      timeout: 30 * 1000, 
      waitUntil: “networkidle0”
});
await page.pdf(pdfOptions);
return page;

As we already mentioned in the lifecycle steps above, it first launches the browser. Then it creates and opens a page in the launched browser. Here along with the URL, we have passed timeout and waitUntil params which are given for the following reasons:

• timeout: If we want to restrict a request time then we can pass it to timeout variable
• waitUntil: if networkidle0 is given, then the next request will not be served until or unless the current one is completed.

In the end, rendered content will be passed to the pdf method and it will generate a pdf. We can also provide PDF formatting options like page height, page width, headers, footers, and margins.

Additionally, we have called page.emulateMedia(“screen”); which applies CSS to the page. If we don’t add emaulateMedia, our PDF doesn’t load the CSS.

Apart from what we have used, there are many different configuration options with Puppeteer APIs. Visit the API docs for more information.

If you found this helpful or if you have any suggestions, please feel free to write them it in comments.

That’s all folks.

It’s official, using Heroku for all my Rails projects so far has spoiled me rotten. After receiving some AWS credits thanks to a pitch competition, I decided to deploy my latest project on Elastic Beanstalk (AWS’ Heroku competitor). All I have to say is that I miss Heroku.

Alas, if you are in a similar situation, here are step-by-step instructions to deploying your Rails 5.2 / PostgreSQL app on Elastic Beanstalk.

Installing the Elastic Beanstalk CLI

We will use the terminal in this tutorial. Let’s begin with installing the “Elastic Beanstalk Command Line Interface.” Here is how to do it on macOS using Homebrew:

brew install awsebcli

If you are using another platform, googling “how to install awsebcli on [your platform]” should lead you in the right direction.

Initializing Elastic Beanstalk

I will assume that you already have an Amazon Web Services account, if not go ahead and create one. Now, go into the directory of your project, and initialize Elastic Beanstalk:

cd my_projecteb init

Then the EB CLI will ask you a few questions to initialize the Elastic Beanstalk application. The initialization part is straightforward. If you get stuck anywhere you can check out the “Configure the EB CLI” page from the documentation.

Creating a new environment

As you already know, your application can have many environments (think of them as different configurations). For example, you might have a “production” environment. This is the environment that you use for the user-facing version of your app. But you might want to have another environment named “staging.” This is where you try new versions of your app, before pushing it to the production environment.

We can create an environment using the command below:

eb create production

Deploying to Elastic Beanstalk

Assuming you are using Git, commit your changes before deploying your application. The EB CLI deploys your last commit. If you deploy before committing, you will deploy an earlier version of your app.

After committing your changes, deploy using the following:

eb deploy

So far so good, now we need to set a few things before our app actually starts working.

Setting up the master key

You can use the CLI for this purpose as well, but I prefer using the web panel for this. Here is how:

1. Go to AWS, choose “Services -> Elastic Beanstalk,” then click on your environment.
2. Open the “Configuration” tab, and click “Modify” under the box titled “Software.”
3. Under “Environment properties,” add a new key named RAILS_MASTER_KEY. Set its value to the content of your “master.key” file. You can find this file in the “config” directory of your Rails app.
4. Click on the “Apply” button at the bottom of the page.

Setting up a PostgreSQL database

Elastic Beanstalk provides an easy way to set up a database, which you can reach through “Configuration -> Database.” I prefer not to use that because if you need to rebuild your Elastic Beanstalk environment, your database will be deleted. So, we will set up the database separate from our Elastic Beanstalk environment.

Creating a PostgreSQL database on RDS

1. Go to AWS, choose “Services -> RDS.”
2. Choose “Create database.”
3. Choose “PostgreSQL,” and click “Next.”
4. Select your use case, “Production” or “Dev/Test,” and click “Next.”
5. Here, you can try different options, and see what the estimated monthly costs are. Settle with something that is within your budget. You can start with a db.t2.micro instance, no multi-AZ deployment and a general purpose SSD.
6. Choose an instance identifier, this is sort of a “namespace.”
7. Choose a username and password, keep these handy for now, click “Next.”
8. On the “Configure advanced settings” section, the important thing is the security groups. Select “Choose existing VPC security groups,” and select the security group that looks like “…-AWSEBSecurityGroup-…”
9. Pick a database name, such as my_app_production.
10. Click on “Create database,” this will take a while.

Allowing access to the database

In the meantime, let’s add Postgres access to your security group:

1. Go to AWS, choose “Services -> EC2.”
2. Click on “Security Groups” on the left panel.
3. Choose the security group from the previous section.
4. Go to the “Inbound” tab, and click on “Edit.”
5. Click on “Add Rule.” For “Type,” choose “PostgreSQL,” and for “Source” type in the ID of the security group that you are adding this rule to. It should be right above the “Inbound” tab and should look like sg-*.
6. Click “Save.”

Setting up the production database configuration

Now, in your Rails directory, open config/database.yml. Change it as such:

# ...

production:  <<: *default  database: <%= ENV['RDS_DB_NAME'] %>  username: <%= ENV['RDS_USERNAME'] %>  password: <%= ENV['RDS_PASSWORD'] %>  host: <%= ENV['RDS_HOSTNAME'] %>  port: <%= ENV['RDS_PORT'] %>

Adding relevant environment variables to Elastic Beanstalk

We told Rails to get the information for the production database using the above environment variables. Now we need to make sure that our Elastic Beanstalk environment includes these variables:

1. Go to AWS, choose “Services -> Elastic Beanstalk,” then click on your environment.
2. Open the “Configuration” tab, and click “Modify” under the box titled “Software.”
3. Under “Environment properties,” add the following key-value pairs:
4. RDS_DB_NAME: Database name you picked when setting up your database.
5. RDS_USERNAME: Username you picked when setting up your database.
6. RDS_PASSWORD: Password you picked when setting up your database.
7. RDS_HOSTNAME: Go to “Services -> RDS,” and you can find this information under the “Connect” section of your database instance information page. It is called “Endpoint.”
8. RDS_PORT: Set this to 5432.
9. Click on the “Apply” button at the bottom of the page.

After this, commit your Rails app directory again, and run eb deploy. You might want to wait a few minutes before doing this because Elastic Beanstalk does some stuff in the background after updating environment variables.

After these steps, your Rails app “should” be running.

Still not working?

If there are any issues, you can go to your EB environment on the AWS web panel, click on “Logs,” and choose “Request Logs -> Last 100 Lines” to see the logs. But before doing that, I’d recommend trying to run your Rails app using the production environment on your local machine by using the command rails s RAILS_ENV=production.

I’ll be the first to admit that I’m not the most experienced person when it comes to deployment. As I said, I always used Heroku in the past, and I probably will use it for my future projects as well. These steps worked for me after a few days of scratching my head trying to set up my Rails app on Elastic Beanstalk, so I wanted to share these in hopes of saving time for people who are in the same situation I was. So, take this all with a grain of salt, and good luck!

If you like this article, follow me on Twitter or sign up to my newsletter to get notified when I write new articles. I write about software and startups.

If you are looking for a Rails developer, I’m currently available for remote work. Feel free to get in touch with me at hi{at}evrim.io.

Originally published at evrim.io on November 28, 2018.

In one of my previous articles, I talked about the process of internationalizing Rails applications. That article explained all I18n basics, but it was revolving around placing all translations inside YAML files. There is nothing wrong with this approach, but unfortunately it does not always work.

Suppose your website has lots of user-generated content which should be adapted for different languages. I propose that you store your translations inside the database. Why will YAML files not work in this case?

• The content itself may be quite large and it would be inconvenient to store it inside a file
• The content is dynamic and users should be able to create translated versions themselves, without the help of the site’s developer

It appears that the I18n module allows you to define a custom backend that, for instance, may be powered by ActiveRecord. Luckily, there is no need to craft your own solution as there is already an existing one: Globalize. Globalize is a battle-tested library characterized as “Rails I18n de-facto standard library for ActiveRecord model/data translation.” With its help you can easily translate model attributes, scope them, introduce fallbacks, and so on.

So, in this article we are going to talk about Globalize and see it in action by creating a sample Rails application. Shall we start?

Preparing the Application

Let’s get started by generating a new Rails app:

rails new GlobalizeSample

I’ll assume you are using Rails 5.2.1 for this demo but still the described concepts apply to earlier versions as well.

Let’s suppose we are building an international online shop showcasing various products. These products will be added by the administrator, and so we can’t know what the content will be ahead of the game. This means that the traditional method of using YAML files to store translations won’t work. Our content manager will have access to the CMS only, and we would rather not give them access to the source code of the app (I shudder to think about it!).

But, fear not, in the next section we will overcome this problem easily. For now, however, let’s take care of the basics.

Administering Products

Utilize code generator and create a new scaffold for the Product:

rails g scaffold Product title:string description:text

This should create a model, controller, routes, and views for the products. Don’t forget to run the migration:

rails db:migrate

Now start the server:

rails s

Visit the http://localhost:3000/products path and make sure that you are able to add, modify, and delete the products.

Switching the Language

In order to see the Globalize library in action, we will need a way to switch the app’s locale. I won’t cover this process in detail (as we have a separate article on the topic) so let’s do it quickly.

First, add the list of supported locales to the config/application.rb:

# ... config.i18n.available_locales = [:en, :ru]

I will be supporting English and Russian, but you may choose any other languages.

Next, tweak the config/routes.rb and wrap the product resource with a scope. Also, while we are here, add a root route:

scope "(:locale)", locale: /#{I18n.available_locales.join("|")}/ do # <== add this resources :products root 'products#index' # <== add this end # <== add this

After that, modify the application_controller.rb file:

# ... before_action :set_locale private def set_locale I18n.locale = extract_locale || I18n.default_locale end def extract_locale parsed_locale = params[:locale] I18n.available_locales.map(&:to_s).include?(parsed_locale) ? parsed_locale : nil end def default_url_options { locale: I18n.locale } end

This code will set the locale on every request while making sure the chosen language is actually supported. Also, it will add a locale GET param to each link generated with the link_to helper.

Lastly, add two links to the application layout:

<!-- views/layouts/application.html.erb --> <ul> <li><%= link_to 'English', root_path(locale: :en) %></li> <li><%= link_to 'Русский', root_path(locale: :ru) %></li> </ul>

To ensure that this new feature works, add translation for the Products page title:

# config/locales/en.yml en: products: index: title: Our Products

# config/locales/ru.yml ru: products: index: title: Наши продукты

Now simply utilize these translations inside the views/products/index.html.erb:

<!-- ... --> <h1><%= t '.title' %></h1> <!-- ... -->

Note that we can take advantage of the “lazy lookup” because the translation keys were named in the proper way.

Translate other static content as necessary, then reload the server, and make sure that the locale can be properly switched. Great!

Globalize, Globalize it Hard!

Defining Attributes For Translation

Okay, the ground work is done and we may proceed to the next part. Before Globalize can get into the game, it should be added to the Gemfile:

# ... gem 'globalize', git: 'https://github.com/globalize/globalize'

At the time of writing this article, the stable version was not yet compatible with Rails 5.2, so we have to install directly from the master branch. Also note that the latest stable does not support ActiveRecord 4.1 and below, therefore refer to the documentation to learn which Globalize version to use for older AR.

Next, you have to decide which model attributes will be translated with Globalize. We are going to translate both :title and :description so list them in the model in the following way:

# models/products.rb # ... translates :title, :description

This will allow you to store store translations inside the database per locale. To make it work, however, you also need to create a special translation table.

Translation Table

So, if you are creating a new model and a migration, things are as simple as using a create_translation_table! method as explained here. Our case is a bit more complex, because we already have a products table with some data. Therefore it is required to move these data to the translation table. Start by generating a new migration:

rails g migration translate_products

Now flesh it out with the following code:

# db/migrate/xyz_translate_products.rb class TranslateProducts < ActiveRecord::Migration[5.2] def change reversible do |dir| # <=== 1 dir.up do Product.create_translation_table!({ # <=== 2 title: :string, # <=== 3 description: :text }, { migrate_data: true, # <=== 4 remove_source_columns: true # <=== 5 }) end dir.down do Product.drop_translation_table! migrate_data: true # <=== 6 end end end end

I’ve pinpointed the main things to note about this code:

1. This is going to be a reversible migration.
2. We are creating a translation table for the Product.
3. Carefully list all the fields that should be translated as well as their types. As you recall, these fields were passed to the translates method inside the model.
4. Don’t forget to provide the migrate_data option that should preserve your original database records.
5. remove_source_columns will ensure that the original columns (:title and :description) will be removed from the products table. You may also perform this step later in a separate migration.
6. That’s the action to perform when the migration is rolled back. Data should be preserved as well.

Run the migration:

rails db:migrate

After this command finishes its job, you will see a new product_translations table:

As you see, there is a product_id column that establishes relation to the product, and also a locale field to denote which language this translation is for. When you migrate your original data, it will be associated with the app’s default locale (which is English in our case). Override this behavior by using a with_locale method, for example:

I18n.with_locale(:ru) do Post.create_translation_table!(...) end

If you need to add more translated fields to the table later, utilize an add_translation_fields! method as shown in this example. Also, don’t forget to define these new fields in the model.

Try It!

At this point Globalize is integrated into our application and ready to get rolling! Perform the following steps to see it in action:

• Reload your server and try to create a new product: its title and description will be provided for the currently set locale only (English in my case).
• Switch to Russian locale and make sure that both title and description are missing for the new product.
• Edit this product and enter values for the Russian version of the product.

As a result you should see two translations being stored inside the product_translations table:

Great job!

Some More Globalize Features

Fallbacks

What happens if Globalize cannot find translated attributes for the given locale? As we’ve seen in the previous section, by default it will return blank values (which are actually nils). However, it is possible to enable I18n fallbacks and display attribute values from another locale. To achieve that, just turn fallbacks on inside the config/application.rb file:

# ... config.i18n.fallbacks = true

Now when the translated attribute is nil, Globalize will try to load values from another locale. To make sure this feature is working, reload the server, create a new product, and then switch to another language. The title and description should fallback to another locale.

If you would like to employ fallbacks when the translation values are also blank (not nil), set the fallbacks_for_empty_translations option to true:

# models/product.rb # ... translates :title, :description, fallbacks_for_empty_translations: true

Also note that it is possible to define a custom fallback chain globally in the following way:

# somewhere in an initializer Globalize.fallbacks = {:en => [:de, :ru]}

Scope and Context

Globalize provides a special model scope called with_translations that can be used to load translation for a given language. In this example we are loading all translations for the English locale only:

Product.with_translations('en')

On top of that, it is possible to display translation for a desired locale in your views. To achieve that, use a with_locale method:

<% Globalize.with_locale(:en) do %> <!-- render your stuff here... --> <% end %>

Interpolation

What’s interesting is that Globalize even supports interpolation in the translated attributes. It works in the same way as interpolation in YAML translation files:

product.title = "Product for %{someone}" product.title someone: "John" # => "Product for John"

So, the placeholder here is %{someone}. To provide its value, simply pass a hash to the proper model attribute. Really convenient!

Conclusion

In this section we have seen how to store translations inside database with the help of Globalize solution. We have discussed its basics, seen how to install and configure it, how to migrate data properly, how to define translations, provide fallbacks and utilize scopes. All in all, we have covered nearly everything Globalize has to offer, and so you may now apply these concepts into practice! Also don’t forget that Globalize can safely play with YAML files, so you can mix and match these approaches as you see fit.

Which solution do you utilize to internationalize user-generated content? Would you give Globalize a go? Share your thoughts in the comments section!

Make Your Life Easier With Lokalise

Supporting multiple languages on a big website may become a serious pain. You must make sure that all the keys are translated for each and every locale. Luckily, there is a solution to this problem: the Lokalise platform that makes working with the localization files much simpler. Let me guide you through the initial setup which is nothing complex really.

• To get started, grab your free trial
• Create a new project, give it some name, and set English as a base language
• Click “Upload Language Files”
• Upload translation files for all your languages
• Proceed to the project, and edit your translations as needed
• You may also contact professional translator to do the job for you
• Next simply download your files back
• Profit!

Lokalise has many more features including support for dozens of platforms and formats, and even the possibility to upload screenshots in order to read texts from them. So, stick with Lokalise and make your life easier!

Originally published at blog.lokalise.co on November 16, 2018.

The popularity of using Webpack to deal with your assets in Rails is steadily increasing. Getting started is really straightforward. If you are starting a new app, you simply run rails new my_app --webpack and Rails takes care of the rest.

Thanks to the webpacker gem, adding Webpack to your existing application is also pretty uncomplicated. You add the gem to your Gemfile, bundle, and finally install webpacker:

gem 'webpacker', '~> 3.5'bundlebundle exec rails webpacker:install

This is pretty sweet. Now all you need to do is link your JavaScript pack and the CSS imported in it into the head of your application.html.haml:

<%= javascript_pack_tag 'application' %> <!-- js from app/javascript/packs/application.js -->

<%= stylesheet_pack_tag 'application' %> <!-- CSS imported via Wbpack -->

Once this is done, you are ready to write your modern JavaScript code and make use of all the great libraries out there.

What is tinyMCE?

TinyMCE is a rich text editor in the cloud. To put it simply, it’s like Word that can be implemented into your app.

The project I am working on uses it to let admins edit the content of the front page. Thanks to TinyMCE, it isn’t necessary to build a separate admin interface for that purpose. But the editor’s usage can be much more versatile. Think, for example, of what Wordpress or Evernote allows you to do thanks to their build in tools.

Example use of TinyMCE. The power is in the user’s hands now.

Usage via CDN

We originally implemented the editor via CDN (e.g. linking the script in the head of our application.html.haml) like this:

!!!%html  %head    %meta ... <!-- some meta content -->    %title ... <!-- MyApp -->    = csrf_meta_tags

    %script{src: 'https://cloud.tinymce.com/stable/tinymce.min.js?apiKey=gexncjni90zx3qf0m5rr7kl8l40wd5yuly2xjza0g3kwrljt'}    = stylesheet_link_tag 'application', media: 'all'    = javascript_include_tag 'application'  %body    <!-- the usual body stuff -->

This required adding a file with our customized function in app/assets/javascript/tinyMce.js. Note that we are also using jQuery.

$( document ).on('turbolinks:load', function() {

    tinyMCE.init({         selector: 'textarea.tinymce',             // some other settings, like height, language,         // order of buttons on your toolbar etc.             plugins: [            'table', 'lists' // whatever plugins you want to add        ]    });});

In addition to that, we had to include a translation file (which is not necessary if you’re using English in your app). For everything to display correctly in production, you’ll also need to get a free Tiny Cloud API key .

Webpack and tinyMCE

Everything was working great for a couple of months, but we decided that it was time for the transition towards Webpack.

Webpack is supposed to make your life easier and, coupled with yarn, lets you focus on the important stuff. Say you want to use package A. It so happens, that package A relies on packages B and C. And package B depends on D, E and F. Rather than spending hours figuring out what the dependencies are and installing them all individually, what you want is to say yarn add package-A, and have it figured out for you. And this is almost the case.

This transition when it came to tinyMCE was way more painful than it should have been. And that’s why I decided to write this post. I hope it saves someone some time and frustration.

If you previously had tinyMCE implemented via CDN, you’d like to get rid of some stuff, to start clean. Remove the script link from application.html.haml. Then comment out the content of the tinyMce.js file (and the language file if you’re using one). I also decided to get rid of the jQuery dependency (in our case it meant removing gem 'jquery-rails' from the Gemfile, and in the app/assets/javascripts/application.js removing //= require jquery and replacing //= require jquery_ujs with //= require rails-ujs).

Note: Proceed with caution if you have more external libraries in your project that rely on jQuery (e.g. Bootstrap or Select2). Ultimately your goal would probably be to move all of them to Webpack, but the bigger the project, the more complex that task could be, so just bear it in mind. Nothing stops you from keeping your traditional implementation parallel with the Webpack one. In that case I would still recommend commenting it out for the time of tinyMCE implementation.

All these steps will ensure that things we’ll be implementing from now on work, and the old implementation doesn’t function as a fallback.

Step 1. If you want to use jQuery via webpack

Adding jQuery through Webpack is as simple as running yarn add jquery and adding the following code to the config/webpack/environment.js:

const { environment } = require('@rails/webpacker')const webpack = require('webpack')environment.plugins.prepend('Provide',  new webpack.ProvidePlugin({    $: 'jquery',    jQuery: 'jquery'  }))module.exports = environment

Step 2. Get the tinyMCE package

That is also pretty straightforward: run yarn add tinymce.

Then create a new file where we’ll place our function. I ended up with app/javascript/vendor/tinyMce.js with the following content:

import tinymce from 'tinymce/tinymce';import 'tinymce/themes/modern/theme';import 'tinymce/plugins/table';import 'tinymce/plugins/lists';

function tinyMce() {    tinymce.init({        selector: 'textarea.tinymce',

        // some other settings, like height, language,         // order of buttons on your toolbar etc.

        plugins: [            'table', 'lists'        ]    });}

// if you're using a language file, you can place its content here

export { tinyMce };

Step 3. Import everything to the application.js

We can import our function like so:

import { tinyMce } from "../vendor/tinyMce";

and then call it:

document.addEventListener(“turbolinks:load”, function () {    tinyMce(); });

As you can see, we also replaced the jQuery code with ES6.

Step 4. Get the tinyMCE skin to work

If you run your webpack-dev-server and rails s you might be surprised to see that your text editor is not there. One look in the console and you’ll see the following error:

This is because tinyMCE will not work without a skin, and pulling it in through Webpack requires its explicit import. We can do this by including this line in our tinyMce.js file, right after the other import statements. The path is relative to the node_modules folder:

import ‘tinymce/skins/lightgray/skin.min.css’;

At this point you should have your editor working.

But… if you look into the console, you might be disappointed to see that you are still getting 2 errors:

Don’t despair! There is an easy fix. Just add skin: false to your function tinyMce() config and it should do the trick. This will prevent the default files from loading.

Congrats! You just got your tinyMCE up and running!

I’m currently working with a legacy Rails application. We are slowly transitioning the front-end from Rails views to a Vue application.

As part of this transition, we have some elements that we want to turn into global Vue components. We want to be able to use these components within our existing Rails views and within a Vue application without having to customize each component to handle both situations.

Before I share my solution to this problem, here is an example single file Vue component that we want to be able to use in both scenarios (Rails view and Vue Application):

// Payments.vue

<template lang="html">  <div id="payments>    <div class="payment" v-for="payment in payments>      {{ payment.amount }}    </div>  </div></template>

<script>export default {  name: 'payments'

  props: {    payments: { type: Array }  }}</script>

<style lang="scss" scoped></style>

From within a Vue app, this is a straightforward component to use, right? For example:

// app/javascript/App.vue

<template lang="html">  <div id="app>    <payments :payments="payments" />  </div></template>

<script>import Payments from './Payments.vue'

export default {  name: 'app',

  components: { Payments },

  data () {    return {      payments: [        { amount: 123.00 },        { amount: 124.00 }      ]    }  }</script>

<style lang="scss" scoped></style>

But what about using it in a Rails view?

Solution

So a solution for using the Payments.vue component in Rails looks like this:

// app/views/payments/index.haml

.global-comp  = content_tag 'comp-wrapper', nil, data: { component: 'payments', props: { payments: @payments } }.to_json

Let’s break this element down.

.global-comp is a div (with class “global-comp”) for mounting a super simple Vue instance. This Vue instance gives us a wrapper component to use called CompWrapper.vue (we’ll get to what CompWrapper is for in a minute).

Here is the Vue instance mounted to .global-comp:

// app/javascript/packs/global_comp.js

import Vue from 'vue/dist/vue.esm'import CompWrapper from './CompWrapper'

document.addEventListener('DOMContentLoaded', () => {  const app = new Vue({    components: { CompWrapper }  }).$mount('.global-comp')})

All this does is make the component (CompWrapper.vue) available to us within a div with the class global-comp.

If you are using Webpacker with Rails, you will need to include this pack within your layout somewhere before the closing body tag. For example:

// app/views/layouts/application.haml

...

= javascript_pack_tag "global_comp"

CompWrapper.vue

This is the fun part. CompWrapper.vue allows us to pass:

1. The name of the component we want to use, for example, “payments”
2. The props we want to pass to it

The whole purpose of this wrapper component is to allow us to pass Rails instance variables like @payments into our components as props without having to handle this from within each component like Payments.vue.

So here is CompWrapper.vue:

// app/javascript/CompWrapper.vue

<template lang="html">  <component :is="data.component" v-bind="data.props"></component></template>

<script>import * as components from './components'

export default {  name: 'comp-wrapper',

  components,

  data () {    return {      data: {}    }  },

  created() {    this.data = JSON.parse(this.$attrs.data)  }}</script>

<style lang="scss" scoped></style>

The first thing the CompWrapper component is doing is taking the data attributes you set on the element in the Rails view, parsing the JSON, and setting an internal Vue data attribute with the parsed data:

created() {  this.data = JSON.parse(this.$attrs.data)}

with this.data set we can then use it to select the component we want to use and pass it the props we provided in our Rails view using a Vue dynamic component:

<component :is="data.component" v-bind="data.props"></component>

And that’s it!

We can now use Vue components as they’re meant to be used, but from within our rails views. ?

The (perfect) solution for the N+1 problem

The n+1 query problem is one of the most common scalability bottlenecks. It involves fetching a list of resources from a database that includes other associated resources within them. This means that we might have to query for the associated resources separately. So if you have a list of n parent objects, another n queries will have to be executed for fetching the associated resources. Let’s try to get rid of this O(n) conundrum.

If you’re comfortable with Rails, Active Model Serializers, and already have a good idea about what our problem is going to be, then maybe you can jump straight into the code here.

A Concrete Example

Say you’re fetching an array of Post objects at a GET endpoint. You also want to load the respective authors of the posts, embedding an author object within each of the post objects. Here’s a naive way of doing it:

class PostsController < ApplicationController    def index        posts = Post.all              render json: posts    endend

class Post  belongs_to :author, class_name: 'User'end

class PostSerializer < ActiveModel::Serializer    attributes :id, :title, :details

  belongs_to :author end

For each of the n Post objects being rendered, a query will run to fetch the corresponding User object. Hence we’ll run a total of n+1 queries. This is disastrous. And here’s how you fix it by eager loading the User object:

class PostsController < ApplicationController    def index        # Runs a SQL join with the users table.    posts = Post.includes(:author).all              render json: posts    endend

When A Simple Join Is Not Possible

Until now there’s been absolutely nothing new for veterans.

But let’s complicate this. Let’s assume that the site’s users are not being stored in the same RDMS as the posts are. Rather, the users are documents stored in MongoDB (for whatever reason). How do we modify our Post serializer to fetch the user now, optimally? This would be going back to square one:

class PostSerializer < ActiveModel::Serializer    attributes :id, :title, :details, :author

  # Will run n Mongo queries for n posts being rendered.  def author    User.find(object.author_id)  endend

# This is now a Mongoid document, not an ActiveRecord model.class User    include Mongoid::Document    include Mongoid::Timestamps    # ...end

The predicament that our users now reside in a Mongo database can be substituted with, say, calling a 3rd party HTTP service for fetching the users or storing them in a completely different RDMS. Our essential problem remains that there’s no way to ‘join’ the users datastore with the posts table and get the response we want in a single query.

Of course, we can do better. We can fetch the entire response in two queries:

• Fetch all the posts without the author attribute (1 SQL query).
• Fetch all the corresponding authors by running a where-in query with the user IDs plucked from the array of posts (1 Mongo query with an IN clause).

posts      = Post.allauthor_ids = posts.pluck(:author_id)authors    = User.where(:_id.in => author_ids)

# Somehow pass the author objects to the post serializer and# map them to the correct post objects. Can't imagine what # exactly that would look like, but probably not pretty.render json: posts, pass_some_parameter_maybe: authors

Enter Batch Loader

So our original optimization problem has been reduced to “how do we make this code readable and maintainable”. The folks at Universe have come up with an absolute gem (too obvious?). Batch Loader has been incredibly helpful to me recently.

gem 'batch-loader'

bundle install

class PostSerializer < ActiveModel::Serializer    attributes :id, :title, :details, :author

  def author    object.get_author_lazily  endend

class Post  def get_author_lazily    # The current post object is added to the batch here,    # which is eventually processed when the block executes.       BatchLoader.for(self).batch do |posts, batch_loader|

      author_ids = posts.pluck(:author_id)        User.where(:_id.in => author_ids).each do |user|        post = posts.detect { |p| p.author_id == user._id.to_s }        #'Assign' the user object to the right post.        batch_loader.call(post, user)            end        end    endend

If you’re familiar with JavaScript Promises, think of the get_author_lazily method as returning a Promise which is evaluated later. That’s a decent analogy, I think since BatchLoader uses lazy Ruby objects. By default, BatchLoader caches the loaded values, and so to keep the responses up-to-date you should add this to your config/application.rb:

config.middleware.use BatchLoader::Middleware

That’s it! We’ve solved an advanced version of the n+1 queries problem while keeping our code clean and using Active Model Serializers the right way.

Using AMS for Nested Resources

One problem though. If you have a User serializer (Active Model Serializers work with Mongoid as well), that won’t be called for the lazily loaded author objects, unlike before. To fix this, we can use a Ruby block and serialize the author objects before they’re ‘assigned’ to the posts.

class PostSerializer < ActiveModel::Serializer    attributes :id, :title, :details, :author

  def author    object.get_author_lazily do |author|      # Serialize the author after it has been loaded.           ActiveModelSerializers::SerializableResource                             .new(author)                             .as_json[:user]    end  endend

class Post  def get_author_lazily    # The current post object is added to the batch here,    # which is eventually processed when the block executes.       BatchLoader.for(self).batch do |posts, batch_loader|

      author_ids = posts.pluck(:author_id)      User.where(:_id.in => author_ids).each do |user|        modified_user = block_given? ? yield(user) : user        post = posts.detect { |p| p.author_id == user._id.to_s }          # 'Assign' the user object to the right post.        batch_loader.call(post, modified_user)            end        end    endend

Here’s the entire code. Enjoy!

Pundit is a Ruby gem that handles authorization via a very simple API.

Remember that authorization is different from authentication — authentication is verifying that you are who you say you are, and authorization is verifying that you have permission to perform an action.

Pundit is squarely within the authorization camp — use another authentication system like Devise to handle authentication.

How you work with Pundit

Step 1: You create a Policy class that deals with authorizing access to a specific type of record — whether it be a Blog or Potato or User.

Step 2: You call the built-in authorize function, passing in what you’re trying to authorize access to.

Step 3: Pundit will find the appropriate Policy class and call the Policy method that matches the name of the method you are authorizing. If it returns true, you have permission to perform the action. If not, it’ll throw an exception.

It’s pretty straightforward. Logic for specific models is encapsulated into its own policy class, which is great for keeping things tidy. Competing authorization library cancancan had issues with complicated permissions getting out of hand.

Minor tweaks required

Pundit’s simple conventions sometimes need to be tweaked to support more complex authorization use cases.

Access more information from within a Policy

By default, Pundit provides two objects to your authorization context: the User and the Record being authorized. This is sufficient if you have system-wide roles in your system like Admin or Moderator, but isn’t enough when you need authorize to a more specific context.

Let’s say you had a system that supported the concept of an Organization, and you had to support different roles within those organizations. System-wide authorization won’t cut it — you don’t want an admin of Organization Potato to be able to do things to Organization Orange unless they are an admin of both organizations. When authorizing this case, you would need access to 3 items: the User, the Record, and the user’s role information in the Organization. The ideal case would be to have access to the organization the record belongs to, but let’s make it harder and say we don’t have access to that via the record or the user.

Pundit provides an opportunity to provide additional context. By defining a function called pundit_user, this allows you to change what is considered a user. If you return a object with the authorization context from that function, that context will be available to your policies.

application_controller.rb

class ApplicationController < ActionController::Base  include Pundit

  def pundit_user    AuthorizationContext.new(current_user, current_organization)  endend

authorization_context.rb

class AuthorizationContext  attr_reader :user, :organization

  def initialize(user, organization)    @user = user    @organization = organization  endend

application_policy.rb

class ApplicationPolicy  attr_reader :request_organization, :user, :record

  def initialize(authorization_context, record)    @user = authorization_context.user    @organization = authorization_context.organization    @record = record  end

  def index?    # Your policy has access to @user, @organization, and @record.    endend

Your policies would now have access to all three kinds of information — you should be able to see how you would access more information if you needed it.

Override convention and specify which Policy to use

Pundit uses naming conventions to match up what you’re trying to authorize with the right policy. Most of the time this works well, but in certain cases you may need to override this convention, such as when you want to authorize a general dashboard action that doesn’t have an associated model. You can pass in symbols to specify which action or policy to use for authorization:

#Below will call DashboardPolicy#bake_potato?authorize(:dashboard, :bake_potato?)

If you have a model that is named differently, you can also override the policy_class function within the model itself:

class DashboardForAdmins  def self.policy_class   DashboardPolicy     # This forces Pundit to use Dashboard Policy instead of looking    # for DashboardForAdminsPolicy  endend

Testing

Authorization is one of those things I strong recommend having an automated test suite around. Setting them up incorrectly can be catastrophic, and it’s in my opinion one of the most tedious things to test manually. Being able to run a single command and knowing that you haven’t inadvertently changed any authorization business rules is a great feeling.

Pundit makes testing authorization very simple.

def test_user_cant_destroy?  assert_raises Pundit::NotAuthorizedError do    authorize @record, :destroy?  endend

def test_user_can_show?  authorize @record, :show?end

Overall I like Pundit. I’ve only been using it for a short while, but I already prefer it over cancancan — it just feels more maintainable and testable.

Did you find this story helpful? Please Clap to show your support!
If you didn’t find it helpful, please let me know why with a Comment!

Ruby is a general purpose programming language created in the 1990s by Yukihiro “Matz” Matsumoto. It’s also considered one of the best languages to start with when you’re first learning to code. We have lots of channels dedicated to Ruby-related projects on Gitter, both for advanced developers and beginners. Check them out!

• rails/rails — General chat around Ruby on Rails. http://rubyonrails.org
• voltrb/volt — Volt is a reactive web framework where your Ruby runs on both server and client.
• opal/opal — Opal is a Ruby to Javascript compiler. It is source-to-source, making it fast as a runtime. Opal includes a compiler (which can be run in any browser), a corelib and runtime implementation.
• hanami/chat — Hanami is a modern web framework for Ruby.
• jekyll/jekyll — Jekyll is a blog-aware, static site generator in Ruby.
• aws/aws-sdk-ruby — The official AWS SDK for Ruby.
• refinery/refinerycms — Refinery CMS is an extendable Ruby on Rails CMS that supports Rails 4.2.
• rubinius/rubinius — Rubinius is a modern language platform that supports a number of programming languages. Rubinius includes a bytecode virtual machine, generational garbage collector, and just-in-time (JIT) native machine code compiler. Rubinius provides concurrency support via native OS threads with no global interpreter lock.
• dev-ua/ruby-ua — Ukrainian developers chat dedicated to Ruby.
• bbatsov/rubocop — Rubocop is a robust static Ruby code analyzer, based on the community Ruby style guide.
• puma/puma — Puma is a ruby web server built for concurrency.
• cucumber/cucumber-ruby — Cucumber is a tool for running automated tests written in plain language.
• mruby/mruby — mruby is the lightweight implementation of the Ruby language complying to (part of) the ISO standard. Its syntax is Ruby 1.9 compatible.
• mperham/sidekiq — Sidekiq is simple, efficient background processing for Ruby.
• rebelidealist/stripe-ruby-mock — A mocking library for testing stripe ruby.
• trailblazer/chat — Trailblazer gives you a high-level architecture for web applications.
• dry-rb/chat — dry-rb is a collection of next-generation Ruby libraries, each intended to encapsulate a common task.

Looking for something else? Check out our Explore section or easily start your own channel here.

Did we miss an channel that you think should be featured? Drop us a line in the Gitter HQ and we will add it to the list.