video1.0<iframe src="https://www.loom.com/embed/a38330e102fc45ac91246d0631e3a378" frameborder="0" width="1280" height="960" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>9601280Loomhttps://www.loom.com9601280https://cdn.loom.com/sessions/thumbnails/a38330e102fc45ac91246d0631e3a378-c60bd0668798397d.gif217.862A modern, secure, and scalable task management application built with an Nx monorepo. This project features a robust Angular frontend styled with Tailwind CSS v4 and a NestJS backend API using TypeORM and SQLite/Postgres. Hi, this is my Secure Task Management application. - It’s implemented as an Nx monorepo with an Angular 19 dashboard and a NestJS API. - The primary focus is secure JWT authentication, hierarchical RBAC, and strict organization scoping for multi-tenant isolation. - I’ll start with a quick UI walkthrough, then cover the authentication and authorization flow, followed by the architecture and key trade-offs. - After logging in, authentication is handled by Supabase, which issues a JWT that is attached to all API requests. - The user lands on the project board where tasks can be created, updated, moved between columns using Angular CDK drag-and-drop, and deleted if the user’s role permits. - Task visibility is scoped to the user’s organization, so users only see data they’re authorized to access. - The analytics section provides a simple completion bar chart, and there’s support for dark mode and keyboard shortcuts for faster task actions. - In the audit log, every create, update, and delete operation is recorded with the user, action, resource, and timestamp. Looking at the network tab, each request includes an Authorization header with a Bearer token. - On the backend, NestJS uses a Passport-JWT strategy to validate the token against the Supabase secret. - The token’s subject is mapped to the internal user entity and attached to the request context, which allows guards and services to enforce access control consistently. - RBAC is implemented using a custom `@Roles()` decorator and a `RolesGuard`. - The role hierarchy is Owner, Admin, and Viewer, with inheritance handled in the guard. - Route handlers declare the required roles, and access is denied if the user does not meet the minimum role. - In addition to route-level protection, organization scoping is enforced at the query layer. - Users only receive tasks belonging to their organization, while admins in a parent organization can view data from child organizations but not from unrelated tenants. - This ensures proper multi-tenant isolation. - From an architectural perspective, Nx is used to enforce clear boundaries and shared contracts. - Shared DTOs live in `libs/data`, which provides type safety across the frontend and backend. - RBAC decorators and guards live in `libs/auth`, making them reusable, testable, and decoupled from feature modules. -Audit logging is implemented in the service layer so that every state-changing operation automatically records an audit entry without duplicating logic in controllers. -In terms of trade-offs, I used short-lived access tokens without refresh tokens due to time constraints. -RBAC checks are performed on every request, so there is no caching layer yet. -Authorization is implemented at the resource level rather than the field level to keep the model simple and correct. -Future improvements would include Redis-based RBAC caching, Postgres row-level security to push authorization closer to the data layer, refresh token rotation for stronger session security, and WebSocket support for real-time board updates. -Overall, this implementation prioritizes secure defaults, clear RBAC boundaries, and a scalable Nx architecture with shared types and reusable authorization logic. Thank you.