Building My First Sinatra Application

While learning about Sinatra, my worldview as to how the internet operates has really expanded. Sinatra is a lightweight web-framework implemented using Ruby. In essence, Sinatra contains a library of Ruby methods that can turn a Ruby application into a dynamic web application. In conjunction with ActiveRecord, which is the database side of the application, Sinatra provides all the methods necessary to implement a web application with a working server and database. Sinatra is designed to be the gateway into full-stack development by introducing a simple, yet powerful way to implement a Model-View-Controller(MVC) web application.

The Project Requirements

Without some guidance, this project would have been a nightmare. Luckily, the project’s requirements were clear and familiar enough for me to be able to implement a small web application. The requirements are as follows:

• Build an MVC Sinatra Application.
• Use ActiveRecord.
• Use multiple models.
• Use has_many and belongs_to relationships.
• Have user accounts (sign in, log in, log out).
• Once logged in, the user can Create Read Update Destroy(CRUD).
• Users can only CRUD their own resources.
• Validate user input to catch bad data.

By the time I started this project, I had finished plenty of labs that prepared me for the road ahead. I had the methodology to build the project, now I just needed an idea. I enjoy fashion and clothes, so it was a natural next step to build an app that could be like my virtual closet. I called it Outfitt3r!

Building Outfitt3r

I survived to the end of Phase 2 of the Flatiron Software Development Bootcamp, so I knew the road ahead of me would be demanding. The biggest problem I faced as I started building Outfitt3r, was that there were no tests for my work. Everything was either working or not working, and it was all up to me to keep pushing forward and solve every cryptic NoMethodError and undefined variable messages I kept encountering at nearly every turn. However, the MVC standard structure and the accessibility of ActiveRecord really helped me set up my application in a way that I could easily troubleshoot as needed.

Part of the Project Structure

Models

Given the requirements, I knew I needed at least two classes that would have a has_many to belongs_to relationship. This was relatively easy to do since ActiveRecord can keep track of these relationships and make it accessible throughout the application. I kept it simple with two classes:

1. Users Class: has_many Outfits and has_secure_password.
2. Outfits Class: belongs_to User.

Views

The views were actually the trickiest part to implement. Since this merges together HTML and Ruby logic, everything needs to be written very accurately, as it was in the ERB views that most of my errors were emerging.

• User Views: They are in charge of authentication for the user. It includes the sign-up view that allows for user creation given a password, email and username. It also includes the sign-in page that allows the user to log-in to the main application view.
• Outfit Views: These views include the main pages that give the application its actual functionality. It is here where the user can perform CRUD actions on their own resources. I also implemented a view that allows the user to browse through other user’s outfits and add it to their own library, without affecting the original outfit.

Controller

This is the part that ties it all together, it is the brain that connects the models and the views to the internet. All types of HTTP requests, such as GET and POST requests, are processed by the controller and sent to their appropriate route. The parameters collected at the views, in conjunction with ActiveRecord, are used in the controller to perform all of the data manipulation needed for the application to function properly.

• Users Controller: This controller ties all the user views together by declaring all the routes for each type of HTTP request. It is also in charge of checking whether the data obtained from the sign-up and log-in views is safe to use.
• Outfits Controller: Similar to the users controller, all the outfit routes are declared here. There are much more routes to be taken care of, since the user can perform CRUD actions on their outfits. Users can create a new outfit, read each of their outfits, update / edit their outfits and delete outfits. They can also add an outfit to their library from the collection of outfits from other users.

Wrapping Up

This was one of the most interesting projects I have worked on by myself. I learned a lot of new aspects of the internet that I had always seen but never actually learnt in depth. Using HTTP requests and processing them in my own local environment was thrilling. Even the process of troubleshooting was fun because it gave me a lot of insight as to how big tech companies take all these considerations and precautions for their applications to be safe for the users and for their own internal systems. Given more time, I would do more input sanitization so that malicious data cannot enter the database and modify the application logic leading fatal failures. I now feel, I am one step closer to a brand new career where I can have a fresh outlook on tech.