Forem: Paweł Dąbrowski

Security Best Practices for Your Rails Application

Paweł Dąbrowski — Wed, 12 Oct 2022 11:36:28 +0000

Alongside performance and usability, you should always focus on security when creating any web application. Keep in mind that hacking techniques are constantly evolving, just as fast as technology is. So you must know how to secure your users and their data.

This article will show you how to create a secure Rails application. The framework is known to be secure by default, but the default configuration is not enough to let you sleep well at night.

We will share some best coding practices and a few habits in the development process that can help you create secure code.

Let's dive in!

Security in Your App: Best Coding Practices

Modern web applications are often complex. They utilize multiple data sources and handle custom authorization rules as well as different methods of authentication. Knowing how to avoid SQL injections or ensuring that users can only read their data is not enough.

When you build a Rails application, you have to configure it properly, design the application securely, and write code that makes it bulletproof.

We'll look at:

Application configuration - The default configuration is exemplary, but we can make things even better with a few extra steps.
Business logic - Applications should be secure by design, not only by code. This principle is essential but is often ignored when an MVP has to be delivered quickly.
Code in controllers - These classes are the entry point to our application, so an extra dose of attention is always needed to design a reliable application.
Code in models - Many issues are related to a database, so it is essential to design and perform secure communication with the primary source of the data.
Code in views - The point where we expose data to the browser is also a popular target for hackers, so we have to ensure that we don't render anything that risks our users' data or privacy.

Application Configuration

It all starts here, in the configuration files. In most cases, unless you restart the application, the rules will remain the same. Rails' creators made an effort to create secure defaults, but we can still improve them with some extra steps.

Force SSL

You can force your Rails application to always use a secure connection with the HTTPS protocol. To do this, open the config/environments/production.rb file and set the following line:

config.force_ssl = true

This setting does a few things to the application:

Every time there is a request to the HTTP version of the application, Rails will redirect the request to the HTTPS protocol.
It sets a secure flag on cookies. Thanks to this, browsers won't send cookies with HTTP requests.
It tells the browser to remember your application as TLS-only (TLS is Transport Layer Security, an extension of the HTTPS protocol).

CORS

Cross-Origin Resource Sharing (CORS) is a security mechanism that defines which website can interact with your application's API. Of course, if you build a monolith app, you don't need to care about this protection.

If you build an API application, you can configure CORS by installing an additional gem called rack-cors.

Once you have done that, create a file called cors.rb in the initializers directory config/initializers. Define what endpoints a website can access (including request methods):

Rails.application.config.middleware.insert_before 0, Rack::Cors do
 allow do
   origins 'https://your-frontend.com'
   resource '/users',
     :headers => :any,
     :methods => [:post]
   resource '/articles',
     headers: :any,
     methods: [:get]
 end
end

In the above example, we allow the your-frontend.com website to call the /users endpoint (using only the POST method) and the /articles endpoint (using only the GET method).

Secure Environment Variables

You should never hardcode your API keys, passwords, or other sensitive credentials in the source code. You might accidentally make them public or give someone who's not authorized access to some sensitive application resources.

The Rails framework itself provides a way to store credentials securely. However, the implementation varies depending on the framework version:

Rails 4 - The feature is called 'secrets'. You store your sensitive information in a config/secrets.yml file that is not tracked in the git repository.
Rails 5 - The feature is called 'credentials'. Your sensitive information is stored encrypted in config/credentials.yml.enc — you can edit it with the config/master.key file. So while the YAML configuration file can be stored in the repository because it’s encrypted, you don’t track the master.key file.
Rails 6 - Also called 'credentials', you can store credentials per environment. Because of that, for every environment, you have the encrypted YAML file and key to decrypt it.

Alternatively, you can always set the values on the server level, so that they only load in the server environment. Locally, each developer sets them individually.

Business Logic

You should think about security not only when you write code, but also when you design the processes in your application.

Business logic is a set of rules that apply in the real world, and your goal is to map them in your code. Unfortunately, mapping them can cause weak points in your application and lead to security issues.

Strong Authentication and Authorization Rules

Let's first explain the difference between authentication and authorization, as these terms are sometimes misinterpreted:

Authentication - You validate a user's login and password against an application's database.
Authorization - You validate the role of a signed-in user and, based on that, render different information for different users. For example, a user with an admin role can access a list of users in an application, while in most cases, the typical user can't.

To improve the security level of your authentication, you can set high standards for your end-users:

Strong passwords - Set a strict password policy that doesn't allow for passwords that are too simple or weak. Of course, you can't control if your users share their passwords, but you can make their passwords hard to guess.
Two-factor authentication - Another layer of protection that will secure an account even if someone else knows the password.
Encrypted passwords - Never store passwords in your database as plain text. Then, even if your database is exposed, a hacker won't be able to get your users' passwords.

Authorization Best Practices

If your application is complex, you probably need different roles for users to manage their data. As business logic grows, it may be hard to control everything without making a mistake that leads to an information leak.

You can avoid issues by following some well-known good practices:

Keep authorization logic in one place - It's hard to modify business logic correctly if you have to change multiple areas in the code. Storing the rules in one file makes it easy.
Set clear rules - You won't be able to tell whether your application is secure if you can't validate the business logic against well-defined rules.
Set roles based on the group, not a single user - It is easier to control the authorization process if you have groups of permissions instead of defining rules per user.

Of course, good code reviews and well-written tests are also a must here to avoid introducing bugs to existing business logic.

Code in Controllers

Controllers are the first layer of MVC architecture and handle requests coming from users. Therefore, it is essential to filter incoming information correctly as it will be propagated on other application layers.

Filter Incoming Parameters

You should never pass a raw params value to your application. Thanks to the strong parameters feature, it is easy to control the data that we'd like to pass along.

Imagine that we have a User model we want to update:

class UsersController < ApplicationController
  def update
    current_user.update(params[:user])
  end
end

Someone can manipulate the params, and it would be possible to update other User model attributes (for example, the admin flag if you have one). To avoid such a situation, filter params that you pass to your model:

class UsersController < ApplicationController
  def update
    current_user.update(user_params)
  end

  private

  def user_params
    params.require(:user).permit(:first_name, :last_name)
  end
end

Use Scopes to Avoid Data Leaking

Usually, we don't want to show the user data that does not belong to them. We may inadvertently expose some records for URL address manipulation due to the wrong code design. Let's consider the following case:

class MessagesController
  before_action :authenticate_user!

  def show
    @message = Message.find(params[:id])
  end
end

Everything seems fine; the controller is protected from guests, and we assign the message object. However, a user just needs to change the id in the URL address to get a message that does not belong to them. This is a very dangerous situation.

We can avoid it by using scopes within the given context. In the mentioned example, the current user is the scope:

class MessagesController
  before_action :authenticate_user!

  def show
    @message = current_user.messages.find(params[:id])
  end
end

Avoid Insecure URL Redirects

Let's consider a straightforward example of a redirect based on the user input:

redirect_to params[:url]

We should never do that, as we expose our user to a redirect that can take them everywhere. The simplest solution to prevent this security issue is to avoid using redirects with user input. If you can't, you can always redirect to a path without the host:

path = URI.parse(params[:url]).path.presence || "/"
redirect_to path

Code in Models

Once Rails parses code in a controller, you will probably call models to receive the information from the database. Since models are responsible for communicating with your database as well as performing important computations, they are also often targeted by hackers.

