Overview
Trevecca-pedia is an internal wiki platform built as a service-based system. Users can register and log in, browse and search content pages, and manage wiki entries. The project was designed to be easy to demo, easy to extend, and structured so each service has a single clear responsibility.
The project matters because it demonstrates the kind of backend thinking that doesn't come from toy tutorials: actual service decomposition, auth token flows across service boundaries, and a containerized setup that a teammate can clone and run without configuration drama.
Problem
Need an internal, searchable knowledge base with reliable auth and a clean web UI.
Solution
Three services, each doing one job: web UI, wiki content, and authentication.
My Role
Owned the authentication service end-to-end: design, implementation, and integration.
Tech Stack
What I Built
- Designed and implemented the full authentication service in Go: register, login, logout, and token refresh endpoints.
- Implemented JWT issuance with configurable expiry and secret key management via environment variables.
- Built middleware for protected route validation: the web and wiki services forward the token; auth service verifies and responds with user claims.
- Hashed passwords with bcrypt before storage; never stored plaintext credentials.
- Wrote the PostgreSQL schema for the users table, including indexes on email for fast lookups.
- Coordinated API contracts with the teammates building the wiki and web services so inter-service calls had agreed-upon request/response shapes.
- Configured the auth service container in Docker Compose with correct environment injection and service dependencies.
Architecture
How the three services connect in the MVP:
Each service runs in its own Docker container. Docker Compose handles networking,
startup order, and environment variable injection. This means a new contributor
can run docker compose up and have the full system running locally in minutes.
Architecture Documentation (arc42)
The Trevecca-pedia architecture was formally documented using the arc42 template, a standardized format for software architecture documentation used in professional engineering practice. The document covers system context, the three-service building block view, runtime sequence diagrams for the auth flow, the Docker deployment view, and the rationale behind key architectural decisions.
Challenges & What I Learned
- Inter-service token validation: Getting the token to flow correctly from browser → web → wiki → auth required careful coordination. We settled on a clear header convention and documented it early.
- Docker networking: Services need to reference each other by container name, not localhost. Debugging this taught me a lot about how Docker's internal DNS works.
- JWT expiry edge cases: I learned to think about what happens when a token expires mid-session, and how the web service should handle a 401 from the auth service gracefully.
- Defining API contracts as a team: Working with teammates on request/response shapes forced me to think about how to communicate technical decisions clearly and commit to interfaces early enough that we weren't blocking each other.