Important Default Rails Gems and Their Usages

Rails is a pretty useful tool for building web apps. You can build your backend and frontend totally with it, also communicate with your database and after deployment, your app server and web server communication work smoothly. After I learned Rails, (it’s still an ongoing process :)), I’ve realized Rails is heavily depends on some gems. Those gems are basically, the shared products for doing certain tasks, and Rails is using them at different parts of the app and for different purposes. In this article, I’ll try to explain them briefly. Whether if you are a newbie or you know how to build apps but not sure about some parts of Rails, I think this article could be helpful for you.

The Gem List

• Actioncable
• Actionmailer
• Actionpack
• Actionview
• Activemodel
• Activerecord
• Bundler
• Rack
• Rake

Actioncable

Actioncable is a tool to integrate WebSockets into your Rails application. If I want to summarize Websockets, they are using WebSocket protocol to communicate with your app, and they are giving some real-time features to your app. They provide a duplex type of communication over a single TCP channel. I don’t want to dive deep into these protocols now, if you are curious about them, you can check the links and with an easy google search, you can find very useful books to learn them by heart.

If we go back to actioncable, it has some certain terminology that you need to understand. Those are connections, consumers, channels, subscribers, Pub/Sub, and broadcastings.

Connection as the name implies provides a connection between a server and many clients. I’m telling many clients because a single actioncable server can handle multiple connection instances. Yes instances, so every client connection is an instance of a connection. Also, a client can have multiple instances, which means different connections with the server.

Consumer as the name implies is a server-client, who uses actioncable to connect. It is created by the client-side Javascript framework.

Channels are also pretty self-explanatory, are a unit of logic, that works depending on the developer and the user expectations. A user can subscribe to different channels and with the help of these different channels, a user can have multiple connections for different purposes. A channel is like a controller as in the MVC architecture.

Subscriber is the client, who subscribes to a channel uses the connection and gets the real-time features with the help of the actioncable.

Pub/Sub is the term to explain the one server is sending the data to an abstract class of receivers, without specifying the subscriber. Actioncable uses this approach to have multiple channels and connections.

Broadcasting is the pub/sub link to navigate this data to a specific channel and the subscribers of this channel.

The information above is the skeleton of the actioncable. If you got the idea of server-client working simultaneously, the OOP principles and from an abstract class instance to a certain client, and the similarities between a controller and a channel, just navigate to the actioncable link I gave in the beginning, check the examples and implement your WebSocket as per your needs. I’m not gonna give any code in here, just want to summarize the logic.

Actionmailer

If you initiate a Rails app, you see a directory, mailers. We are going to talk about this directory in this section. I’ve used this feature once for one of my freelance duties, to notify the users about their transactions and the bought products. The thing that I understand from the mailer, they are also like a controller and if a certain action is triggered, they start working and send the mails with the params that you configured the actionmailer. As a side note, mailers also use a different type of protocol SMTP, that you need to configure in your initializers. I’m learning these protocols nowadays so just wanted to mention this area of the web that needs to be covered if you want to improve yourself.

If we go back to actionmailer again, the created mailer has a controller which inherits from ActionMailer::Base, there you can create your logic and send your params to here.

A simple example of this, which inherits from ApplicationMailer which inherits from ActionMailer::Base.

class UserMailer < ApplicationMailer
 def welcome_email
  @user = params[:user]
  @url = "http://example.com/login"
  mail(to: @user.email, subject: "Welcome to My Awesome Site")
 end
end

After this logic, you need to create a view for your mails. For this, I used a text.erb and html.erb templates. If one of them fails to render, the other can help your clients to see the content. I mentioned to you earlier, you need to configure your actionmailer delivery method. For this, I prefer to use production.rb inside the initializers. There you can use the config object and give necessary features to your actionmailer. I’m giving one example here;

config.action_mailer.delivery_method = :smtp
host = "https://example.com/" #replace with your own url
config.action_mailer.default_url_options = { host: host }
# SMTP settings for gmail
config.action_mailer.smtp_settings = {
:address => “smtp.gmail.com”,
:port => 587,
:user_name => "example@gmail.com",
:password => "123456789",
:authentication => "plain",
:enable_starttls_auto => true
}

