PokéTeam
About the project
This project combines a love for competitive Pokémon with a love for team building. The goal of this project is to let users search for Pokémon by name to build their ideal teams! Each team would be evaluated, and users would receive stats and information about it.
Introduction
My database class included a final group project. This project required us to create a database and perform different operations on different tables. Each project also had to implement distinct aggregate operations relevant to its purpose.
Since each team consisted of three people, I took the initiative and began to search for free APIs online to use as a baseline. After some discussion, we settled on the Pokémon API because we all had a love for the game and appreciated the information that the API provides.
I took the lead as the project architect and code reviewer. I assigned roles to each member and ensured that each pull request followed the conventions I had established.
Technologies used
Since this project was for our database class, it was natural that we had to use T-SQL. However, the professor gave the class complete freedom over the rest of the implementation and the structure of the project. Since I had experience with other projects, I was chosen to lead the selection of the tech stack.
Frontend
The frontend was kept very simple since the main focus was on the backend implementation. The project used HTML to structure the frontend, while JavaScript handled operation calls when buttons were clicked. We used Tailwind CSS to create the clean Pokémon-like design we wanted.
Backend
The backend had some stricter requirements due to the database being the center of the project. We used T-SQL for database operations, and the database was hosted on K-State’s services. Since I had previous experience with Flask, we chose this web framework to handle communication between the frontend and the database.
Design
Since there was a lot of freedom in this project, I decided to explore different designs for communication from a database to the frontend. After some research, I decided to use the repository pattern. This pattern allowed clear separation of the layers of logic. We used data transfer objects (DTOs) to transfer data between these layers. These were Python objects that contained information retrieved from the database when the DTOs were created.
However, if the frontend accessed these objects directly, it would defeat the purpose of layer separation. This is solved by having the Flask routes call a repository class instead. The repository class handles the T-SQL code and the creation of the object itself. The Flask route is able to call different methods in the repository class based on the user’s operation. The image below shows the communication between classes when a user creates a team.
Issues encountered
Originally, this project was intended to be a complete Pokédex where information about Pokémon, their moves, and other details would be available to users. However, due to time constraints and the demands of other courses, we decided to simplify the project. Users would be able to choose a Pokémon’s nature, level, and modifier and add the Pokémon to a team.
Outcomes
Despite a small setback in the original implementation, I would still consider it a great success! The project worked as intended! All the requirements were met, and the live demo presentation went smoothly!
Future additions
Given its original purpose as an assignment, I would say that this project is finished. If I were to continue, I would love to add more options for customizing a Pokémon. I think this would add complexity to how customization data is passed through the codebase and tied to the existing schema.