DEV Community: Nader Fkih Hassen

Day 25 – Making Search and Filter Work Like Magic

Nader Fkih Hassen — Fri, 11 Jul 2025 20:24:33 +0000

One of the most important things I’ve learned during my internship is that user experience is built in the details.

Today’s challenge? Search and filtering for legal cases inside Lura.

Lawyers work with hundreds of cases. Scrolling manually isn’t practical. They need fast, flexible ways to find what they’re looking for. Our job as developers is to create features that feel simple — even if they're not.

🧠 Why It Matters
In Lura, every case is tied to a workspace, and every document to a case. As the data grows, finding specific content becomes harder. Lawyers need:

Search by title (e.g., “Doe vs Smith”)
Tag-based filtering (e.g., “Criminal”, “Pending”)
Workspace-scoped results (can’t show data across teams)

Without this, the app feels clunky. With it, it becomes a tool that actually helps users think and act faster.

⚙️ How I Built It
📦 Backend: NestJS + Prisma
I built a GET endpoint like /cases?search=...&tag=...&workspace=...
In the controller, I used Prisma to dynamically filter based on query params:

ts
const cases = await prisma.case.findMany({
  where: {
    title: { contains: search },
    workspaceId,
    tags: { some: { name: tag } },
  },
  include: { tags: true }
});

This made the filtering flexible and efficient. Prisma made chaining filters feel natural.

💻 Frontend: Next.js + TailwindCSS
I added:

A search bar with debounced input (to avoid spamming the backend)
A tag selector dropdown
A workspace switcher that resets filters when you move teams

Each interaction triggers a router query update, which then fetches the correct results.

tsx
router.push({
  pathname: '/cases',
  query: { search, tag, workspace }
});

Then I used useEffect to trigger fetching on query change. Everything updates without a full reload — just like a proper SPA should.

✨ The Result
Users can now:

Type to instantly filter by title
Click tags to narrow down results
Switch workspaces with isolated results

It feels fast. It feels modern. And more importantly: it helps the user get to work faster.

✅ Takeaways

Filtering is UX power — it saves time and makes apps feel smarter.
Prisma’s flexible querying makes dynamic filters easier than expected.
State and URL sync in Next.js is a must-have for clean navigation.

❓Question for You
What’s your go-to strategy for building smart filtering systems?
Do you prefer using server-side filters, or handle them on the client?

Day 24 – Experiencing Real Teamwork in Software Development

Nader Fkih Hassen — Thu, 10 Jul 2025 15:48:12 +0000

During my time as a computer science student, we always worked on group projects — but let’s be honest: it’s usually just one or two people doing most of the work. Real teamwork? I thought I understood it.

Then I started my internship and worked on Lura, our full-stack lawyer management system — and suddenly, I saw what it actually means to be part of a real software development team.

💼 It’s Not About Just “Working Together”
I used to think teamwork meant:

“Just be nice and don’t step on toes.”

But what I learned is that real teams communicate, disagree constructively, and plan constantly. We had proper daily standups, backlog grooming, sprint planning, and retrospectives. Not to mention reviewing PRs with real feedback — not just a 👍.

🛠️ What I Did This Week

Took part in resolving merge conflicts in GitHub (finally learned not to fear them 😅).
Wrote detailed commit messages that actually made sense to others.
Helped fix bugs introduced by features I didn't even write.
Reviewed code, left comments, and asked clarifying questions when I didn’t understand something.

These might seem small, but it’s what teamwork really looks like — understanding the whole app, not just your part of it.

🤯 Realizations That Changed the Way I Work

Communication is Everything The more I talked, the better we worked. Silent struggle helps no one.
Accountability Matters When a feature breaks, it’s not about blame — it’s about solving it together.
No One Writes Perfect Code Even the best devs need feedback and edits. The magic is in collaboration.
Structure Helps, Not Hinders I used to roll my eyes at GitHub issues and structured planning. But now? I can’t imagine working without them.