After all these, you can call your created controller method where you need it, and the templated mails will be sent to their destinations.

Actionpack

To my understanding actionpack is the roof for MVC architecture. It gives functionality to controllers, routing, views. Basically, it’s the layer that connects views and controllers. It uses Action Dispatch which parses the web request information, and Action Controller which provides a base for all the controllers a Rails developer uses.

Actionview

Actionview provides us to use embedded ruby templates. Action Controller handles the web request and actionview compile the response. I don’t want to dive deep into this, if you are curious about and learn more, please refer to the given link. The part that I’m interested in, you can use Rails scaffolding commands and get a template view to use. After that, you can easily change them as per your needs and their syntax is so close to HTML.

Activemodel

Activemodel is the part, that gives life to Active Record. It also gives us some callbacks and validation methods to use. I just want to mention this, again not gonna give deep. Because as an ORM we developers mostly face Activerecord. The methods that activemodel gives come to us from inheriting the ApplicationRecord, so we can talk about them when we talk about Active Record. However, if you are curious or want to do some metaprogramming I highly recommend you to check the given API link, so you have a better understanding of activemodel. It is basically, the part responsible for the model part and the methods to protect your app and parameters.

Activerecord

This one impresses me a lot. It takes lots of functionality from activemodel, and with the help of it, you can create your schema for your database, you can manipulate your database with ease without thinking about SQL syntax. It is an object-relational mapping, so it maps out your logic to your database and from the app, with a clean syntax you can arrange your relations, manipulations, and so on. Also, the given class which inherits from ApplicationRecord, there you can have model-related custom logic. I’m giving their GitHub repo, just navigate through the repo. After this, you can have more ideas about ORM and also some nice Ruby techniques that you can learn.

As a summary, it has naming conventions, which automatically map the tables in your database to your models, it has validations that you can control and protect your database, and a lot of callbacks during the model creation phases, you can interact with your app and database.

Bundler

I’ve never thought about it at low level. However, it is super powerful and helpful. If you have Ruby and RubyGems installed on your machine, you can directly start with it. You can install the Bundler with `gem install bundler` command and then in your Rails project if you specify the gem you need all you need to get the gem is just type `bundle install` at your terminal. It adds the gem to your app, and from the gem.lock file, you can check the versions of the gem. As I told you I don’t have low-level information about it, want to talk about it here because it is something very important. As a side note, I have some bad memories about it while deploying, because of the version conflicts of the bundlers. So keep in mind that, before writing your code, if you know where you’ll deploy the app, check the bundler requirements so you won’t spend days as I did.

Rack

Rack is the app server, that Ruby uses for Rails. An app server is a thing that wraps the HTTP request and communicates with the web server via the app’s commands. From the blog post, I’ve read earlier; “Informally, a Rack application is a thing that responds to #call and takes a hash as an argument, returning an array of status, headers, and a body.”. So it takes the request and split the request into its components and responds to it with the call method. When you say it like that it sounds a bit easy but query parsing, cookie handling, communicating back and forth with the web server is a ‘real’ thing that we need to think about when we write applications. The rack has multiple middlewares that developers can use. I’m giving their GitHub repo as a conclusion.

Rake

Rake is a task runner, that you can call default tasks at your terminal or add more tasks to your application. Rails comes with lots of default tasks, for example, rails new, or rails generate… Those tasks are helping buddies while you are building your app. Rake is the part that is responsible from that point. If you can imagine a scenario like this, you need to run a background job, that checks the waited response from an external API. There are some approaches to this problem but one of them is writing a rake task, containing it inside the tasks folder in your app, bind it with the background job. After these configurations, all you need to do is run the rake task and the rest will work in the background. With rake, you can open the console or db console, check your routes, initiate your local server, and so on. So it’s basically the task that is not directly ‘inside’ your app but helping the app to get its shape.

Conclusion

Apart from those gems, there are more built-in gems and some gems that you’ll need to add while working. I haven’t talked about them in this article, hope to write about them in the future. Also hope to help you understand the basics about them and where to look at them.