Humans are continuously making decisions about their personal and professional life. Decisions are made based on previous experiences, other people's help or coach, books you read, podcasts you hear, and people you know and trust.
As engineers, we're making decisions and questioning ourselves all the time. For instance: which technology to study next? What's the focus I want to keep during my career? Should I do a Class or a simple method?. Should I learn the front or back end? Where do I feel better with these technologies? What kind of skills are companies needing? Where are the best salaries? Do I want to build something from scratch? Do I want to launch a startup or idea?
As you can see, we all are exposed to these kinds of decisions almost daily, and you have to be clever or at least choose the type of things that make you happy. Probably I'm not the best person to guide you on this decision because I'm complete in Ruby on Rails, so I'm skewed to this technology. But what I can do is tell you my story in a couple of sentences.
My Short Rails Story
Convention over configuration
As I mentioned before, we as engineers need to make choices all the time (technical and non-technical), and knowing the fact that there are things well established, we don't have to reinvent the wheel each time we want to build something. The Model-View-Controller pattern gives you the proper structure to start. We can think of other business-related differentiators with a good skeleton in place and start working on them as features. When we have all of that included in a framework, it doesn't make sense to think about booting a server or structuring project folders.
In JS, everybody does everything differently, there is no consensus, there are so many fancy new things you don't know if they will become standard or not, and it is so wordy, so verbose.
It is the complete opposite of organized and straightforward. I use it and understand the basics, but I don't want to go deeper into something that doesn't make me happy but frustrated. In my opinion, Ruby is simple, organized, standard, clean, wordless, and makes me happy. Same thing with Rails. It's a personal opinion; it is my personal happiness.
A quick comment here: I'm not the radical Ruby advocate who hates everything else; I actually learned Data Science with Python stack (which I also love). During my career, I've learned a lot of different technologies. If you're just starting, be always open-minded and learn new things, but finally dedicate your efforts to just one thing because it's simple: you'll get a competitive advantage if you focus on just one thing.
But what is Rails?
Ruby on Rails' emergence in 2005 greatly influenced web app development through innovative features such as seamless database table creations, migrations, and scaffolding of views to enable rapid application development. Ruby on Rails' influence on other web frameworks remains apparent today, with many frameworks in other languages borrowing its ideas, including Django in Python; Catalyst in Perl; Laravel, CakePHP, and Yii in PHP; Grails in Groovy; Phoenix in Elixir; Play in Scala; and Sails.js in Node.js.
The model–view controller (MVC) pattern is the fundamental structure for organizing application programming.
Personally, when I explain the concept of MVC, I always add another component to the image, called Routes, so we can talk about MVC/R. For example, let's see the following diagram.
The Rails router recognizes URLs and dispatches them to a controller's action or a Rack application. It can also generate paths and URLs, avoiding the need to hardcode strings in your views. Rails encourage developers to use RESTful routes, including actions such as create, new, edit, update, destroy, show, and index. These mappings of incoming requests/routes to controller actions can be easily set up in the routes.rb configuration file.
A controller is a server-side component of Rails that responds to external requests from the webserver to the application by determining which view file to render. The controller may also have to query one or more models for information and pass these on to the view.
For example, in a subscription system, a controller implementing a subscription-search function would need to query a model representing individual subscriptions to find subscriptions matching the search and might need to query models representing users and magazines to find related secondary data.
The controller might then pass some subset of the subscription data to the corresponding view, which would contain a mixture of static HTML and logic that use the subscription data to create an HTML document containing a table with one row per subscription.
A controller may provide one or more actions. In Ruby on Rails, an effort is typically a basic unit that describes how to respond to a specific external web browser request. Also, note that the controller/action will be accessible only for external web requests if a corresponding route is mapped.
In a default configuration, a Ruby on Rails framework model maps to a table in a database and to a Ruby file. So, for example, a model class Product will usually be defined in the file product.rb in the app/models directory and linked to the table products in the database. While developers can ignore this convention and choose different names for their models, files, and database tables, this is not common practice and is usually discouraged by the "convention-over-configuration" philosophy.
A view in the default configuration of Rails is an erb file, which is evaluated and converted to HTML at run-time. Alternatively, many other templating systems can be used for views.
Ruby on Rails includes tools that make everyday development tasks accessible "out-of-the-box," such as scaffolding that can automatically construct some of the models and views needed for an essential website. Also included are WEBrick, a simple Ruby web server that is distributed with Ruby, and Rake, a build system distributed as a gem. Together with Ruby on Rails, these tools provide a basic development environment.
Ruby on Rails is separated into various packages, namely ActiveRecord (an object-relational mapping system for database access), Action Pack, Active Support, and Action Mailer. Before version 2.0, Ruby on Rails also included the Action Web Service package that is now replaced by Active Resource. Apart from standard packages, developers can make plugins to extend existing packages. Earlier Rails supported plugins within their own custom framework; version 3.2 deprecates these in favor of traditional Ruby "gems."
As you can see, we have a lot of things to learn and practice here, so the following posts will be following this very same order: Routes, Controllers, Models, and Views. We'll be discussing each component in detail, and we'll make an example application.
I hope you learned a lot.
Thanks for reading