# Ruby on Rails ### The Magic Ingredient 3 words: **Conventions over configuration**. ## Basics {% embed url="" %} 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 ![](https://i.pinimg.com/originals/13/52/92/1352927bf6c754be8abad20bbf1b7bac.png) ### 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/](https://434471908-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LsMtxmH6ixcLmlwG2Vl%2F-LwI3laGfGq_S9TtYwug%2F-LwI5J1Z3jXDuuzZfyYk%2FCapture%20d%E2%80%99e%CC%81cran%202019-12-17%20a%CC%80%2010.01.26.png?alt=media\&token=63c86b1b-aa34-4fee-8c2b-bff1b97c1481) 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](https://prospect-io.gitbook.io/developer-playbook/our-stack/ruby-on-rails/controllers), then just continue the flow from there. ## References ### Documentation {% embed url="" %} {% embed url="" %} ### Interesting newsletters {% embed url="" %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://prospect-io.gitbook.io/developer-playbook/our-stack/ruby-on-rails.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.