When Frank Smith III built Jukebox Pro, the useful part of the project was not just storing playlist data. The application needed a backend structure that could separate public behavior from authenticated user actions and keep the playlist workflow predictable.
Jukebox Pro is an Express and Postgres playlist API. The verified project stack includes Node.js, Express, PostgreSQL, JSON Web Token authentication, bcrypt password hashing, protected playlist routes, seed data, and Vitest/Supertest coverage.
The problem
A playlist API looks simple until the application needs account-based behavior. Users need to register, log in, and access routes that should not be available without a valid session token. That changes the shape of the backend. The project needs clear route boundaries, predictable error handling, and a database model that supports repeatable local development.
Authentication workflow
The authentication flow uses registration and login endpoints. Passwords are hashed with bcrypt before storage, and successful login returns a JWT that the client can use when calling protected routes.
That structure keeps the important responsibilities separated:
- Express handles route behavior.
- Postgres stores application data.
- bcrypt handles password hashing.
- JWT authentication controls access to protected playlist actions.
- Tests help confirm that the API behaves correctly as routes evolve.
Why protected routes matter
Protected routes are where a small API starts to feel like a real application. Instead of every endpoint being open, Jukebox Pro can distinguish between general API behavior and actions that belong to an authenticated user.
For Frank Smith III, that was the point of the build: practice the backend decisions that make full-stack applications more reliable. A useful API is not only about returning data. It also has to enforce boundaries consistently.
Seed data and testing
Seed data makes the development environment easier to reason about. Instead of manually recreating records every time, the project can start from known data and make route behavior easier to test.
Vitest and Supertest coverage also matter because authentication bugs are easy to miss manually. A route can appear to work in the browser or API client while still failing edge cases around missing tokens, bad credentials, or protected behavior.
Lessons from the project
Jukebox Pro reinforced a few practical backend lessons:
- Keep authentication logic clear and isolated.
- Make protected routes explicit.
- Use seed data to make local development repeatable.
- Test user flows that affect access control.
- Prefer boring, readable API structure over clever abstractions.
This kind of project fits Frank's broader work as a full-stack developer and Field Operations Specialist in water treatment. Both environments reward clear process, reliability, and predictable systems.
Read the full official project note here: https://franksmithlll.com/jukebox-pro-api-authentication-frank-smith-iii
Project portfolio: https://franksmithlll.com/projects
Top comments (0)