👨‍💻 Takeaway
Working in a real development team showed me how important process, patience, and people are. It’s not just about tech stacks — it’s about trust and timing. I’m grateful to my teammates and mentors who gave me the space to grow, ask questions, and even mess up (sometimes).

I came into this internship wanting to become a better developer.
I’m leaving it with a better understanding of what it means to be teammate.

❓Your Turn
What was the biggest surprise for you when you started working with a dev team for the first time?
Let me know — I’d love to learn from your experience too!

Day 23: My First Real Developer Experience

Nader Fkih Hassen — Wed, 09 Jul 2025 15:07:22 +0000

I used to think that knowing how to code meant I was ready to work in a company. I had built some personal projects, passed some online courses, and contributed to group assignments at university.

But after spending a few weeks at my internship with StartupFACTORY, I realized there’s a whole different level to being a real developer.

👥 What Changed?
It wasn’t the frameworks or tools. I already knew some JavaScript, had played with React, and learned NestJS during the early weeks of training.

What changed was the environment.

Suddenly, I was:

Writing code that would be reviewed by someone else
Explaining my decisions in a pull request
Responding to constructive feedback
Breaking something in one workspace and realizing it affected five others
Writing TODOs not for myself, but for my teammates

This wasn’t a tutorial — this was a real product, being built for real users. That pressure changes everything.

🛠️ Tools, But with Purpose
Using GitHub felt different now:

Each branch had a ticket and a purpose
Every commit message mattered
Merge conflicts had real consequences

Using Scrum wasn’t just a school concept:

We had sprint goals
We had reviews and retrospectives
We adjusted based on blockers, not guesses

Even writing a button component became an act of collaboration.

💬 What I Learned

💡 Code that works isn’t always code that fits — consistency and readability matter.
🤝 Asking for help is a strength, not a weakness. The team culture encourages open communication.
🧭 Following structure (Scrum, planning, backlog) brings clarity — and reduces chaos.
🧱 Real development is about sustainability, not just building fast.

🔁 Reflection
What was the first moment you felt like a “real” dev — not just someone writing code?

For me, it was when my mentor asked, “Will this scale to multiple workspaces?” — and I didn’t have an answer. That one question changed the way I built everything after.

Today wasn’t about learning a new library. It was about realizing how much I still have to learn to work like a professional. And that’s the most motivating feeling in the world.

Day 22: Building a Workspace-Centric Calendar System

Nader Fkih Hassen — Tue, 08 Jul 2025 14:05:13 +0000

🗓️ Why Calendars Matter in a Lawyer Management System
Lura, the app we’re building during my internship, is built around workspaces where legal professionals manage cases, documents, and more. One thing they all needed? A centralized, collaborative calendar.

But it’s not just about putting dates on a page — it’s about communication, accountability, and structure.

💡 Feature Goals for the Calendar:

Create and edit case-related events (meetings, court dates, deadlines)
Events should be linked to a workspace, not globally shared
Only workspace members can view and manage their calendar
Support recurring events (future enhancement)
Simple, intuitive UI

🔧 Technical Breakdown
📦 Backend (NestJS + Prisma)
Created an Event model:

ts
model Event {
  id          String   @id @default(uuid())
  title       String
  description String?
  date        DateTime
  workspaceId String
  createdBy   String
  createdAt   DateTime @default(now())
}

Added routes for:
- POST /events: Create a new event
- GET /workspaces/:id/events: List events per workspace
- PUT /events/🆔 Edit event
- DELETE /events/🆔 Delete event
Used class-validator to handle input DTOs with proper date formatting.

💻 Frontend (Next.js + FullCalendar)

Integrated FullCalendar to render a beautiful, interactive calendar.
Used React hooks and context to handle user roles and event permissions.
Built a modal form to add/edit events and hook into API routes.

tsx
const handleSubmit = async () => {
  const res = await fetch('/api/events', {
    method: 'POST',
    body: JSON.stringify({ title, date }),
    headers: { 'Content-Type': 'application/json' },
  });
  const data = await res.json();
  mutate(); // refresh event list
};

