For a previous Pokédex project as an exercise to practice React Redux, I used the public REST PokéAPI. However, which the sheer amount of data and quantity of endpoints, my queries were slow because I had to "endpoint hop" to get all of the data I wanted. So I created a GraphQL wrapper around the REST API using Apollo Server. This was great! It really cleaned up my queries since I could just make a single GraphQL request and it would take care of the endpoint mess for me. This greatly sped up my query times, but they were still slower than I wanted. So I took things up a notch, cloned my own SQLite3 PokéAPI database from their GitHub repo, and made a GraphQL API from scratch. It's still incomplete and untested, but it's way faster than either the REST API or the GraphQL wrapper since it's making direct requests to the database.

After having cloned the SQLite3 database from PokéAPI, I used SQLite Studio to study the different tables and columns so that I could figure out what data was available to work with. Then, I used Apollo Server to build the GraphQL server! First, I started with creating the schema. I thought that this would be the best place to start because I already had ideas of what data I wanted for my frontend application. Knowing what data I needed helped me to create a schema that could meet those needs. Then after creating the schema, I created the SQL datasource. Using knex to make the SQL queries, I was able to make helper functions to access the data and then utilize them inside of my resolvers.

The most challenging part has been how time consuming and tedious it was to write all of the knex queries. Since I had previously made a GraphQL API with Apollo Server, I didn't have to worry about learning a lot of new things. But since there was a lot of data to sift through, it took a long time to figure out which tables had the data I needed.

Another inconvenience I encountered was as the schema grew, it became harder to remember what all of the fields and types were. To help with this, I created a documentation site that describes all of the fields and has a GraphQL playground so that I wouldn't have to go digging through the codebase every time. Writing docs for the API proved to be more helpful than I anticipated. Not only did it make it easier for me to write queries, but in writing the docs I found some bugs that I didn't know existed! Moral of the story: always document your code.

As I'm currently focusing on more features and bug fixes on the frontend application, the server has kind of been put on hold. However, I do have plans for what I want to work on next:

• Fix a couple of bugs I found when writing the docs
• Add testing! I wasn't originally going to since I was going to be the only person using it. But after giving it some thought, I think it would be great practice to improve my testing skills.
• Modularize the schema and resolvers instead of having a big monolith so that everything is more organized