Ruby on Rails

Ruby on rail is our main backend framework at Prospect.io

The Magic Ingredient

3 words: Conventions over configuration.

Basics

Ruby on Rails (also known as rails) is a web application framework (backend), which presents as a set of ruby gems (aka libraries).

Code Organization

Framework

Rails organization is made around some main components, making what we call the MVC framework:

  • Model : The representation of the data stored in the database

  • View : Something that we can display

  • Controller : The logic for handling a web request

At Prospect, we don't really use the View part of Rails, since we're using Ember for the frontend, and reserve it for a very little subset of elements (mails, PDFs, ...). That's the API configuration of Rails.

Apart from that, Rails also includes a set of other components:

  • ActiveJob : A system for background action processing

  • ActiveMailer : A system to send mails

  • ActiveRecord: A full featured ORM

  • ActiveStorage : A system to attach files to models

Components

Rails also come with some components:

  • Puma: A web server for running rails

  • Rake : A system for running tasks

  • The rails console: An interpreter of ruby code, which runs in the context of the current rails app (with all models loaded, ...)

MVC & Service Oriented Architecture

To implement that in Rails, we decided to split our code in two parts:

Business logic:

  • models

  • services

Technical elements:

All the technical components of our applications that do not relate to business logic:

  • controllers

  • params

  • serializers

  • commands

  • jobs

  • libraries

Rules

We define strict rules on the roles of each elements:

  • controllers: handle an HTTP request

  • params: parse & validate the HTTP parameters

  • commands: call services and format their results

  • models: represent database information (and should be as simple as possible)

  • services: perform business logic (that's were the complex parts go)

  • jobs: for asynchronous processing

  • libraries: for non-domain-related utilities (like text processing)

The relation between those elements is unidirectional: technical elements can call business logic, but not the opposite.

Source: https://study.dnsimple.com/resources/maintaining-rails-hanami/

As you can see, we use a variety of classes to implement this service oriented architecture.

We will talk about each and every one of them in the subsection of this page. It will allow you to see how we implemented our framework and see a complete flow of execution.

If you discover Rails and our framework for the first time, we highly recommend you to check these out. You can start by learning about controllers, then just continue the flow from there.

References

Documentation

Interesting newsletters