🔐 Role-Based Access

Only workspace members can view/edit calendar events.
Admins and Super Admins can delete any event.
Used middleware on the backend to validate token and role on each action.

✅ Key Takeaways

📆 Calendars look simple but hide lots of edge cases (time zones, ownership, validation).
👨‍💻 FullCalendar is a powerful library, but integrating with custom APIs takes care.
🔐 Role-based logic really adds value to team collaboration features.
🧠 Legal apps need precision and traceability — even in UI elements like calendars.

❓Question for You
How do you usually handle shared calendar systems in your apps? Do you prefer an in-app solution or integrations like Google Calendar?

Thanks for following along this journey — we’re nearing the finish line! 💪
Stay tuned for Day 23.

Day 21: Backend Security – The Last Line of Defense

Nader Fkih Hassen — Mon, 07 Jul 2025 15:49:52 +0000

"Sometimes it’s not about what you add, but what you protect."

In my internship journey, I revisited a crucial lesson that every developer (especially full-stack ones) should hold dear: never trust the frontend when it comes to security.

🔍 The Problem
In the early days of building Lura – The Lawyer Management System, we did most of our RBAC (Role-Based Access Control) checks on the frontend. Buttons were shown or hidden based on role, navigation was blocked, and unauthorized users couldn’t even see actions they shouldn’t take.

It felt secure... until I asked myself:
“What happens if someone just sends a crafted POST request directly to our backend?”

Answer: They might just bypass all our hard work.

🔒 The Solution: Backend Enforcement
So I shifted focus and began securing our NestJS backend endpoints. Here's what I did:

🧰 Backend Guards and Decorators
I created a series of custom guards and decorators in NestJS:

ts
// Example: Role Guard
@Injectable()
export class RolesGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    const user = request.user;
    const requiredRoles = this.reflector.get<string[]>('roles', context.getHandler());
    return requiredRoles.includes(user.role);
  }
}

// Used like this:
@UseGuards(RolesGuard)
@Roles('admin')

This simple logic ensures that even if someone sends a forged request, they won't pass unless the role matches.

🔁 Workspace Validation
We also have workspace-scoped actions. For that, I added:

A @WorkspaceMember() decorator
Logic to confirm the user is part of the workspace they’re acting on
AuthorizationService with reusable checks

🧪 Testing
Finally, I used Jest to write tests for key routes:

Can an admin delete a document?
Can a lawyer access a case from a different workspace? (They shouldn’t)
Can anyone else invite users to a workspace?

💡 Takeaways

Frontend is UX. Backend is law.
NestJS makes it easy to build modular, reusable security logic
Good security is invisible to the user — and obvious to the developer
I now have a deeper respect for backend checks and how they actually protect users

❓ Today’s Question
What’s your approach to securing backend logic in multi-role applications? Do you go with service-based policies, decorators, or custom guards?

I’d love to hear how others handle authorization at scale.

Thanks for reading — and see you for Day 22!

NestJS #BackendSecurity #RBAC #LearningInPublic #30DaysOfLearning #LuraApp #WebDevJourney

Day 20 – Building Notification Logic: Keeping Users in the Loop

Nader Fkih Hassen — Sun, 06 Jul 2025 11:28:45 +0000

🧭 Why Notifications Matter
Legal professionals are busy. They don’t want to log in just to check if something changed. So for Lura, our legal case platform, I began implementing a notification system to make sure users get the right information at the right time — whether it's a new document, case, or event.

It’s not about spamming them — it’s about respecting their time.

🏗️ System Goals

Notify users when:
- A new document is added to their case
- A new calendar event is assigned
- A case is created or updated
Let users view unread/read notifications
Allow notifications to be dismissible
Eventually extend to real-time push or email

🧱 Backend (NestJS + Prisma)
I added a new Notification model in our Prisma schema:

