After having to make an API manually in Phase 2, my knowledge of backend was that it was tedious and required manual data entry. Certainly not what I was looking to do. I knew there had to be a way to dynamically create, update and delete APIs. There just had to be…
Enter Ruby, Active Record, and Sinatra!
Ruby, which is known for being incredibly coder friendly, is the language that we use to navigate the backend. Active Record and Sinatra are libraries/frameworks on Ruby that allow coders to easily create tables, migrate seed data, and navigate the data across several tables. My partner Freddy and I used this to great effect in our app.
Freddy and I are both avid indoor climbers. Most rock climbing gyms have route setters who periodically change the routes on the wall. The routes will have different grips and difficulty levels, offering diversity for climbers of all types. Usually, this diversity means that there are routes for all, but the route setter will make changes based on what they feel is appropriate. There is not an open communication channel between climbers and route setters which can often be frustrating. As a result, there will be times when a climber will go to the gym to find that a route that they really like has been changed, often without warning, and that the kinds of routes they usually like are no longer at the gym. Opening up the lines of communication can give the route setter information on what people like and do not like, and give climbers information about the routes, the holds used, and of surprising importance when the route will be ended. Enter BO(u)LDERBETA.
The back end allows for this data to be exchanged freely thanks to the structure we set up, and React was used to create the front end to interact with that data.
Our two main tables were Problem and Climbproblem. Problem which is controlled to only have input from the Route Setter, which in this instance has their own table called Maker (climbing nomenclature and Active Record/Sinatra keywords have a lot of overlap which lead to a lot of challenges so even though we would have liked to call it RouteSetter, it was highly problematic), has direct control over the Problem table, with the ability to POST new routes, PATCH (edit/update) previous routes, and DELETE previous routes, while also being able to READ all the routes as well as information from Climbproblem, specifically if a user indicated that the route was their favorite, are they still climbing it, have they completed it, and how do they rate it.
Climbproblem is a table that the Climber has access to, which through the association with Problems, can read all the problems and give feedback. Climbers can get information about where routes are in the gym, the difficulty, the holds that are highlighted in the route, and when they will be changed. This is how the climber sees the information from the front end as well as how they can give feedback.
As was said before, this was all thanks to the associations that were set up between our tables.
These tables have the ability to interact with each other. Pairing this with controllers that control how the data can be created, read, updated, and deleted gave us our backend.
This code in our problems_controller is a great example of that control. The first method pulls specific data from the Problem table, as well as review data that is specific to each climb from the Climbproblem table. The second method allows the route setter to update previously existing Problems.
This is also a method that allows for the route setter to delete routes they have already made and it is tied into the front end through the 🗑 icon in the front end.
Our approach to Updating the problems was unique. We had already coded the form above to create new routes. We did not want to have to create a new UI to update any routes. Our solution was to have the form fields populate with route data upon clicking the 🖊 icon, setting up logic to turn that submit button from being able to just create a new problem to update/patching a previous one.
A simple solution to update/patch!
The controllers and methods allow for all this data to be shown on the frontend that will dynamically change based on how the user rates the route.
Any clicks of the icons for Favorite/In progress/Completed will dynamically be reflected in what the route setter sees, as those clicks will update/patch the data on the backend for that specific route.
Thanks to the ability to Create, Read, Update, and Delete through careful coding with Ruby/Active Record/Sinatra, after tying it to the front end through our React App, we were able to create an app that will give climbers and route setters the ability to communicate better. Climbers can give information about what they really like, and route setters can use that info to set better routes.
