Art Marketplace Sinatra App

I’ve just completed my second project working through Flatiron Schools Software Engineering program. The goal of this project was to create a fully functioning web app using Ruby, Active Record, and Sinatra. A user needed to be able to create, read, update, and delete content on the site.

I decided to create an art marketplace where art “sellers” could create posts of art they would want to put up for sale on the site. Then art “buyers” would also be able to browse the site and add pieces of art to their cart that they’re interested in buying.

Building An App For Multiple Types Of Users

I started off by just creating a “seller” user for my app since they would be the ones who would be creating, editing, and deleting content from the site. Building out the necessary MVCs with Sinatra for this functionality wasn’t too time consuming so I decided to go for building out the “buyer” user as well. Now the buyer wouldn’t be creating, editing, or deleting anything. But having a buyer seemed like a natural element for a marketplace app that would round the site out nicely.

Buyers Get Their Own MVC

I decided to build out a completely separate MVC for the buyer user. While this was maybe not the most efficient way to achieve my desired outcome, it does work as long as you don’t need any user crossover(for instance the fact that theoretically a “seller” could also be a “buyer”).

I had to figure out how to integrate the two separate users so they would work together on the app. I already had helper methods current_user and is_logged_in? to help me easily keep track of a user throughout my app. I expanded these to now differentiate users.

This allowed me to easily keep track of different users that had different capabilities through the app. For instance only sellers can create, edit, or delete posts. Buyers can only view the post, and add it to their cart.

Allowing Different User Capabilities

I had to include the helper methods I mentioned above, along with a couple others a wrote specifically for my art_posts_controller, throughout the art_posts_controller in order for the different users to interact with the same app in different ways.

Taking a look at my route for a new post form you can see how I used these different helper methods to make sure the correct user had access.

Only if a seller is logged in will they be able to get to the new form. If a buyer is currently logged in the redirect_if_not_authorized method will run because buyers are not allowed to create new posts.

Similarly on the art_post show page buyers and sellers see differentiated button options.

If a seller is logged in and they own the post then they are shown buttons that allow them to edit and/or delete that post. If a buyer is logged in then they only have a button for adding to cart.

Handling Every Possibility

A big take away for me was all the detail that goes into making sure a web app runs in exactly the way it should. Once I added in a second user model I had to be really careful and set things up in a very specific way to make sure that each user functioned within the app in the appropriate way. Adding this functionality within a Sinatra app was simple in its construction, but required a ton of vigilance at every turn.