Avoid SQL Injection

SQL injection is one of the most popular techniques used to access database information from the outside. The Rails framework tries to protect us from that threat, but we also need to write code that won't let this happen.

In general, we should avoid passing user input directly as a part of a query:

User.joins(params[:table]).order('id DESC')

If you need to, always validate the user input and assign a default value when the input is invalid:

valid_tables = %w[articles posts messages]
table = valid_tables.include?(params[:table]) ? params[:table] : "articles"
User.joins(table).order('id DESC')

Check out this extensive set of examples of what not to do when it comes to SQL injection.

Prevent Command Injection

Avoid using methods that allow a program to execute any code. Such methods include exec, system, `, and eval. You should never pass user input to those functions.

If your application allows users to execute code, you should run their code in separate Docker containers. In addition, you can remove dangerous methods before executing user input:

module Kernel
 remove_method :exec
 remove_method :system
 remove_method :`
 remove_method :eval
 remove_method :open
end

Binding.send :remove_method, :eval
RubyVM::InstructionSequence.send :remove_method, :eval

Avoid Unsafe Data Serialization

Insecure deserialization can lead to the execution of arbitrary code in your application. If you plan to serialize JSON:

data = { "key" => "value" }.to_json
# => "{\"key\":\"value\"}"

Instead of using load or restore methods, use parse:

# bad
JSON.load(data)
JSON.restore(data)

# good
JSON.parse(data)

If you plan to serialize YAML:

data = { "key" => "value" }.to_yaml
# => "---\nkey: value\n"

Instead of using load or restore methods from the Marshal module, use the safe_load method from Psych:

# bad
Marshal.load(data)
Marshal.restore(data)

# good
Psych.safe_load(data)

Code in Views

Whatever you render in views is visible to the end-user. When malicious code is rendered, it will affect your users directly by exposing them to untrusted websites and data sources.

Avoid CSS Injection

It would appear that CSS code is always secure; it only modifies the styles of a website. However, if you allow for user-defined styles in your application, there is always a risk of CSS code injection.

One of the most popular cases of user-defined CSS is a custom page background:

<body style="background: <%= profile.background_color %>;"></body>

A user with bad intentions can input a URL that an application will automatically load, and do damage to the current user viewing the content. To prevent such situations, provide a predefined set of values instead of allowing users to type any value.

Sanitize Rendered Output

In the modern versions of Rails, output is sanitized by default. Even if a user inputs HTML or JS code and the application renders it, the HTML or JS code will escape.

If you want to render HTML defined by users, always predefine which tags should render and which should escape:

<%= sanitize @comment.body, tags: %w(strong em a), attributes: %w(href) %>

In the above code, we allow users to render strong, em, and a HTML elements in their comments.

Don't Include Sensitive Data in Comments

This is primarily a reminder for junior developers unfamiliar with how web applications work on the front end. Don't ever put sensitive information in comments (especially in views, as it will be exposed to end-users):

<!--- password for the service is 1234 –>
<%= @some_service.result_of_search %>

Habits to Keep Your Rails Application Secure

To make your Rails app secure and reduce technical debt, establish some valuable development habits. Taking small preventative actions frequently is much less painful than refactoring more significant portions of your codebase.

Upgrade Rails and Other Libraries Often

An upgrade is often painful and time-consuming, unless you upgrade to minor versions of a library. Develop a habit of upgrading a library each time a new, stable version is published. Your application will then be in good shape (not only regarding security, but also performance).

If you use GitHub for day-to-day development, an extension like Depfu is useful as it performs frequent updates for you.

Perform Security Audits

I don't mean expensive audits by external companies. Often, it is enough to install a tool like Brakeman and scan code with every commit or pull request.

Also, it is a good idea to scan your Gemfile and find gems that need updating due to security issues discovered by the community. You can use bundler-audit to automate this process.

Have A Proper Logging Strategy

Logs, in many cases, are usually just thousands of lines of information you will never view. However, there might be a case where one of your users is attacked or experiences a suspicious action.

In such a situation, if you have detailed and easily searchable logs, you can collect information that will help you prevent similar problems in the future.

Wrapping Up: Keep Your Rails App Secure

In this post, we ran through some security best practices for your Rails app that reduce the risk of a data breach.

Making sure that your Rails application is secure might be challenging. Sticking to the framework's defaults is not enough; you have to know how to avoid creating security issues. For example, various injections and remote code executions have been well-known issues for the past few years, but still, you can't be 100% sure that your application won't be affected.

Don't forget the importance of frequent upgrades, security audits, and a culture of good logging. When combined, all of these things will help to make your Rails application more secure.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Connect a Ruby on Rails App with React in a Monolith

Paweł Dąbrowski — Wed, 10 Aug 2022 13:06:49 +0000

More and more people are using Ruby on Rails to create a back-end API application for a front-end app.

But what if you want to create a rich and functional interface with JavaScript and use Rails for the back-end, without having them in separate repositories? You can create a monolithic Rails application.

This article will show you how to connect a Rails application with a front-end developed in React (without splitting the code into two separate applications). We'll also give some alternatives if React is not your framework of choice, but you like the idea of a monolithic app with a rich front-end.

But first, let’s start with an architecture overview to see why linking Rails and React is an option worth considering.

App Architecture: An Overview

A while back, when a developer started to build a web application, they didn’t have a list of possible architectures they could use. For the most part, web apps were monoliths without a very interactive user interface.

In modern software development, we have much more to choose from. We can:

Use the old monolith architecture
Go for a separated back-end and front-end
Use service-oriented architecture

Let’s take a closer look at the most common types of architecture.

Headless Architecture

In headless architecture, the head of an application is detached from its body. In other words, you create a back-end application using Ruby, Python, Node.js, or another programming language. This application manages a connection with a database and provides computing power.

The body is a front-end application created with a framework like React, Vue, or Angular.

CDN stands for content delivery network, a service designed to deliver assets faster for visitors worldwide. We can build the architecture in the cloud environment, or each setup piece can be a separate server.

Choose headless architecture when:

You aim for a large codebase. If your application is going to be very large, the separate back-end and front-end layers will make it more maintainable.
You expect different workloads for different system elements. With a more modular approach, you can scale modules separately.
You foresee that you'll change the technology in the future. It is easier to adopt new technology with a headless architecture, as the communication, in most cases, will be the same between the back-end and front-end, regardless of the stack.

Avoid a headless approach when:

You want to develop an MVP version of an app very quickly. You will likely start over again in the future and consider a different angle.
You have a very small team. Finding the right person to do the back-end, front-end, and DevOps stuff simultaneously might be hard.
You want to build a straightforward application. Unfortunately, the headless approach increases your app's complexity.

Monolith Architecture

One application handles the presentation layer (front) and computation layer (back) in a monolith architecture. Such an approach speeds up the application creation process and simplifies the server setup.

As you'll notice, in a monolith, we eliminate a part of the communication that's in the headless approach. Such architecture improves the performance and security of an application.

Choose this architecture when:

You develop an MVP version of your app. Frameworks like Ruby on Rails or Django make it easy and fast to build robust monolith applications.
You start with a small team. Back-end developers can easily handle the front-end in such an architecture, and the deployment process is straightforward.
Your application doesn’t have to depend on a very interactive front-end, and you don’t want to build a single-page application.