prisma
model Notification {
  id          String   @id @default(uuid())
  message     String
  userId      String
  isRead      Boolean  @default(false)
  createdAt   DateTime @default(now())
}

Every time a document or event is created, the server creates a new notification assigned to relevant users (typically by role or case ownership).

In NestJS, I created a reusable NotificationService:

ts
@Injectable()
export class NotificationService {
  constructor(private prisma: PrismaService) {}

  async notify(userId: string, message: string) {
    return this.prisma.notification.create({
      data: { userId, message },
    });
  }
}

Then I injected that into controllers like DocumentController and EventController to trigger alerts automatically.

💻 Frontend (Next.js + TailwindCSS)
On the user dashboard, I created a simple notification bell icon. When clicked, it shows a dropdown of the latest alerts.

tsx
{notifications.map(note => (
  <div key={note.id} className="bg-white shadow-sm p-2 rounded-md">
    <p className="text-sm">{note.message}</p>
    <span className="text-xs text-gray-400">{formatDate(note.createdAt)}</span>
  </div>
))}

Unread notifications are highlighted, and users can mark them as read with one click. I used a small badge icon to show the count of unread alerts.

🔐 Access Control
Only users assigned to a workspace/case receive its related notifications. The backend checks user roles before inserting or displaying alerts.

💡 What I Learned

Notifications aren’t just UI features — they’re about clarity and communication.
Timing and relevance matter more than frequency.
Prisma made it really easy to store and retrieve alert metadata.

❓Question
What’s the worst or best notification UX you’ve seen in a real product? Something that made you go, “Wow, this helped”… or “Why did they send me this?”

nestjs #nextjs #notificationsystem #uxdesign #backend #prisma #internshipexperience #30DaysOfLearning #LuraApp

Day 19 – Cleaning Up the Core: Refactoring the Database Schema

Nader Fkih Hassen — Sat, 05 Jul 2025 15:28:16 +0000

🧠 Context
After nearly three weeks of building features into Lura, our legal case management app, I realized something that many early-stage developers face: your first database schema will rarely be your best.

Today, I stepped back from building features to refactor and clarify the data relationships between the major entities in our system — Workspaces, Cases, Documents, Users, Tags, and Calendar Events.

📦 What I Did

Simplified Relationships At first, we had awkward relationships like:

Case having both workspaceId and a nested workspace reference,
Document storing redundant workspace references already tied through Case.

I cleaned this up using Prisma relations. Now, each document belongs to a case, and the case belongs to a workspace. This means fewer joins, less chance of inconsistency, and clearer logic in queries.

prisma
model Workspace {
  id        String    @id @default(uuid())
  name      String
  cases     Case[]
}

model Case {
  id           String     @id @default(uuid())
  title        String
  workspace    Workspace  @relation(fields: [workspaceId], references: [id])
  workspaceId  String
  documents    Document[]
}

model Document {
  id       String   @id @default(uuid())
  title    String
  case     Case     @relation(fields: [caseId], references: [id])
  caseId   String
}

Improved Naming Conventions
I found names like createdByUser and user_id_fk scattered through my schema. I standardized field names to things like createdById, assignedToId, and made naming consistent across all models.
Added Indexes for Performance
Since we often filter by workspaceId, caseId, or tagId, I added indexes in the Prisma schema to optimize query speeds, especially when working with large datasets.

prisma
@@index([workspaceId])
@@index([caseId])

⚠️ Lessons Learned

You don’t need to get your schema perfect on Day 1.
Design clarity = easier maintenance and faster development.
Refactoring schemas early saves hours later.
A simple, normalized structure beats clever tricks.

🔍 Bonus Debug Tip
If you're using Prisma and things stop syncing right after a schema change:

npx prisma migrate reset

Just remember to back up your seed data first!

❓Question
How often do you audit your data models? Do you prefer to design everything upfront or evolve your schema as the project grows?

Let me know your approach! Day 20 is going to be exciting — diving into user notifications and communication flows.

