Explicit authentication architecture
Registration and login are handled by the application itself. Passwords are stored as hashes, while authenticated sessions use unique server-managed tokens with expiration.
Back to portfolio
Case Study
Atlas
Production-oriented Full Stack Next.js Application
A full-stack Next.js application demonstrating authentication, database architecture, validation, rate limiting, automated testing and production deployment.
Next.jsReactTypeScriptPrismaPostgreSQLZodReact Hook FormVitestLinuxPM2
The Problem
What this project demonstrates
Atlas focuses on the parts of a full-stack application that are often skipped in small demos: authentication, persistent sessions, validation, database modelling, rate limiting, testing, CI and deployment to a real production server.
Architecture
System architecture
01
Next.js App RouterServer-side application layer
Routes and server actions handle application requests.
02
Zod validationApplication services
Input is validated before business logic executes.
03
Application servicesPrisma ORM
Business logic accesses typed persistence operations.
04
Prisma ORMPostgreSQL
Users, sessions and application data are stored in PostgreSQL.
Atlas uses Next.js as the application boundary, Prisma as the data-access layer and PostgreSQL for persistence. Authentication is implemented explicitly with password hashing and database-backed sessions rather than delegated to a third-party authentication provider.
Engineering Decisions
Key decisions
Database-backed sessions
Sessions are first-class database records linked to users. They can expire independently, be indexed for cleanup and are removed automatically when a user is deleted.
Shared validation boundaries
Zod schemas define input constraints while React Hook Form provides typed client-side form handling. Server-side logic still validates input before performing mutations.
Authentication rate limiting
Sensitive authentication actions are protected from repeated attempts, with limiter state cleared after successful authentication where appropriate.
Production deployment
The application is deployed to Linux with PostgreSQL and managed using PM2, demonstrating deployment and operational concerns beyond local development.
Performance
Performance approach
Server-first architecture
Next.js App Router keeps server-side responsibilities close to the data layer and avoids unnecessary client-side API orchestration.
Focused client components
Interactive behavior such as forms and charts is isolated to client components instead of converting the entire application into a client-rendered SPA.
Database-aware design
Session expiration is indexed in the database and relational cleanup uses cascading deletes where appropriate.
Testing
Testing strategy
Vitest
Unit coverage for authentication actions, validation and rate-limiting behavior.
React Testing Library
Form and interactive component behavior can be verified independently from backend infrastructure.
GitHub Actions
Automated CI validates installation, linting, tests and production builds.
Product
Application screens
Trade-offs
Challenges & trade-offs
- 01Custom authentication provides full visibility into session behavior but carries more implementation and maintenance responsibility than a managed authentication provider.
- 02PM2 on a Linux server is intentionally simpler than container orchestration and is appropriate for the scale and goals of this demonstration.
- 03Atlas demonstrates production-oriented architecture rather than attempting to implement every feature expected from a complete commercial product.