As this was my final project as a Thinkful student, I really wanted to shoot for the moon on this one. I challenged myself to pick up several frameworks and libraries outside the curriculum and broaden my knowledge as much as possible.

I decided early that I would try out GraphQL and that turned out to be an amazing adventure of highs and lows! The server side implementation was unexpectedly easy; the challenges really came on the client side. I was drawn to Apollo Client and I tried hard to make it work, but ultimately decided that this project wasn’t a good fit. I learned a ton about Redux trying to make it play along with Apollo, and I experienced some of the pains of dealing with emerging technology (at one point discovering the source of a problem in a change that wasn’t documented outside of the changelog). In the end it made more sense for me to use Lokka in my Redux actions, but I was grateful for the experience.

I also had quite the journey troubleshooting a Passport problem (which turned out to be, as it so often is, a simple mistake in what looked like solid code). It was at this point that I learned about using Chrome DevTools to debug Node. I was stepping through the Express and Passport source line by line trying to discover the problem. I got to see how Express middleware layers work in practice - quite an educational experience!

To push myself even further, I deployed this project using Docker, and not only that, but building and deploying the Docker image through Travis CI. Getting that to work was so satisfying!

My first Angular project. I originally built this app using jQuery but the complexity of the code quickly multiplied and made it difficult to debug and reason about. I wanted to learn Angular and this project stuck out as a great candidate for a port.

I quickly taught myself Angular and the basics of Typescript, ngrx, and reactive forms. Ngrx was easy to learn given how similar it is to Redux. My biggest struggles were learning how to use ngx-bootstrap and how to manage state and events through its modals. They don't show up in Augury so debugging them is a pain point, but manageable.

While porting this app I also took the opportunity to clean up the back end. I switched the testing framework from Mocha to Jest, which I really like! I also refactored the code into an MVC pattern and used async/await for clarity in the code. Comparing this to my older code makes me feel great about how much I've grown as a developer!

NOTE: To see the original jQuery version of this app, see here.

Originally my goal for this project was to learn Flask, but in order to learn Flask I had to learn several other technologies as well, making this project an enormous learning experience.

In order to get Flask running in Docker, I had to learn how to use Docker-Compose, which I will be using in every project from now on. I also had to figure out how to get Travis CI to work with a multilingual repository (Python on the back end, React Javascript on the front end), and also how to deploy them separately. I also had to learn how to run tests in Python (ultimately I settled for pytest) as part of the CI/CD process in Travis.

I also got more experience with relational databases, using Postgresql with Sqlalchemy. I had to learn how to do many-to-many relationships in tables rather than the NoSQL ways I was used to. I also had to update the database on a fixed interval; I experimented with Celery and RabbitMQ for this, but ultimately I used an AWS Lambda to call an endpoint to get around the problem of Heroku sleeping dynos.

Finally, I implemented JSON Web Tokens for authentication rather than the session cookie approach I had always used previously. On the client side, I tried out Styled Components and found them to be a really great solution that declutters the project structure; deleting all those CSS files was really satisfying!

My first React/Redux project. I never expected React to be so much fun! The major challenge on this project was struggling with the Steam API. It is a poor quality API: it is highly fragmented, outdated, and inadequately documented. It has multiple endpoints using different formats with no consistent return pattern. Although I think this project was successful in the end, I had to scrap many plans to make the scoring more complex and interesting due to limitations of the API.

Since the Steam API does not support CORS, I had to create a backend proxy. Since I love to write APIs so much, I was grateful for the chance to do so. Originally I built a Node/Express server to handle the job, but later took this as an opportunity to learn Google Cloud Functions and converted my endpoints over.

On the front end, dealing with the Steam APIs rate limit meant that I had to throttle my network calls. I used lodash debounce to implement a custom type-ahead feature that tells you when you have a valid Steam ID as you type.

My struggles with the Steam API certainly inspired me to write better APIs myself. It was a major factor in pushing me to try out GraphQL on my next project.

Contributing to this open source project has been an invaluable experience for me as a developer. Habitica is a product I use every day, and discovering that it was not only a Node/Express app but also open source was a welcome surprise. Through my contributions I have been able to get experience working with other developers and learning a large codebase written by others.

I decided to start small and help in a place where I could only do limited harm but definite and measurable good - beefing up the testing suite. I looked at the coverage reports and Github Issues and noticed that there were gaps in the test coverage for the API. Over time I developed three PRs that closed those gaps: #8771, #8809, and #8810. Getting these merged in and knowing that code of mine is helping this app that so many people use and love is such a great feeling!

Most recently I have begun working on actual customer-facing elements of the site. Habitica recently converted its front end to Vue, and I've been learning a lot about Vue while digging through that code. Recently I submitted a PR to optimize a component by cutting down on an unnecessary API call for data which was already available in the store.