DatabaseRefactor #Prisma #BackendBestPractices #DevLog #FullstackLearning #SoftwareDesign #InternshipJourney #LuraApp #30DaysOfLearning

Day 18 – Building Smarter AI Chatbots with Dify and Prompt Engineering

Nader Fkih Hassen — Fri, 04 Jul 2025 18:43:35 +0000

🧠 Today’s Focus

As Lura evolves into more than just a case and document management platform, I wanted to explore how we can make it feel intelligent — like it’s working with you, not just for you. That led me to deepen my integration of Dify and Ollama, specifically around prompt engineering.

While I had Dify running earlier in the project, today was about quality — not just functionality.

🧩 What I Worked On

1.Refining Prompt Templates:

Instead of using a generic prompt like “Summarize this document,” I wrote a more tailored version:

You are a legal assistant AI inside a document platform. Always summarize in simple language, highlight important names, and suggest next steps for legal actions.

I also tested multiple prompt structures to see how results changed with small adjustments.

2.Customizing System Instructions:

Dify allows setting "system messages" that guide how the assistant behaves. I made sure the assistant stays professional, doesn’t hallucinate, and sticks to the workspace’s document context.

3.PDF Chunking and Indexing:

Learned how Dify chunks large PDF documents before embedding them.
Tuned the chunk size and overlap to improve answer relevance.

4.Testing Real User Scenarios:

Sample query: “What’s the main point of this contract?”
I uploaded an actual test contract and watched how the AI summarized it in 3 lines, perfectly highlighting the client name and conditions.

🔧 Useful Code/Setup

# My Dify docker-compose.yaml snippet
  dify:
    image: langgenius/dify
    environment:
      - MODEL_PROVIDER=ollama
      - SYSTEM_PROMPT="You are a legal assistant..."
    volumes:
      - ./data:/app/data

// Sample Prompt Template in UI
{
  "prompt": "Summarize this legal document in plain language. Highlight any deadlines or responsibilities.",
  "context": "Document file content here..."
}

💡 Takeaways

Prompt engineering is UX for AI. How you phrase things matters a lot.
Even “dumb” chatbots can become useful with thoughtful design.
Working with lawyers? Be precise. AI must never invent or exaggerate.
Keeping tone and context on-brand is just as important as accuracy.

❓Question
Have you ever tried building your own assistant — even something simple? What did you wish you knew before starting?

On to Day 19. 👨‍💻💬

AI #Ollama #ChatbotDevelopment #LegalTech #Dify #PromptEngineering #JavaScript #InternshipJourney #LuraApp #30DaysOfCode

Day 17 – Securing Files with Role-Based Permissions

Nader Fkih Hassen — Thu, 03 Jul 2025 16:06:02 +0000

📂 "Oops, I deleted the wrong file..."

That’s a nightmare in any app — but in legal software? It’s a lawsuit waiting to happen.

So on Day 17 of my internship learning journey, I focused on a vital but often overlooked problem: making sure only authorized users can delete documents.

🧱 Background
I previously built a file upload feature tied to legal cases. But until now, anyone could delete documents.

In reality, a junior lawyer shouldn’t be able to remove court evidence by mistake. So, I implemented Role-Based Access Control (RBAC) specifically for file deletion.

🔐 RBAC Rules for Document Handling
Role Upload View Delete
Lawyer ✅ ✅ ❌
Admin ✅ ✅ ✅
Super Admin ✅ ✅ ✅

These rules were enforced in both backend and frontend.

⚙️ Backend Implementation (NestJS + Prisma)
I updated the document deletion route in NestJS:

@UseGuards(AuthGuard, RolesGuard)
@Roles('ADMIN', 'SUPER_ADMIN')
@Delete('/documents/:id')
async deleteDoc(@Param('id') id: string) {
  return this.documentService.remove(id);
}

This ensures only authorized users can trigger deletion, even if they try via tools like Postman.

