Ruby on rail is our main backend framework at Prospect.io
The Magic Ingredient
3 words: Conventions over configuration.
Ruby on Rails (also known as rails) is a web application framework (backend), which presents as a set of ruby gems (aka libraries).
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
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:
All the technical components of our applications that do not relate to business logic:
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.