Avoid the monolith approach if:

You know that the front-end of the application will be huge. It is harder to maintain this part as it's connected directly with the back-end codebase.
You know the front-end will have a completely different workload than the back-end. As a result, you won’t scale certain elements of the monolith easily.
You may change the front-end or back-end tech stack in the future. Such a transition would be pretty complicated with this architecture.

Hybrid Architecture

An alternative approach to the monolith and headless architectures is a hybrid. You create a monolith application, but instead of using the front-end produced by the back-end framework, use the technology of headless applications.

Yet this comes with a few disadvantages which you should consider:

The codebase is shared. So as the application grows, it is harder to navigate through all the files and build a structure that is easy to understand.
Scaling only the back-end or front-end is very difficult as both parts connect in one application.
Being agile is not easy. With every change, you deploy the whole application, even if it’s just a change in the front-end style.

However, you also get some benefits that you wouldn’t get with a standard monolith architecture:

You can work separately on the back-end and front-end and update libraries independently. Changing the stack of the front-end is easier.
You can build a very interactive, single-page application based on the monolith with a reasonably simple deployment process.
You can be flexible. It's possible to use the front-end served by the JavaScript framework for some parts of your application.

With these pros and cons of hybrid architecture in mind, we will now go through the design process of a monolith application (created with Rails and a front-end React framework).

Designing a Monolith with React

There are three main things to keep in mind before you build a monolith application with a React front-end:

Front-end framework installation process - there are a few ways of adding React to a Rails application. However, each has some limitations, so choosing the right one for your project is essential.
Communication inside the application - The back-end needs to expose data to the front-end, and the front needs to present this data. This element of the system needs to be designed carefully to make information exchange as smooth and fast as possible. As always, your choice should depend on the type of application you would like to build.
Alternatives - You can still go for the hybrid approach but not use React. We will show you other solutions that you can quickly adapt to build a more interactive monolith.

Install React in Your Ruby on Rails App

There are three main ways to install React in your Rails application.

Install React Using Ruby Gems

We can extend the functionality of our app by installing external libraries called Ruby gems. If you are unfamiliar with JavaScript, this is the fastest way to add React to Rails.

The react-rails library is one of the most popular Ruby gems to integrate React with Rails. It provides generators for components, testing helpers, and view helpers to render JavaScript code inside the views.

If you accept another layer of logic for your front-end, using this Ruby gem is the best way to get started with React quickly. However, remember that besides the JS framework updates, you also have to depend on the gem updates. The more gems you use, the more problematic the Rails upgrade process can become.

Install React Using Import Maps

Import maps were first presented in Rails 7. The lib lets you build modern JS applications using libraries made for ES modules without transpiling or bundling.

Installing React with import maps is as easy as calling this command from the terminal:

$ ./bin/importmap pin react react-dom

You don’t even need to host source files on your server, as they are served from JavaScript’s CDN by default. By applying the --download flag, you can download the files to the vendor directory inside your application.

However, you cannot use JSX (the most popular rendering extension in the React community) with import maps. HTM library is an alternative solution.

Install React Using Package Manager

This option seems to be the most flexible and optimal way to add React to a Rails project. You don’t create another level of abstraction for the front-end as you fetch the library directly. Updating React is also simpler.

The most popular package managers in the Rails community are NPM and Yarn. You can add React libraries by invoking this command in the terminal:

yarn add react react-dom # or npm install react react-dom

With this installation method, you won’t get any Rails helpers to render JavaScript code. However, we'll show you how to install and run React components using this approach shortly.

Communication Between Your Ruby on Rails App and React

Choosing the right way to exchange information between your Rails application and React components is essential. Selecting the wrong method can harm your application's performance and make your code less maintainable.

There are two common, standardized ways of exposing information from the back-end — REST and GraphQL. Let's take a look at both options.

REST Communication

The REST API is a pretty simple way of exchanging information. We have different request types at our disposal to perform CRUD (create, retrieve, update, delete) operations. If you are familiar with the concept of resources in Rails, the REST API works the same way.

You call the /authors endpoint if you want to pull information about authors or a single author. You call the /posts endpoint to do the same, but for posts. If a single page in your application requires a lot of different data, you will perform multiple HTTP requests.

You should consider using REST in your application if:

Your front-end application doesn’t need to render data from different sources on a single page. On the other hand, this doesn’t have to mean that the application is very simple.
You don’t want to implement the cache mechanism on the application level. Using REST API, you can benefit from the HTTP cache provided by browsers.
You care about error reporting. Implementing an error report with REST is easy as you work on different HTTP responses. With GraphQL, it’s not, as your application always returns a 200 response status.

GraphQL Communication

GraphQL represents an entirely different approach to data fetching. Using this technology, you perform one request and get only the data you need. You can hit multiple endpoints at once and pull only one attribute per endpoint.

With GraphQL implemented on the back-end, you always call the same endpoint and modify the query parameter.

You should consider using GraphQL in your application if:

You are building a very interactive application requiring the front-end to pull a lot of different data at once.
You want to build your application very quickly. Building an API with REST is slower. With GraphQL, you get maximum flexibility, and all you need to care about in every step is the content of the query.
You are building an application where the API is used by multiple different applications like mobile, front-end, or services.

Front-end Alternatives to React for Your Ruby on Rails App

If you don’t want to use React but like the idea of having a front-end application inside the Rails monolith, there are some alternative solutions available.

Rails Turbo

Turbo allows you to write single-page applications without the need for any JavaScript code. You design the page from independent frames. They behave like components and can also be lazy-loaded if needed.

With Rails Turbo, you don’t spend time building the JSON responses from an API. You can simply reuse Rails views and render HTML — it’s automatically transferred and rendered in your components. This reduces the amount of code in your application.

You should consider using Rails Turbo if:

You don’t like writing JavaScript. It is possible to design rich and interactive web applications without the need for a single line of JavaScript.
You like the Rails framework. The Turbo library provides helper methods to quickly build interactive pages or transform existing ones into more dynamic forms.
You want to move fast. As mentioned before, you don’t have to care about the JSON responses from an API. You can simply serve HTML views and the Turbo library will automatically pull them.

Stimulus JS

Stimulus is a JavaScript framework created by the Rails team. It was designed to extend the HTML that you already have. The main concept of this framework is the controller — one controller per view.

Your Rails application will automatically load the JavaScript controller for the given view and map the HTML elements. You can respond to events or modify the view when you need to.

You should consider using Stimulus if:

You are already using Rails Turbo, but want more control over a page's granular elements.
You don’t want to build a single-page application but still want to make some page elements interactive or dynamic.

Other JavaScript Frameworks

Besides React, other interesting JavaScript frameworks on the market right now include Vue, Svelte, and Ember.js. So if you like writing JavaScript components, you can choose one of these.

Rails Turbo and/or Stimulus JS are the perfect choice if you're a Rails developer who's familiar with JavaScript but doesn’t want to write much of it. Both libraries heavily follow the principles of the Rails framework, so if you already work in this ecosystem, it will be easier for you to use these extensions.

Build a Monolith with React

It’s time to build a simple Rails application to manage a list of books we want to read. Let's start with generating the Rails skeleton.

Ruby on Rails Project Bootstrap

Ensure you have the latest version of Ruby on Rails installed locally on your operating system. Then generate the skeleton using the rails new command:

rails new booklist -d postgresql -j esbuild

The above command will generate a new Rails project in the booklist directory, with support for a PostgreSQL database. We can now enter the project’s directory, create the database, and run the server:

cd booklist/
./bin/rails db:create
rails s

Visit the localhost:3000 address in your browser to see the default Rails welcome screen.

Now generate a home controller for a single endpoint in the application so we can attach the React application to the layout. Run this command in the terminal:

./bin/rails g controller Home index

The last step is to update config/routes.rb file to set the root path:

Rails.application.routes.draw do
  root "home#index"
end

We can now focus on the front-end part with React.

React Installation

We will install the react, react-dom, and node-uuid libraries using yarn in our terminal:

yarn add react react-dom node-uuid

To properly handle JSX, we also have to update our build script. First, open the package.json file, and in the scripts section, ensure that the build command is the following:

esbuild app/javascript/*.* --bundle --sourcemap --outdir=app/assets/builds --public-path=assets --loader:.js=jsx

You can now run ./bin/dev to kickstart both yarn build and the rails server or run them separately. For example, if you want processes in separate terminal tabs, run rails s in one and yarn build –watch in the second.

Render a React Application in a Rails Layout

We want to run the React application when a user enters the main root in our Rails application. To do this, update the app/views/layout.html.erb file, so that the body section looks like this:

<body>
  <div id="app"></div>
</body>

The React application will render the component with JavaScript logic inside the app div.

Let’s now create the entry point for the React application. Open the app/javascript/application.js file and write the following code:

import React from "react";
import { createRoot } from "react-dom/client";
import App from "./App";

const container = document.getElementById("app");
const root = createRoot(container);
root.render(<App />);

We have the container element, but we are missing the App component so the application will throw an error. Let’s create the App component then.

Writing a React Component

We won’t create a separate directory for components. Let's place our tiny application in one component for demonstration purposes.

Note: When writing a production app, always design the React app using multiple components and follow the best design principles.

Create a file App.js in the app/javascript directory and place the application skeleton there, with the header as a placeholder:

import React, { useState } from "react";

export default function App() {
  const [books, setBooks] = useState([]);

  return (
    <>
      <h1>Books {books.length}</h1>
    </>
  );
}

Rendering a Book List

Now it’s time to render a simple list of books. To do this, we have to update the render function:

return (
  <>
    <h1>Books {books.length}</h1>
    <div>
      <table>
        <thead>
          <tr>
            <th>Title</th>
            <th>Author</th>
          </tr>
        </thead>
        <tbody>
          {books &&
            books.map(({ id, title, author }, i) => (
              <tr key={id}>
                <td>{title}</td>
                <td>{author}</td>
              </tr>
            ))}
        </tbody>
      </table>
    </div>
  </>
);

Create a New Book

We don’t have anything we can render. Let’s add the form to create a new book so we can fill our list with some data that we can later edit and delete if needed.

However, before we do this, we have to update our component to store some more information:

import { default as UUID } from "node-uuid";

const [action, setAction] = useState("list");
const [formData, setFormData] = useState({ title: "", author: "" });

I’m not going to create a separate component for the form, so I have to use a conditional in the render function. Thanks to the action, I can tell when to render the list or form.

Our render function is the following:

return (
  <>
    <h1>Books {books.length}</h1>
    {action == "list" ? (
      <div>
        <button onClick={() => setAction("form")}>New book</button>
        <table>
          <thead>
            <tr>
              <th>Title</th>
              <th>Author</th>
              <th></th>
            </tr>
          </thead>
          <tbody>
            {books &&
              books.map(({ id, title, author }, i) => (
                <tr key={id}>
                  <td>{title}</td>
                  <td>{author}</td>
                  <td></td>
                </tr>
              ))}
          </tbody>
        </table>
      </div>
    ) : (
      <div>
        <form>
          <label>Title:</label>
          <input
            onChange={(e) =>
              setFormData({ ...formData, title: e.target.value })
            }
            name="title"
            value={formData.title}
          />
          <label>Author:</label>
          <input
            onChange={(e) =>
              setFormData({ ...formData, author: e.target.value })
            }
            name="author"
            value={formData.author}
          />
          <button onClick={(e) => saveBook(e)}>Submit</button>
          <button onClick={() => setAction("list")}>Back</button>
        </form>
      </div>
    )}
  </>
);

Each time you type something into the title or author input, formData will update with values from the form. The last missing piece is the saveBook function:

const saveBook = (e) => {
  e.preventDefault();

  setBooks([...books, { ...formData, id: UUID.v4() }]);
  setFormData({ title: "", author: "", id: "" });
  setAction("list");
};

The first step is to prevent a form submission — we don’t want to reload the page. Then we update the books collection and reset the form data. The last step is to render back the list view.

Update an Existing Book

Let's reuse the form we created in the previous step. We also have to store the id of the book we are currently editing:

const [currentBookId, setCurrentBookId] = useState(null);

The editBook function will set the id of the book we want to edit. Fill the form with values and render the form view:

const editBook = (id) => {
  const currentBook = books.find((book) => book.id == id);
  setCurrentBookId(id);
  setFormData({
    ...formData,
    title: currentBook.title,
    author: currentBook.author,
  });
  setAction("form");
};

Since we are going to use the saveBook function for a creation and update action, we have to modify it accordingly:

const saveBook = async (e) => {
  e.preventDefault();

  if (currentBookId) {
    bookIndex = books.findIndex((book) => book.id == currentBookId);
    updatedBooks = [...books];
    updatedBooks[bookIndex] = formData;
    setBooks(updatedBooks);
    setCurrentBookId(null);
  } else {
    setBooks([...books, { ...formData, id: UUID.v4() }]);
  }

  setFormData({ title: "", author: "", id: "" });
  setAction("list");
};

Delete a Single Book

Let’s start with building the simple code for destroying the book:

const deleteBook = (id) => {
  setBooks(books.filter((book) => book.id != id));
};

We get the array of books that aren't deleted and update the books collection. React will update our component automatically.

The Complete Component

We implemented all the actions needed to create, update, list, and destroy a book. View the code for the complete component in this Gist.

Recap

Congratulations, you created a React application inside a Rails monolith! Let’s summarize what we have learned and done during this article.

Different Types of Architecture for Web Apps

When you build a web application, it has a front and back part. So you need to decide how you want to connect these two sides. Here's a reminder of the most common types of architecture:

Headless architecture - The front-end application is separate from the back-end. Choose it if you expect to write a lot of code, want to change technologies in the future, or expect a different workload for the front-end and back-end. However, keep in mind that such architecture increases the complexity of an application, takes more time to build, and the development process might be complex for a small development team.
Monolith architecture - One application that handles both front-end and back-end. You can build one with popular frameworks like Ruby on Rails or Django. With this architecture, you can build fast with a small team. However, you can run into trouble in the future if you want to change the technology or scale only part of the application.
Hybrid architecture - A compromise between a monolith and headless architecture. You build one codebase, but the front-end is served by a different technology from the back-end. The codebase might be hard to navigate, and it will be challenging to scale only one piece of the system. However, it is more flexible than a monolith. If you don’t like monoliths, but don’t want to fully detach the front from the back-end, this solution is for you.

The Design Process to Build Hybrid Architecture

Don’t jump into coding straight away. Think about the specifications of your application. When building a Rails application that uses a React framework for the front-end, you have to consider the following things:

Installation process - You can install React using import maps if you don’t need to use JSX templates. Otherwise, you can select package managers like Yarn or NPM, or install React using a Ruby gem.
Communication between Rails and React - Both applications are inside the same codebase, but need a bridge to exchange information. Use REST API for simpler applications and GraphQL for more complex interfaces where a lot of different data is necessary for the view layer.

Alternatives to React for a Rails App

If you decide that you don’t want to use React, but you like the idea of hybrid architecture, you can consider the following alternative solutions for the front-end:

Rails Turbo - With this library, you can split the page into independent frames and update them when needed. Go for this option if you like the Rails framework, and don’t want to write a lot of JavaScript code.
Stimulus JS - A small library for the HTML you already have in your views. Choose it when you are happy with your Rails monolith, but you want to make some views more interactive.
Other JavaScript frameworks - If you want to write more JavaScript, you can use Vue.js, Svelte, or Ember.js, instead of React. You can easily incorporate these solutions into your Rails application.

Summing Up

In this post, we explored the three main types of architecture — headless, monolith, and hybrid — and looked at their pros and cons. We then created a React application inside a Rails monolith.

Now it should hopefully be easier for you to choose the right architecture and tools for your next project.

Until next time, happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

5 Tips to Design Ruby on Rails Transactions the Right Way

Paweł Dąbrowski — Thu, 14 Apr 2022 10:20:20 +0000

Data integrity problems are among the most common database issues Rails developers face. Besides allowing for proper validation, correctly designed transaction blocks ensure that your data isn't partially created or updated.

However, transactions can also harm your application — or even take down your whole database — when not properly designed.

This article offers a set of good practices for working with transactions. The tips are pretty simple, but they will help make your transactions bulletproof, readable, and relatively safe.

Let's dive in!

1. Use Bang Methods in Rails When Possible

In Rails, method versions with ! can give you confidence that an error will be raised when something goes wrong.

For example, the #save method also exists in the save! version. You might want to use this version in the controller if you don't want to raise any errors:

def create
  user = User.new(user_params)

  if user.save
    # redirect
  else
    render :new
  end
end

The above approach won't work well in transactions. By using save, we can't roll back the process when the error is raised. That's why it is so important to use the ! version of the methods:

ActiveRecord::Base.transaction do
  user = User.create(user_attributes)
  user.memberships.create(membership_attributes)
end

In the above, the transaction succeeds even if the membership record isn't created, and we end up with a messed-up data structure in the database.

If you use the following version, the transaction reverts due to an ActiveRecord::RecordNotSaved error:

ActiveRecord::Base.transaction do
  user = User.create!(user_attributes)
  user.memberships.create!(membership_attributes)
end

2. Handle Errors in Rails Transactions Properly

When it comes to errors in transactions, there are a few rules that you should respect. By following these rules, you'll have readable and well-working code that will not create confusion among other developers or weird behavior that is hard to debug.

Do Not Rescue from `ActiveRecord::StatementInvalid`

ActiveRecord::StatementInvalid is a special error raised when something on the database level goes wrong. Never rescue from this error. You should always be explicitly notified when something goes wrong with the database query.

Avoid the following code:

def perform_action(...)
  User.transaction do
    # perform transaction
  end
rescue ActiveRecord::StatementInvalid
  # do something
end

Use the Rescue on the Right Level

If you use rescue on the following level, you'll catch the error:

User.transaction do
  user.perform_action!
  user.perform_another_action!
rescue SomeError
  # rescue
end

The transaction does not roll back because you caught the error. Let the error be raised and catch it outside the transaction block:

def some_method
  User.transaction do
    user.perform_action!
    user.perform_another_action!
  end
rescue SomeError
  # rescue
end

In the above approach, the transaction rolls back in case of an error, and you catch the error. This is the right approach to catch errors raised inside transactions without overwriting transaction behavior.

Do Not Catch Generic Errors

You should avoid catching generic errors like StandardError or ArgumentError. This is more like a general rule for readable and easily testable code, but it's worth mentioning.

Catching these errors can make debugging harder, as other places in the code may raise the errors. This could silence some serious issues in your app that are not necessarily related to the place you rescue them.

Use ActiveRecord's Default Rollback Error Wisely

ActiveRecord provides a particular error class that you can use inside a transaction to make a silent rollback. You roll back the transaction by raising the ActiveRecord::Rollback error, but the error isn't raised outside, as happens with other errors. Keep this behavior in mind and use it wisely.

3. Know When to Avoid Using Transactions in Rails

As with anything, you should not overuse transactions in your code. For example, a common mistake is to wrap only one query into your transaction. This does not make sense because, if the query doesn't succeed, there is no need to roll back anything.

Another common mistake is to wrap code unrelated to your database call into a transaction. You should avoid such an approach, as the transaction will hold the connection unless the code inside the block executes. Limit the code inside the block to call only your database, if possible.

4. Understand the Disadvantages of Transactions

Transactions help maintain data integrity inside a database, but you should also be aware of their disadvantages. For example, queries wrapped in a transaction block take more DB resources than single queries.

Another drawback of using transactions is that it leads to more complex code. Transactions can make your code less readable when used incorrectly.

5. Use the Transaction Block in the Right Context

You can use the transaction method when a class inherits from the ActiveRecord class. This does not mean that the version you use does not matter. Although it might not matter from a functional perspective, it matters in terms of ensuring your code is readable.

Three common versions use the transaction method:

ActiveRecord::Base.transaction
Model.transaction
Model.new.transaction

When you use many models and mix instance method invocations with classes inside a block, you should use ActiveRecord::Base.transaction:

ActiveRecord::Base.transaction do
  attributes = user.prepare_attributes(account)
  membership = Membership.create(attributes)
  LogService.log_creation(user, membership)
end

If you deal mostly with code that belongs to a given model, invoke the transaction method on a class:

User.transaction do
  user = User.create!(attributes)
  user.log_activity(‘creation’)
end

When you operate on a model instance, it makes sense to invoke the transaction method on the instance level:

user.transaction do
  user.make_transaction(attributes)
  user.log_activity(‘transaction’)
end

Of course, these rules are not official. They are just suggestions to make code more readable.

Next Steps: Review Transactions in Your Ruby on Rails Project

I hope you've found these tips for working with transactions in Ruby on Rails useful.

We've covered the importance of designing Rails transactions properly to improve data integrity and ensure that your processes perform without surprising side effects.

However, a proper error handling policy isn't only beneficial when using transactions — it will also improve your whole codebase. Keep that in mind the next time you expect your code to throw some errors.

Now is an excellent time to review transactions in your Ruby on Rails project design to avoid errors. Design for efficient and reliable communication with your database to make your application more stable.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Import Maps Under the Hood in Rails 7

Paweł Dąbrowski — Wed, 16 Mar 2022 13:15:12 +0000

Import maps is the new feature in Rails 7 that allows us to say goodbye to Node.js and tools like Webpack. There's no need for bundling anymore. With this new mechanism, you can still manage your JavaScript libraries with a specific version. Instead of one big file, though, your application serves many small JavaScript files.

It’s essential you know how import maps work to benefit from the newest version of Rails (but don’t worry, you can still use tools like Webpack instead). However, it’s also worth discovering what is happening under the hood. This way, you can better understand the journey from installing a JavaScript library in your project to serving its content to your users.

This article will show you how to install, serve, and uninstall JavaScript libraries with import maps and what happens under the hood during each phase.

The Core of Import Maps

The feature itself is not complicated. However, before I show you what happens inside the library, I would like to introduce the JSPM tool. JSPM is a shortcut for JavaScript Package Management. Thanks to this tool, you can load any NPM package inside the browser without extra tooling, and it will be fully optimized.

Rails uses JSPM to serve JavaScript libraries in your application. You can either download the source files to the vendor directory or serve the code directly from the URL.

For example, to access the jQuery library, you can call https://api.jspm.io/generate?install=jquery URL in your browser, and you will receive the URL to the minified source code in the JSON response. Of course, the service provides some more options for requests, but this knowledge is enough to understand how Rails cooperates with JSPM in the import maps library.

Install Import Maps in Your Rails Project

The import maps feature is available in Rails as a Ruby gem. If you generate a new project with Rails 7, it’s included in the Gemfile by default. You can add it to existing projects by executing the following command:

bundle add importmap-rails

Once you have the gem installed, you have to generate the required files by using the following command:

./bin/rails importmap:install

What does this command do, exactly? First, it calls the install rake task included in the importmap namespace. The gem delivers the rake task. Inside the task, the standard rails rake task is executed:

system "#{RbConfig.ruby} ./bin/rails app:template LOCATION=#{File.expand_path("../install/install.rb",  __dir__)}"

The install.rb file does a few things in the following order:

Adds helper to the layout in the head section - if the application.html.erb layout exists in your project, it adds the javascript_importmap_tags line before the closing </head> tag. This helper includes JavaScript libraries pinned by import maps. If your project does not include the standard layout file, it will render the information about the helper so you can add it by yourself.
Creates app/javascript/application.js file - it adds the comment about import maps to let you know that there is a new place where you should define dependencies.
Creates vendor/javascript directory - this is where JavaScript libraries will be stored if they are not served directly via a URL.
Updates sprockets manifest, if it exists - sprockets needs to know about the JavaScript files placed inside the vendor/javascript directory.
Creates config/importmap.rb file - this will contain the list of libraries used by Rails (something like package.json file).
Copies bin/importmap file and sets the correct permission to execute it - this file is used to pin and unpin specific libraries.

As soon as this process finishes, you are ready to install JavaScript libraries using the ./bin/importmap file, and Rails is prepared to serve those files to your visitors.

Adding Libraries to Your Rails Project

When installing a library with import maps, you have two options: you can either use the code directly from the CDN URL or download the file and serve it directly from your server.

Let’s explore the CDN option first.

Using NPM Packages via JavaScript CDN’s

It all starts with the pin command and the library name:

./bin/importmap pin jquery

You pass two arguments to the program located inside the ./bin/importmap file. importmap is an executable file that loads a config/application.rb file from your project and the import maps commands file.

Import maps use the Thor gem to handle command line programs gently. The first argument, pin, is the command name. When you invoke it, the following things happen under the hood:

Request to JSPM API is executed

As I mentioned before, the gem uses JSPM to get the contents of the package into our application. Therefore, the very first step is the request URL formation. Without any extra parameters passed to the pin command, the request URL is https://api.jspm.io/generate with the following parameters:

install - ["jquery"] - the param is an array because you can install multiple packages simultaneously.
flattenScope - true - with this param set to true, the returned import map format will be more straightforward without scopes, if possible.
env - ["browser", "module", "production"] - this is the list of environment condition strings.
provider - "jspm" - besides JSPM, Skypack, JSdelivr, and Unpkg providers are available to use as well.

Try accessing https://api.jspm.io/generate?install=jquery&flattenScope=true in your browser, and you will get a simple JSON response with some simple attributes.

Response from JSPM is parsed

Parsing is a very straightforward phase. As you saw, the response is simple, and all we need is the library name and CDN URL. The Packager class is responsible for parsing the response in the import map library. Instead of returning the attributes, it returns a complete line that you can use directly in the config:

%(pin "#{package}", to: "#{url}")

If you are not yet familiar with %(), don’t worry, as it works almost the same as the following:

"pin \"#{package}\", to: \"#{url}\""

The only difference is that the %() notation escapes the double quotes automatically. The generated config line passes to another function that handles the config file update process.

Import map config is updated

The last step is to update the config file with the pin definition. Because the previous pin definition can be present, the gem first verifies the config file and searches for the existing library definition. It’s simple to do with the regex:

/^pin "#{package}".*$/

If the pin definition for the given package is present, the gem replaces the line with the new definition. If the previous definition is not present, the gem adds a new line at the end of the config/importmap.rb file.

Note: When you use this method, keep in mind that this option is free, but one person supported by the community manages the JSPM servers. This situation could change in the future, so I advise you to store libraries locally if you plan to use import maps with production-ready applications.

Downloading NPM Packages

If you don’t want to use source code from a CDN URL, you can download the library to the vendor directory inside your application. In this case, the process is very similar to the case with CDN URLs. What's different is that the code is downloaded into a .js file before the config line is returned for an update.

The download process

The download process consists of a few small steps:

The gem calls FileUtils.mkdir_p, which creates the vendor directory if it does not already exist.
The gem calls FileUtils.rm_rf to remove the previous package file if it exists.
The gem saves JS code located under the JSPM-provided URL into the .js file and places it into the vendor directory.

If the gem cannot download the package’s contents, you will be notified by a proper error raised in your command line.

Config line generation

If the package is named the same as the file with the package source, the config line is straightforward:

%(pin "#{package}" # #{version})

Otherwise, the import map needs to map the package name to the file directly:

%(pin "#{package}", to: "#{filename}" # #{version})

When the config line is formatted and returned, the config is updated with the package definition (as described in the CDN URL version above).

Using Pinned Packages in Your Rails App

The gem extensively uses the Rails engine mechanism to deliver features. The Importmap::Engine defines a bunch of initializers that perform the configuration.

Import Pinned Packages from config/importmap.rb

The configuration lines inside the config/importmap.rb file are replaced with references inside the application. First, the gem collects all definitions into a hash where the Struct object represents each definition to make it easier to access specific attributes.

You can call Rails.application.importmap.packages to access the hash with all definitions inside the application.

Including References to Packages inside Views

When pinned packages are imported, you can include them in your views to provide the code. The gem provides a javascript_importmap_tags helper, which you can simply render in your layout. It uses Rails.application.importmap to generate JSON output for all pinned libraries, and with the usage of asset_helper in Rails, it provides the correct paths to the libraries.

After adding the following line to your head section of the layout:

<%= javascript_importmap_tags %>

You will get the following output (assuming that you are only using jQuery):

<script type="importmap" data-turbo-track="reload">
  {
    "imports": {
      "application": "/assets/application-37f365cbecf1fa2810a8303f4b6571676fa1f9c56c248528bc14ddb857531b95.js",
      "jquery": "https://ga.jspm.io/npm:jquery@3.6.0/dist/jquery.js"
    }
  }
</script>

Handling Import Maps by Browser

From that moment on, the browser handles the rest. If you are not familiar with the importmap script type, let me explain it quickly.

Import map simply controls what is fetched when you use the following statement inside your JavaScript code:

import "jquery";

Removing Pinned Packages

To remove a pinned package, you have to execute the unpin command:

./bin/importmap unpin react

You don’t have to pass the --download parameter because the gem will automatically delete any files related to the package. The removal process consists of three steps:

Request to the JSPM API - the same request is executed when the package is added. The gem does this to get up-to-date package information.
Removal of the existing package files - the gem uses FileUtils.rm_rf to remove all related files even if they are placed in directories.
Remove the config lines related to the package - with the usage of File.readlines, the gem loads all lines from the config file, selects those that do not contain anything related to the removed package and saves them again in the config file. Simple as that.

You can also unpin multiple packages at once; just add their names after the unpin argument.

Wrap Up

We've reached the end of this short, yet valuable, journey. You now know that import maps is just a different way of loading JavaScript libraries in your web application. Instead of one big bundled file, you serve multiple smaller files that are easy to cache and control.

With the importmap-rails gem, it’s easy to adapt import maps in your project. The gem ships with a simple configuration file and command-line interface to install and remove packages using the JSPM.

Should you use import maps in your next Rails project? As always, it depends. The good thing is that you are not limited to import maps — you can always switch between it, Webpack, and similar, more complex tools.

Thanks for reading and happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Solution for those who like Action Cable but hate writing JavaScript

Paweł Dąbrowski — Tue, 21 Jul 2020 13:02:02 +0000

Introduction

Cable Ready is a great addition for Action Cable, especially if you don't like to write JavaScript code to interact with your website's DOM in a real-time. It helps us to quickly write real-time applications that work out of the box.

To demonstrate the features that the gem provides, we will build a simple chat where new messages will appear on the website without reloading. We will start with creating a brand-new Rails application, creating a little code, adding the Cable Ready gem, and making things real-time.

Demo

At the end of the article, we will have fully working simple chat:

Creating example application

Our application will consist of only one model: Message. The model will have the following columns: username and body. The main purpose of the application is to let guests to simply write messages on the chat.

Application sekeleton

We will use Ruby 2.7.0 and Rails in version 6.0.3.2 . Since we don't need anything fancy on the database side, we will use SQLite as a database engine.

rails new chat
cd chat

Model

As mentioned before, we would need one model - Message where we will save the guest username along with the message that will appear in the chat. Let's create it:

rails g model Message username:string body:text
rails db:setup
rails db:migrate

Controller

We will need a controller to display messages and save new messages. Let's create one and save the following code into app/controllers/messages_controller.rb:

class MessagesController < ApplicationController
  def index
    @message = Message.new
    @messages = Message.order('created_at DESC')
  end

  def create
    Message.create!(message_params)

    redirect_to :messages
  end

  private

  def message_params
    params.require(:message).permit(:username, :body)
  end
end

update routes in config/routes.rb

Rails.application.routes.draw do
  resources :messages, only: %i[index create]
  root to: 'messages#index'
end

and create app/views/messages/index.html.erb view:

Current messages:

<ul>
  <% @messages.each do |message| %>
    <li><%= message.username %>: <%= message.body %>
  <% end %>
</ul>

<h2>Add new message:</h2>

<%= form_for(@message) do |f| %>
  <%= f.text_field :username, placeholder: 'username' %>
  <%= f.text_area :body, placeholder: 'message' %>
  <%= f.submit 'Send' %>
<% end %>

Now our "application" works but looks terrible and page is reloading each time we hit the Send button.

Adding proper styles to the application

Before we add Cable Ready to our application, let's refactor the look a little bit so it looks more like a web chat.

Bootstrap installation

We will use the Bootstrap framework to save tons of time and adding nicely look to our simple application. The installation process is simple and consists of two steps. The first one is to install the library using yarn:

yarn add bootstrap@4.3.1

and the second one is to load styles. Update app/assets/stylesheets/application.css and add the following line:

*= require bootstrap

Updating styles of messages list and new message form

Make sure that your app/views/layouts/application.html.erb looks like the following:

<!DOCTYPE html>
<html>
  <head>
    <title>Chat</title>
    <%= csrf_meta_tags %>
    <%= csp_meta_tag %>
    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
  </head>

  <body>
    <div class="flex-md-row p-3 px-md-4 mb-3 bg-white border-bottom box-shadow">
      <h5 class="text-center">Simple chat</h5>
    </div>
    <div class="container">
      <%= yield %>
    </div>
  </body>
</html>

and app/views/messages/index.html.erb :

<div class="row justify-content-center">
  <div class='col-6'>
    <div class="list-group" id="messages">
      <% @messages.each do |message| %>
        <a href="#" class="list-group-item list-group-item-action">
          <p class="mb-1"><%= message.body %></p>
          <small class="text-muted"><%= message.username %></small>
        </a>
      <% end %>
    </div>
  </div>
</div>
<div class="row justify-content-center">
  <div class='col-6'>
    <hr class="mt-3 mb-3"/>
    <h2>Add new message:</h2>

    <%= form_for(@message) do |f| %>
      <div class="form-group">
        <label>Username</label>
        <%= f.text_field :username, placeholder: 'username', class: 'form-control' %>
      </div>
      <div class="form-group">
        <label>Message</label>
        <%= f.text_area :body, placeholder: 'message', class: 'form-control' %>
      </div>
      <%= f.submit 'Send', class: 'btn btn-primary' %>
    <% end %>
  </div>
</div>

Now our application looks way better:

Making our chat real-time

It's time to update our code so new chat messages will appear without reloading the whole page. In the first step, we will update the form so the request will be sent in the background via AJAX, not as the normal POST request with redirection. In the second step, we will finally add ActionCable along with CableReady to make real-time updates.

Continue reading on https://pdabrowski.com/articles/cable-ready-with-action-cable

Value objects - a complete guide to Ruby code that is testable, readable and simple

Paweł Dąbrowski — Tue, 14 Jul 2020 11:48:17 +0000

Introduction

Regardless of the type of architecture do you like the most in Rails, you will find value objects design pattern useful and, which is just as important, easy to maintain, implement and test. The pattern itself doesn't introduce any unneeded level of abstraction and aims to make your code more isolated, easier to understand and less complicated.

A quick look at the pattern's name

Let's just quickly analyze its name before we move on:

value - in your application there are many classes, some of them are complex which means that they have a lot of lines of code or performs many actions and some of them are simple which means the opposite. This design pattern focuses on providing values that's why it is so simple - it don't care about connecting to the database or external APIs.
object - you know what is an object in objected programming and similarly, value object is an object that provides some attributes and accepts some initialization params.

The definition

There is no need to reinvent the wheel so I will use the definition created by Martin Fowler:

A small simple object, like money or a date range, whose equality isn't based on identity.

Won't it be beautiful if a part of our app would be composed of small and simple objects? Sounds like a heaven and we can easily get a piece of this haven and put it into our app. Let's see how.

Hands on keyboard

I would like to discuss the advantages of using value objects and rules for writing good implementation but before I will do it, let's take a quick look at some examples of value objects to give you a better understanding of the whole concept.

Colors - equality comparsion example

If you are using colors inside your app, you would probably end up with the following representation of a color:

class Color
  CSS_REPRESENTATION = {
    'black' => '#000000',
    'white' => '#ffffff'
  }.freeze

  def initialize(name)
    @name = name
  end

  def css_code
    CSS_REPRESENTATION[@name]
  end

  attr_reader :name
end

The implementation is self-explainable so we won't focus on going through the lines. Now consider the following case: two users picked up the same color and you want to compare the colors and when they are matching, perform some action:

user_a_color = Color.new('black')
user_b_color = Color.new('black')

if user_a_color == user_b_color
  # perform some action
end

With the current implementation, the action would never be performed because now objects are compared using their identity and its different for every new object:

user_a_color.object_id # => 70324226484560
user_b_color.object_id # => 70324226449560

Remember Martin's Fowler words? A value object is compared not by the identity but with its attributes. Taking this into account we can say that our Color class is not a true value object. Let's change that:

class Color
  CSS_REPRESENTATION = {
    'black' => '#000000',
    'white' => '#ffffff'
  }.freeze

  def initialize(name)
    @name = name
  end

  def css_code
    CSS_REPRESENTATION[@name]
  end

  def ==(other)
    name == other.name
  end

  attr_reader :name
end

Now the compare action makes sense as we compare not object ids but color names so the same color names will be always equal:

Color.new('black') == Color.new('black') # => true
Color.new('black') == Color.new('white') # => false

With the above example we have just learned about the first fundamental of value object - its equality is not based on identity.

Price - duck typing example

Another very common but yet meaningful example of a value object is a price object. Let's assume that you have a shop application and separated object for a price:

class Price
  def initialize(value:, currency:)
    @value = value
    @currency = currency
  end

  attr_reader :value, :currency
end

and you want to display the price to the end user:

juice_price = Price.new(value: 2, currency: 'USD')
puts "Price of juice is: #{juice_price.value} #{juice_price.currency}"

the goal is achieved but it doesn't look good. Another feature often seen in value object is duck typing and this example is a perfect case where we can take advantage of it. In simple words duck typing means that the object behaves like a different object if it implements a given method - in the above example, our price object should behave like a string:

class Price
  def initialize(value:, currency:)
    @value = value
    @currency = currency
  end

  def to_s
    "#{value} #{currency}"
  end

  attr_reader :value, :currency
end

now we can update our snippet:

juice_price = Price.new(value: 2, currency: 'USD')
puts "Price of juice is: #{juice_price}"

We have just discovered another fundamental of value objects and as you see we still only return values and we keep the object very simple and testable.

Read the rest of the article at https://pdabrowski.com/articles/rails-design-patterns-value-object

Ruby on Rails - list validators for a given model

Paweł Dąbrowski — Fri, 03 Jan 2020 14:28:34 +0000

You can easily list given model validators by calling validators method on the class name:

User.validators # => array of validators

If you define presence validator on your User model:

class User < ActiveRecord::Base
  validates :email, presence: true
end

you can access validator attributes the following way:

email_presence_validator = User.validators.first
email_presence_validator.class # => ActiveRecord::Validations::PresenceValidator
email_presence_validator.attributes # => [:email]
email_presence_validator.options # => {}

The options method returns options like :if or :unless conditions that are passed to the validator definition as extra arguments. Experiment with other types of validations to see how it's working.

Thank you for reading! Follow me on Twitter to be up to date with the latest tips, articles, and videos about programming.

Call Rails helper method from another helper method

Paweł Dąbrowski — Thu, 02 Jan 2020 11:36:39 +0000

Since 4 version of Rails, helpers are loaded in the view so it is possible to call one helper method from another one without including helpers:

module ApplicationHelper
  def some_method_from_application_helper
    # do something
  end
end

module AnotherHelper
  def do_something
    some_method_from_application_helper # will work
  end
end

Thank you for reading! Follow me on Twitter to be up to date with the latest tips, articles, and videos about programming.

Speed up development by adding bash aliases

Paweł Dąbrowski — Wed, 01 Jan 2020 14:58:37 +0000

Currently, I'm using two git accounts with separated keys, one for side projects and one for the company I'm working for. I have to switch to the second account each time I am using a new shell window and want to push changes using a different account:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/company

git push origin something

it is quite annoying. However, it can be easily replaced with a simple bash alias with a meaningful name that you would always remember.

Creating a bash alias

Mainly, there are two user-level files which system run when a bash shell starts - ~/.bash_profile and ~/.bashrc. You have to edit one of them to add our alias. The alias format is the following:

alias alias_name='command1;command2'

in my case I have to run two commands so the alias looks like this:

alias company_git='eval "$(ssh-agent -s)";ssh-add ~/.ssh/company'

Now I can simply type company_git in terminal each time I open a new shell window and I want to be ready to push some code to the company repositories. It's so simple but makes the development less frustrating.

Thank you for reading! Follow me on Twitter to be up to date with the latest tips, articles, and videos about programming.

Forem: Paweł Dąbrowski

Security Best Practices for Your Rails Application

Security in Your App: Best Coding Practices

Application Configuration

Force SSL

CORS

Secure Environment Variables

Business Logic

Strong Authentication and Authorization Rules

Authorization Best Practices

Code in Controllers

Filter Incoming Parameters

Use Scopes to Avoid Data Leaking

Avoid Insecure URL Redirects

Code in Models

Avoid SQL Injection

Prevent Command Injection

Avoid Unsafe Data Serialization

Code in Views

Avoid CSS Injection

Sanitize Rendered Output

Don't Include Sensitive Data in Comments

Habits to Keep Your Rails Application Secure

Upgrade Rails and Other Libraries Often

Perform Security Audits

Have A Proper Logging Strategy

Wrapping Up: Keep Your Rails App Secure

Connect a Ruby on Rails App with React in a Monolith

App Architecture: An Overview

Headless Architecture

Monolith Architecture

Hybrid Architecture

Designing a Monolith with React

Install React in Your Ruby on Rails App

Install React Using Ruby Gems

Install React Using Import Maps

Install React Using Package Manager

Communication Between Your Ruby on Rails App and React

REST Communication

GraphQL Communication

Front-end Alternatives to React for Your Ruby on Rails App

Rails Turbo

Stimulus JS

Other JavaScript Frameworks

Build a Monolith with React

Ruby on Rails Project Bootstrap

React Installation

Render a React Application in a Rails Layout

Writing a React Component

Rendering a Book List

Create a New Book

Update an Existing Book

Delete a Single Book

The Complete Component

Recap

Different Types of Architecture for Web Apps

The Design Process to Build Hybrid Architecture

Alternatives to React for a Rails App

Summing Up

5 Tips to Design Ruby on Rails Transactions the Right Way

1. Use Bang Methods in Rails When Possible

2. Handle Errors in Rails Transactions Properly

Do Not Rescue from ActiveRecord::StatementInvalid

Use the Rescue on the Right Level

Do Not Catch Generic Errors

Use ActiveRecord's Default Rollback Error Wisely

3. Know When to Avoid Using Transactions in Rails

4. Understand the Disadvantages of Transactions

5. Use the Transaction Block in the Right Context

Next Steps: Review Transactions in Your Ruby on Rails Project

Import Maps Under the Hood in Rails 7

The Core of Import Maps

Install Import Maps in Your Rails Project

Adding Libraries to Your Rails Project

Using NPM Packages via JavaScript CDN’s

Downloading NPM Packages

Using Pinned Packages in Your Rails App

Import Pinned Packages from config/importmap.rb

Including References to Packages inside Views

Handling Import Maps by Browser

Do Not Rescue from `ActiveRecord::StatementInvalid`