💻 Frontend Guards (Next.js)
In the file list UI, I used useUser() to conditionally show the delete button only to eligible roles:

{user?.role === 'ADMIN' || user?.role === 'SUPER_ADMIN' ? (
  <button onClick={() => deleteFile(file.id)}>🗑️ Delete</button>
) : null}

Even if someone inspects the page and reveals the button, the backend guard blocks them.

🧠 What I Learned

Security isn’t just about code — it’s about UI decisions, too.
People trust file systems. You only notice it when things break.
NestJS guards + frontend conditional rendering = powerful security combo

✅ Extra UX Touches

Show a confirmation modal before deletion.
Use toast notifications for success/error feedback.
Added metadata (who deleted what, and when).

❓Discussion Question
Have you ever had to roll back a user’s accidental delete?
What safeguards do you build around sensitive actions?

Let me know — and see you tomorrow for Day 18!

RBAC #LearningInPublic #SecurityByDesign #LuraApp #InternshipDevLog

Day 16 – Building Calendar Events That Actually Matter

Nader Fkih Hassen — Wed, 02 Jul 2025 15:01:18 +0000

If you told me at the start of this internship that I’d be stressing over date pickers, I would’ve laughed.

But here we are. On Day 16, I built the calendar event management system inside Lura — and it’s one of the most human features we’ve touched so far.

🗓️ Why Calendars Matter in Legal Work
Lawyers deal with time-sensitive responsibilities. One missed court date, one forgotten contract review — it’s chaos. So for Lura, we had to build a calendar system that didn’t just store events, but respected context.

We didn’t want a global calendar. We wanted event timelines scoped to cases.

⚙️ How It Works
Each event has:

Title
Description
Start/End DateTime
Related Case ID
CreatedBy & updatedBy
Visibility based on user role

On the backend, I used Prisma to define the model:

model Event {
  id          String   @id @default(uuid())
  title       String
  description String?
  startTime   DateTime
  endTime     DateTime
  caseId      String
  createdBy   String
  updatedAt   DateTime @updatedAt
}

The NestJS controller validates the input and checks role permissions — only Admins and Lawyers can create/edit, while Super Admins have global access.

@UseGuards(AuthGuard, RolesGuard)
@Roles('ADMIN', 'LAWYER')
@Post('/cases/:caseId/events')

💻 Frontend: The Form & List
I used Next.js with TailwindCSS to build a small, responsive form:

Date pickers for start/end
Character limits for titles
Real-time form validation

Events appear in a clean list under each case view. I kept it simple, but clear — readable datetime, case context, and edit/delete buttons (based on role).

🧠 Things That Surprised Me

Date logic gets tricky fast – I had to handle overlapping events and timezone issues even for internal use.
Empty states matter – If a case has no events, that should be obvious and friendly, not just blank.
People really trust their calendars – this reminded me how much power (and responsibility) we have when storing others' plans.

✅ Key Lessons

Always connect calendar features to the real world — lawyers don’t want clutter, they want clarity.
Backend validation is just as important as UI — especially for date logic.
Don’t underestimate “boring” UX details. Smart defaults go a long way.

❓Question for You:
When you build event or calendar features, do you prefer a dedicated calendar UI — or filtered event lists?

Let me know how you approach these tiny-but-vital features.

See you on Day 17 👋

calendarEvents #UXMatters #LegalSoftware #LuraApp #LearningInPublic #DevBlog

Day 15 – Turning a Plain File List into a Real User Experience

Nader Fkih Hassen — Mon, 30 Jun 2025 17:45:00 +0000

Let me be honest — today’s task wasn’t particularly glamorous.

No AI models, no fancy dashboards. I spent the day working on how documents appear after upload inside Lura. Basically: I took a raw, functional file list… and made it not suck.

🧩 Why This Mattered
Lura is a lawyer management system. That means our users — mostly legal professionals — live inside cases and documents. They don’t care about our database schema or component trees. They care about clarity.

