PokeTeams - Sinatra web app project

Let me start by saying man, what a stressful process. This is the end of phase 2 at the Flatiron Schools SE bootcamp and I couldn't be more excited to say I am finally finished with this project. For our final project, we had to create a web based app using CRUD and MVC in Sinatra. Sticking to the Pokemon theme to build more off my previous CLI app using the Pokeapi, I create a website (PokeTeams) that allows the user to create multiple teams which contain Pokemon that can be added or removed as well as having a Pokedex to see the list of all Pokemon and their corresponding information (abilities, moves and types). How useful is this app? Well of course it is catered towards online competitive players though truthfully, I did this to expand on my previous project and wanted to incorporate the same API to see how else I could use it.

I came into the project thinking maybe I could reuse my code from the previous project in order to give myself a head start and allow time to delve further into features I could create for the website however, that was not the case. Similar to my previous project, I ran into the issue of trying to extract usable data from nested urls, each containing a different piece of data.

def fetch_pokemon
    url = "https://pokeapi.co/api/v2/pokemon?limit=10000"
    response = HTTParty.get(url)
    new_response = response.parsed_response
    fetch_abilities(response["results"])
end

def fetch_abilities(results)
    results.each do |x|
        Pokemon.create(name: x["name"], url: x["url"])
    end
end

After some tweaking to previous code used to gather this information, I had finally been able to incorporate it into the project. The next issue was setting up my tables. Relations between tables became an issue as I had been able to get them to align, but not completely.

class User < ActiveRecord::Base
    has_secure_password
    has_many :teams
end

class Team < ActiveRecord::Base
    belongs_to :user
    has_many :team_pokemon
    has_many :pokemons, through: :team_pokemon

end

class TeamPokemon < ActiveRecord::Base
    belongs_to :team
    belongs_to :pokemon
end

class Pokemon < ActiveRecord::Base
    has_many :team_pokemon
    has_many :teams, through: :team_pokemon
end

In the above models, you can see the relations between the user, team, and Pokemon, but wait, whats the TeamPokemon? When creating tables, I ran into the issue of how to join together the teams and Pokemon, and this is the solution. Previously without this, Each team would be able to only have one Pokemon assigned and of course thats no good. With this each Pokemon could be assigned to multiple teams and each team could be assigned multiple Pokemon. Understanding relations in the case of my project was difficult as there were three tables which each had to be connected. Once the tables had come to a working state, the process of completing the app slowly became easier and easier. With this completed, I finally had the backbone to my project complete, being the data and ability for users to register teams and Pokemon to their session. Sessions is the other aspect to this project. All data referring to a specific user had to be connected to their current session to prevent others from gaining access to their data. This required linking each team to the session id of the current user.

user = User.find_by(email: params["user"]["email"])

if user && user.authenticate(params["user"]["password"])
    session["user_id"] = user.id
    redirect "/teams"
else
    redirect "/login"
end

By setting up sessions, each users data becomes more secure as user created data cannot be edited by others. In my case, protecting generic data for each user (the index of Pokemon and their individual information) from being edited was a simple case as there just wasn't a way for the user to access that ability as it was never created or intended as they each have set in stone data.

Throughout the project, compared to my CLI project, it has been nice to see faster speeds when updating information specifically while using this API. By using the same API, I noticed performance has drastically improved through the use of the shotgun gems real time updates in comparison to rerunning the CLI every time I make a change. This increased both productivity and reduced stress as an extra benefit. When booting the CLI, it could take up to two minutes for the information from the API to finished collecting. It has definitely shown me the pokeapi is more suited to a web-based application over that of a CLI.

Though I hope to revisit this project in the future to edit the styling of the webpage (as I left it fairly simple), I am glad to say goodbye to it for now.