Pokemon Team Builder · API

Context

The team builder needed user accounts, team persistence and a reliable Pokémon catalogue. That made the backend the core of the project: authentication, the data model, and a data source that didn't depend on third parties on every request.

Architecture

A REST API with Spring Boot 4 on PostgreSQL 17. Spring Security with JWT for the session and refresh tokens stored in the database so they can be revoked. Transactional emails over SMTP for account verification and recovery.

The Pokémon catalogue is synchronised from the PokéAPI into the API's own tables, so the application's queries never leave the server. An admin panel manages users and re-runs the synchronisation.

Decisions

Persisting refresh tokens instead of keeping them stateless costs one extra query per renewal, but it makes remote sign-out possible. Per-IP rate limiting on the authentication endpoints stops brute force without penalising the rest of the API.

What I'd do differently

I'd study the shape of the PokéAPI's data more carefully before designing the schema. The schema I had in mind was too different from how the data was actually served.

And I'd write the tests before deploying. They arrived once the API had already been in production for a while and I realised I needed them.