Before today, here’s what document display looked like:

- 1248dd9_contract.pdf  
- meeting_notes_final_final_2.docx  
- IMG_23423.jpg

That was it. Not great.

⚙️ What I Did
I redesigned the component to show:

File type icon (PDFs, Word docs, images, etc.)
Human-readable file sizes using pretty-bytes
Timestamps like “uploaded 3 hours ago”
Image previews on hover (for supported types)
Conditional delete button based on user role

On the frontend, I used useRouter() and useUser() to grab the active user’s role and decide what actions they could perform.

{canDelete && (
  <button onClick={() => deleteFile(file.id)}>🗑️ Delete</button>
)}

<span>{prettyBytes(file.size)}</span>
<span>{dayjs(file.createdAt).fromNow()}</span>

🔧 Backend Cleanup
In NestJS, I made sure each upload stored:

File name
Size
MIME type
Case & Workspace linkage
Uploading user

Then I cleaned up the file retrieval route to send everything needed to the UI without extra processing.

return await this.prisma.document.findMany({
  where: { caseId },
  include: { uploadedBy: true },
});

💡 Reflections
This wasn’t a big, technical challenge. But I think it’s one of the most important things I’ve done so far.

Why?

Because it reminded me that good software is about humans. Not code. Not complexity. People.

Our users don’t care if the backend is elegant. They care if they can see their contract at a glance. That’s it.

And now? They can.

❓Question:
How do you turn “boring” features into something thoughtful in your projects?

Would love to hear about how others think about UX in places nobody notices — until it’s done wrong.

See you tomorrow 👋

FullstackDev #NestJS #NextJS #LegalTech #LuraApp #LearningInPublic #UXDesign

📝 Blog Post – Day 14: Implementing Role-Based Access Control (RBAC)

Nader Fkih Hassen — Sun, 29 Jun 2025 17:40:04 +0000

Today’s focus in the Lura project was on Role-Based Access Control (RBAC) — a concept that ensures users only have access to what they’re supposed to see or do.

🔐 Why RBAC Matters
In a legal platform like Lura, different users (lawyers, admins, super admins) need clearly defined responsibilities and permissions. You can’t allow a regular lawyer to delete documents, or a new user to modify system settings. RBAC solves that by assigning roles and mapping them to actions.

🧩 Goals of Today’s Feature:

Clearly define 3 user roles: Lawyer, Admin, Super Admin
Secure sensitive API routes (delete, update, create)
Control visibility of buttons and pages in UI
Prevent role spoofing by enforcing checks server-side
Ensure new users are onboarded with appropriate roles

⚙️ How I Built It
📦 Backend (NestJS + Prisma)

I used NestJS Guards and a custom @Roles() decorator to protect controller routes.
User roles were stored in the database using Prisma’s user model.
I created middleware that intercepts requests and checks JWT tokens for valid roles.

@UseGuards(AuthGuard, RolesGuard)
@Roles('admin')
@Delete('/document/:id')
removeFile() { ... }

💻 Frontend (Next.js + Context)

I pulled the logged-in user’s role from the session context.
Using conditional rendering, I hid buttons and restricted actions for lower roles.

Example:

{user.role === 'admin' && <DeleteButton />}

🔒 Extra Layer of Security
You can’t trust frontend checks alone. That’s why every sensitive route also has backend protection — ensuring only valid roles can trigger dangerous actions like deletions or workspace edits.

I also created a helper function to easily assign roles during registration based on invitation logic (admin invites lawyer, super admin creates admins, etc.).

✅ Key Lessons & Takeaways:

RBAC creates safer and more maintainable software.
It prevents accidental misuse and enforces real-world policies.
NestJS makes backend security very modular with guards and decorators.
UI must align with backend logic — security isn’t only about APIs.
Planning your access model early makes future scaling easier.

❓ Question:
How do you handle permissions in your web apps?
Would you go with RBAC, ACL (Access Control Lists), or something more dynamic like policy-based access?