How to get around in your first Rails projects
Initially seeing a Rails project can be overwhelming and even intimidating because of the number of files and folders that are presented to you, all of this will make you think “Where do I begin?”.
To help you answer this and feel a little more confident in what you are
doing, I’m going to show you how to tackle the project piece by piece, so your ride would be easier and smoother and if you have a problem with the functionality, and believe me you will, you know where to go first instead of guessing what to do. So let's get to it.
doing, I’m going to show you how to tackle the project piece by piece, so your ride would be easier and smoother and if you have a problem with the functionality, and believe me you will, you know where to go first instead of guessing what to do. So let's get to it.
If you are using Rails you are going to use it to build the back-end of your
application, in other words, you are going to build the server that is going to process all the requests from the users. These requests are handled by routes, that are the endpoints of your application where you are going to either get, change, delete, or send data from your application.
application, in other words, you are going to build the server that is going to process all the requests from the users. These requests are handled by routes, that are the endpoints of your application where you are going to either get, change, delete, or send data from your application.
The default architecture followed by Rails is the MVC architecture, this
stands for Model View Controller. This said Rails creates an App folder, among many others, when you run the rails new command, and inside this folder, you will find the layout for the MVC, so you will have folders for each of the components of the architecture.
stands for Model View Controller. This said Rails creates an App folder, among many others, when you run the rails new command, and inside this folder, you will find the layout for the MVC, so you will have folders for each of the components of the architecture.
First, let’s start with the Model. Each model is, in plain and simple words, the layout for one of the tables from your database. In the model you can define relationships with models (called associations), you can define custom queries or operations to the database (called scopes) or you can define methods to address some combined information that you might need.
This is the most important thing in the design of your application because is the foundation for the whole project, so definitely spend a good amount of time thinking about how to divide the data into different tables (models) and how they are related to each other (one to many or many to many relations).
All the models for the application are stored in the path ./app/models/ and every model will have its own .rb file where you can define all the properties we discussed earlier and be able to add so much more stuff, for example, validations for your table fields.
Moving on to the next part of the architecture, a View is just the web page where the information is displayed to the user, in other words, is the front-end of the application. It can be done with any technology you prefer but Rails can generate some templates made with HTML-CSS and ERB (embedded Ruby) to make all the rendering if you find it more convenient. This part of the architecture is the one that interacts with the user and sends and receives data from the server (back-end).
Like the models, the views have their own path ./app/views/, where Rails by default will look for them. The subfolders in that path are one for each model and there is an additional folder called layouts, that stores the main templates for the whole application (rendered each time a view is accessed).
Last but not least we have the Controller. These are the middle man that helps the users as well as the database. The controller is the one that asks the database for the information required by the user and then passes it to the views for rendering.
Each model gets its own controller and they are all inside the ./app/controllers/ path. Inside each .rb file are methods defined to handle each endpoint or action in a RESTFUL manner (default behavior in Rails), but you can make any method you want in there and associate it with a custom endpoint.
The most common behavior for a controller would be asking for the data to the model first and then rendering the view in the case of a show action or getting the data passed by the user from the view and putting it into the database in the case of an edit or create action.
It is worth noting that each action has a corresponding view, ideally, with the same name as the method, so when the method in the controller is executed there is an implicit render statement at the end of it, rendering its view, but if you want to render a different view you just have to explicitly specify which view you want.
Finally, when you talk about endpoints, there is one last file that you need to check and modify when making a Rails app, this file is the routes.rb located in the ./config/ path. This is where all the points of entry to your application are controlled and you can generate or remove these points as you need, and also configure which method from which controller will be in charge of it.
So in this article, we took a glance at how to approach a Rails project as a beginner, looking at the most important components of the MVC architecture, how they are represented inside the Rails project structure, and how they connect with each other.
If you want to dig deeper into model associations, field validations, scopes, controllers, view rendering, or general file structure, you can go to the following links and read about them.
I hope this will help you to feel less overwhelmed by Rails and make it easier for you to understand what is going on as you start your journey in this great framework.
Thank you so much for taking the time to read this all the way to the end, and I wish this will help you take that first step into developing with Rails.