The Basics of Rails App Development
Its nearly 4am on a Saturday and I have about 20–30 tabs open, all of them related to Rails app development. All of my efforts for the last week and a half have been focused on creating a Ruby on Rails app to meet project requirements set forth by Flatiron. To be frank, I’ve already completed a Rails app earlier in the week but I wanted to build another one featuring elements that would entertain the masses. I did not foresee the harrowing experience of this endeavor. From debugging for hours on, end to learning morse code algorithms and reading countless Rails docs, mental fatigue has stricken me. Yet, deep down, a new identity begins to materialize. It is in the past 24 hours, nearing the completion of my Ruby on Rails project that I am starting to identify myself as a software engineer. And this, has made every sleepless night, every hair pulling red wall of errors moment, so worth it.
Understanding Rails App Architecture
To start, Rails app development is incredibly delightful. I would preface my last comment by stating that app development in Sinatra is extremely encouraged if you want to soften the seemingly steep Rails learning curve. Rails follows an MVC(Models, Views, Controllers) architecture for app development. MVC architecture follows a design principle called separation of concerns which aims to separate core responsibilities for a more efficient working environment. For the uninitiated, you are reading this article through what is called a View, the View packages the data you initiate, such as clicking this link here, and sends it to the Controller which manages the information between the View aka browser and the Model. The Model receives your requested data and connects to the database to find relevant data which it then passes to the Controller and then to the View. Imagine placing all of these parts into one file and then envision yourself trying to change an existing feature, it would be a very difficult challenge since it would be hard to discern where everything is located. We avoid this by adopting good app design principles such as MVC architecture.
So now we hopefully have a better understanding of what MVC is, but then what do we build first? We start by building the database and foreseeing to the best of our ability, what our app will turn out to be. In order to build the database we have to envision what our Models will be since they will assume the primary responsibility of communicating and retrieving data from the database. Fortunately, Rails gives us powerful tools to quickly create databases. Tools such as rails g resources, rails g models, rails g controllers, etc. After we have created the database and Models, we would determine how and if our Models are connected. For example, if I had Models Chef and Recipes, and I knew that my app would have to display the recipes of a particular chef then here is where I would apply an ActiveRecord macro association called belongs_to . This is the foundational development of building an app.
Next, we would want to construct our Controllers which is the bridge between the end user and the database. Controllers follow pretty DRY coding patterns which usually involve user validations, requesting data, redirects, and sending information to the Views. Controllers also employ RESTful coding principles in tandem with CRUD. Furthermore, the relationship between a Controller and a file within an app called routes.db is how we are able to generate the nifty URLs you see in a web browser. Additionally, Controllers are where we actually allow a user to sign up and/or login to an app, pretty cool right. Personally, it feels very satisfying knowing that I have the means of determining your access to my app :).
The last part of the puzzle involves creating the Views which presents data to the end user. Elements such as forms, font styling, buttons, search fields, images and more are all rendered by data that has been programmed into the View and received from the Controller. Following our principle of separation of concerns, it is important that we never employ database level actions within our Views since this exposes an app to hacks such as SQL injections.
Why is Rails so Powerful?
In short, the power comes from quick app development turn around time and incredible resources that come in the form of RoR gem libraries, extensive api documentation, an ocean of Rails online forums and resources, and the beauty of the Ruby language. Gem libraries such as Devise have helped speed up my app development so much, it has given me time to add new features to my final Rails project.
Are there disadvantages to Rails? Absolutely, because of the nature of Rails commands that generate entire app file structures one can easily find themselves overwhelmed with the amount of information and quickly get lost which is why getting started with Sinatra, think of it as toddler Rails, is a great stepping stone to Rails. Understanding the behind the scenes of the day to day mechanisms a Rails developer uses such as rails g resources is a great way to become a solid RoR developer.
My Final Thoughts
Looking back at my Rails starting point, I have a sense of pride observing the long road I have traveled. There were several setbacks such as reviewing documentation over and over, testing out different ways to solve a problem, understanding why that darn instance variable in my View file is nil. Every problem surmounted has given me my new identify as a software engineer and I couldn’t be happier.
