A Sinatra Web App for Boulderers

My Sinatra-powered web app — Bolderer, is designed for boulderers who are eager to track their climbing progress, strengths and weaknesses by logging routes/ problems that they have climbed. They can also see others' profiles since bouldering is a personal yet social sport, where the climbing community is supportive and would always cheer for your 'sends'.

I started my project by mapping out the models and their relationships with one another. This helped me plan the models, database tables, and the has_many, belongs_to and many-to-many relationships on the models.

Bolderer Association Diagram:

Key Concepts

I would like to highlight some key building blocks of my Sinatra project — MVC, Sessions, CRUD Actions, and RESTful Routes, which have allowed me to create a functional app and taught me the base concepts of a Content Management System (CMS).

Model-View-Controller (MVC)

An organized way to build frameworks for web apps.

I found this immensely useful in helping me structure my code. It provided a separation of concerns by grouping my files by functionalities -- Models (logic, where data is manipulated and saved), Views (front-end), and Controllers (middleman - relays data from browser to app, and from app to the browser).

My MVC directories:

User Password Encryption with BCrypt

I used the Ruby Gem BCrypt to secure the users' data by encrypting their passwords. It allowed my app to sign up and log-in a user with a secure password.

Implementing Bcrypt by adding the password column as pasword_digest in my users table:

class CreateUsers < ActiveRecord::Migration
  def change
    create_table :users do |t|
      t.string :username
      t.string :password_digest
    end
  end
end

I also added ActiveRecord's macro has_secure_password to my User model, which let me access the user's password attribute even though the users database only had the column called password_digest.

The macro also provided another useful method, authenticate:

post '/login' do
    user = User.find_by(username: params[:username])

    if user && user.authenticate(params[:password])
      #storing user_id key in session hash
      session[:user_id] = user.id
      redirect "/users/#{user.id}"
    else
      @error = true
      erb :"/users/login"
    end
  end

The User's authenticate method turned the user's password input into a hash that would get compared with the hashed password stored in the database. If the user authenticated, the method would return the User instance; otherwise, it would return false. This was helpful for logging in users.

Sessions and User Authentication and Authorization

• Sessions were used to verify a user's identity, as the users were requested to verify their identity by logging in with valid credentials

• Hence, I used sessions to filter and dictate what a user could see or edit:

  • The users could only view the Problems index page if they were logged in
  • The users could only edit/ delete the resources (problems) that they created

• To use sessions in Sinatra, I enabled my application to use the sessions keyword to access the session hash:
  
  

  configure do
    set :public_folder, 'public'
    set :views, 'app/views'
    enable :sessions
    set :session_secret, "session_encryption"
  end

• When a user signs in successfuly, the user_id key would get stored in the session hash: session[:user_id] = user.id.

Defining RESTful routes

Another key lesson was learning to use restful routes to implement CRUD actions. I realized how important it was to plan my routes in order to handle the HTTP verbs and URLs in an organized and standardized way.

I designed my ProblemsController, UsersController and SessionsController controller actions to follow restful conventions and to map the HTTP verbs (get, post, patch, delete) to the controller CRUD actions.

For my app, I wanted a logged-in user to be able to access all CRUD actions: the ability to create sessions (login)/ problems, read, update or delete their own problems.

My Problems Controller:

My Users Controller and Sessions Controller:

Other resources:

• Seeding Data: The dummy data was very important as it helped to demonstrate to the first user(s) how this web app could be used. There was the option of using APIs to seed data (especially for general topics like recipes), but I decided to create my own instances of Users, Problems, and Styles and their associations to make my data more personal (as it reflected my actual bouldering logs)
• Bootstrap: This allowed me to add styling to my forms, buttons, etc. without having to build the CSS from scratch