Brewpedia is a Wikipedia inspired Ruby on Rails SaaS app where users can create and collaborate on Markdown-based wikis.

Explanation

This project was part of the Bloc Full Stack Developer program to reinforce backend programming fundamentals and deepen my knowledge of Ruby on Rails. I was given a set of user stories and tasked with building a web app from scratch to meet each one of these needs and make all design decisions.

Project Objectives

  • Users can sign in and out of Brewpedia
  • Users with a standard account, can create, read, update, and delete public wikis
  • User roles available: admin, standard, or premium. Standard account is the default role assigned to new users.
  • Users can upgrade account from a standard to a premium account and downgrade their account back to standard
  • Users can create private wikis. When downgrading their account all private wikis become public
  • Users can edit wikis using Markdown syntax
  • Users can add and remove collaborators for private wikis

Solution

Having manually created user authentication and authorization in my previous Rails project, I used the Devise Gem for a different experience on this project. After installing Devise I generated the Devise User model and defined the Devise modules I needed then integrated SendGrid to send confirmation emails in production. The Figaro Gem was used here for secure configuration of SendGrid username and password.

I wanted users to be able to view the welcome and about views without having to sign in so I used skip_before_action on the authenticate_user! callback in the Welcome controller to achieve this. I also installed Devise views to allow for customization later on.

With sign up, sign in and sign out setup the next step was to generate the Wiki model, Wikis controller and Wikis views. I set the Wiki Model to belongs_to :user and validated the length and presence of a wiki title and body. In the Wikis controller all CRUD actions were defined and routes/resources setup. The index, show, new and edit Wikis views were also built out. At this point users can view, create, edit and delete public wikis.

To setup multiple roles I used an enum role: on the User model with attributes for :standard, :premium and :admin. I then used after_initialize callback to set the default role to standard.

I installed the Pundit Gem to use for authorization. I used Pundit’s scope to restrict which wikis appear on the private wiki index page for each user by adding an inner Scope class to wiki_policy.rb. I also defined destroy in the wiki_policy.rb so only admin or the wiki creator could delete the wiki.

Then I integrated the Stripe Gem to process payments when charging users before upgrading their account from standard to premium. Again the Figaro Gem was used here for secure configuration of Stripe’s keys. Stripe required the creation of a Charges controller with new and create actions.

Back in the Users controller I defined the downgrade method to switch user’s accounts from premium back to standard. This also changes all the user’s private wikis to public wikis.

To create private wikis I added a checkbox on the wiki partial, used on the create and edit views, to change the :private attribute from false to true. The checkbox is only viewable by admin and premium users. I also integrated the Redcarpet Gem to parse Markdown syntax on all wikis.

Finally I created the functionality to add and remove collaborators on private wikis. I generated the Collaborator model, Collaborators controller and Collaborators views. The Collaborators table joins the Wiki and User tables via a Has Many Through relationship. I setup this relationship using Rails associations in the Wiki, User and Collaborator models.

For the Collaborator views I created a partial form to be added to the edit wiki view. I also created a partial list to be used on the wiki show view so users can see the current collaborators for each wiki. On the Collaborators controller I defined create and destroy methods to add and remove collaborates from wikis.

Results

All user needs have been successfully met.

Conclusion

Going into this project I had only built my own user authentication and authorization so I wasn’t sure how difficult integrating Devise and Pundit would be. I was pleasantly surprised with the documentation and information available on how to integrate each of these. Devise was simple to include but being my first time I had to read through the documentation carefully to understand all the moving parts and how to customize some views. Pundit wasn’t too difficult either although it did take me a bit longer to research and understand how to setup the policies.

One of my favorite parts about this project was integrating Stripe for payment processing. I am intrigued with accessing third party API’s to utilize various features or information and was happy to get more experience with API’s. And of course getting to see my Stripe account balance increase with each test run was exciting.

I was really surprised with how much I enjoyed creating the joins table for the collaborators functionality. It was intriguing and inspired me to take the several Treehouse courses on SQL, including Beginner SQL, Modifying Data with SQL, Querying Relational Databases and Reporting with SQL. These courses helped me to further understand the database relationships and how information is accessed.

The area I probably struggled the most was with the routes and resources. By the end and after some research I had a better understanding but still plan to take the Treehouse course on Rails Routes and Resources since this is a crucial part of setup.

I wasn’t sure what to do with the design until I was implementing Faker Gem with data to seed the database, the coffee data feed was inspiration for the entire app which was fun to bring to life.

This was the project I fell in love with Ruby on Rails!

View Project

Front End Dev. Love clean, intuitive UI. Meetup Organizer. Sporadic Blogger. www.KaseyMarkham.com