Engineering Case Study
A full-stack coffee menu management application built with Next.js, focused on role-based access control, server-side data operations, and a clear separation between public menu consumption and administrative management.
Key architectural and technical decisions made during the development of the project.
Authentication is handled through Supabase Auth, while administrative access is determined separately through the user's role stored in the database. This keeps user identity and application permissions as distinct concerns.
Menu creation, updates, and deletion are implemented with Next.js Server Actions instead of separate API endpoints for each CRUD operation. This keeps internal menu mutations close to the server-side application logic without introducing unnecessary API endpoints.
Administrative permissions are verified on the server before menu mutations are executed. The application does not rely solely on hiding dashboard functionality in the client, keeping authorization independent from the UI.
Authentication uses a dedicated API route because it has its own request and session lifecycle, while internal menu management remains implemented through Server Actions. This keeps the communication pattern appropriate to each responsibility.
The public interface focuses on consuming and presenting menu data, while authenticated administrative workflows handle menu mutations. Separating these responsibilities keeps the public experience independent from management operations.
Real implementation challenges and the approaches used to solve them.
The application exposes a public coffee menu alongside administrative functionality for creating, updating, and deleting menu items. Authenticated users without the required role should not be able to perform these operations.
Authorization is enforced inside the server-side mutation flow. Before a Server Action performs a database mutation, the authenticated user's role is verified, preventing unauthorized users from modifying menu data.
Hiding administrative UI elements does not prevent a user from attempting to invoke protected operations directly. Client-side visibility therefore cannot be treated as the actual security boundary.
Authorization checks are performed on the server before administrative operations access the database. The client controls the user experience, while the server remains responsible for enforcing access rules.
The application required server-side authentication as well as internal menu management mutations. Using API routes for every operation would create endpoints that are only consumed by the same Next.js application.
API routes are limited to the authentication flow, while menu CRUD operations use Server Actions. This keeps the architecture smaller and matches the communication mechanism to the responsibility of each feature.
The public menu and administrative dashboard work with the same underlying menu data but have fundamentally different responsibilities. Mixing their data flows could make access control and maintenance harder to reason about.
Public menu consumption and administrative mutations are separated at the application level. Public users consume menu data through the storefront, while protected Server Actions handle management operations after authorization checks.