Forem: Prashant Swaroop

Technical breakdown of My Feedback Sass application

Prashant Swaroop — Sun, 07 Sep 2025 06:28:55 +0000

🚀 How I Optimized the Backend of My Feedback SaaS

In this blog, I’ll break down how I built my feedback collection app — but with a focus on backend architecture and performance improvements.

⚠️ Heads up: I won’t be diving into Next.js internals or frontend details. My focus lies in backend systems, data design, and the tradeoffs I made. Let's get into it.

🧰 What Did I Build?

At its core, my app works like Google Forms — but for targeted user feedback.

You upload a list of emails in a CSV.
Tag them by category (e.g., Developer, User, Project Manager).
Create a topic like “Alpha Testing Feedback”.
Select who should get that feedback request.
They receive a magic link that opens the form with the topic and context.
They submit feedback. Done ✅

It’s simple on the surface, but has some interesting backend challenges.

🧠 Schema Design and Structure

Here’s the simplified schema:

📌 Observation: The upper half of the schema is tightly coupled to the workspace, which represents the core business logic.

Things like payments or quota tracking are intentionally separated. This makes the code more modular and easier to scale.

❗ Challenge 1: One Person, Multiple Roles

In real teams, people wear multiple hats — someone might be both a Developer and a Project Manager.

I didn’t want to duplicate email entries across categories — that would lead to:

Redundant data
Ghost updates
Harder data consistency

Instead, I introduced a pivot table to manage many-to-many relations between emails and roles.

That’s when things got tricky — on every new upload, I now had to:

Check if an email already exists.
Update its category associations without duplication.

Prisma Schema:-

model Category {
  id           String                 @id @default(cuid())
  name         String
  workspaceId  String
  workspace    Workspace              @relation(fields: [workspaceId], references: [id], onDelete: Cascade)
  emailEntries CategoryToEmailEntry[] // one category could be associated with multiple entries
  ...                               // one to many category -> pivotTable
  @@unique([workspaceId, name])
}

model EmailEntry {
  id          String   @id @default(cuid())
  email       String
  name        String?
  workspaceId String
  workspace   Workspace  @relation(fields: [workspaceId], references: [id], onDelete: Cascade)
  categories  CategoryToEmailEntry[]  // here as well one email could be associated with multiple entries in pivot table
  ...                                 // one to many emailEntry -> pivotTable
  @@unique([workspaceId, email])
}

// Pivot table
model CategoryToEmailEntry {
  categoryId   String     // just updates the associations no need to complicate this
  emailEntryId String
  ...
  @@id([categoryId, emailEntryId])
}

🧩 Email Association Logic (CSV Upload)

✅ Problem:

When adding emails to a workspace via CSV upload, each email can fall into one of these categories:

New email: Never used and never associated with any category.
Already associated: Email is already linked to the given category.
Used elsewhere: Email exists but is associated with a different category.

🛠️ Solution:

Case 1: Insert the email into the database and link it to the category via the pivot table.
Case 2: Skip — no further action needed.
Case 3: Identify and update the pivot table to associate the email with the new category.

⚙️ Optimizations:

Prisma $transaction ensures atomic operations (either all succeed or all fail).
Map usage replaces O(n²) filtering logic with O(n log n) performance.
Edge case: Repeated uploads or attempts to re-associate the same email are gracefully handled.

Code :-

const emailSchema = z.object({
  email: z.string().trim().email("invalidEmail Provided")
})

type emailRow = z.infer<typeof emailSchema>

interface CsvRow {
  email?: string; // CSV might have missing or empty values
}

export async function POST(req: NextRequest) {

  try {

    const formData = await req.formData();

    const workspaceId = formData.get("workspaceId");
    const categoryId = formData.get("categoryId");
    const csvFile = formData.get("csvFile");

    // we take the data as a form 

    if (!workspaceId || !categoryId) {
      return NextResponse.json({ success: false, message: "workspaceId is missing " }, { status: 400 });
    }

    if (!csvFile || !(csvFile instanceof Blob)) {
      return NextResponse.json({ success: false, message: "CSV file missing" }, { status: 400 });
    }

    // verified if files and other things exist

    const text = await csvFile.text();

    const result = parse(text, {
      delimiter: ",",
      header: true, // assumes first row is column headers like "email"
      skipEmptyLines: true,
    });

    // parsing the emails csv file 
    // if you are interested in core optimisations look for prisma transactions

    if (result.errors.length > 0) {
      console.error(" CSV Parse errors:", result.errors);
      return NextResponse.json({ success: false, message: "CSV parsing failed" }, { status: 400 });
    }

const emailData: CsvRow[] = result.data as CsvRow[];

const validRows: emailRow[] = [];
const invalidRows: { row: CsvRow; error: string }[] = [];

    for (const row of emailData) {
      const parsed = emailSchema.safeParse({
        email: row.email?.trim()
      })

      if (parsed.success) {
        validRows.push(parsed.data)
      }
      else {
        invalidRows.push({ row, error: parsed.error.message })
      }
    }

    const emails = Array.from(new Set(validRows.map((r) => r.email)))

    if (!emails.length) {
      return NextResponse.json({ success: false, message: "no unique/valid email" }, { status: 400 })
    }

    // till this we have done few things 
    // used zod to validate emails 
    // if they are valid then kept in a validRows array
    // if they dont pass the zod validation value along with reason is saved in invalidRows array

    // now since we have the data lets see the optimisations

    const resultTx = await prisma.$transaction(async (tx) => {

      const getAllExistingEmails:EmailEntry[] = await tx.emailEntry.findMany({
        where:{
          email:{in: emails},
          workspaceId:workspaceId as string
        }
      })

      // we are checking each email to see of they are added in database earlier or not 
      // to prevent duplicate if you remember

      const existingEmailMap = new Map(
        getAllExistingEmails.map((entry)=>[entry.email, entry])
      ) 

      // created a map for easy and constant lookup (maps are faster to lookup data and filter so first optimisation done)

      const newEmails = emails.filter((email)=>(!existingEmailMap.has(email)))

      // this checks the map by comparing emails field if nothing matches we return the emails 

      // now add all the new emails to database
      const addNewEmails = await Promise.all(
        newEmails.map((data)=>(
            tx.emailEntry.create({
            data:{
              email:data,
              workspaceId:workspaceId as string
            }
          })
        ))
      )

      // now link new email with category and add it to the pivot table

      await tx.categoryToEmailEntry.createMany({
        data:addNewEmails.map((data)=>(
          {
            emailEntryId:data.id,
            categoryId:categoryId as string
          }
        ))
      })

      // check which existing email is linked 
      // now this linkedemail could either be linked to category which user has currently given or existing one
      // even if email is linked to any other category we still have to link it to our new categor
      // so what do we have to sort -> emails that are linked with current category

      // how do we do that getAllExisting Linked Emails
      // check which one is already linked to our new/current category discard that we dont need that
      // now link all the filtered emails to current category
      // ignore this it was when i was figuring it out



      // now we check which emails are already linked to some other category

      const linkedEntriesOnly = getAllExistingEmails


      // here we are checking condition 2 where email could be liked to give category already

      const existingPivotLinks = await tx.categoryToEmailEntry.findMany({
        where:{emailEntryId:{in: linkedEntriesOnly.map((e)=>e.id)},
      categoryId:categoryId as string}
      })

      const existingPivotLinksMap = new Map(
        existingPivotLinks.map((value)=>[value.emailEntryId, value])
      )

      // this new map has already linked emails to category condition 2
      // now we filter to get not linked email to our current category condition 3

      const notLinkedData = getAllExistingEmails.filter((emailData)=>(!existingPivotLinksMap.has(emailData.id)))

      // finally add all not linked values to our table (it was linked with some other category)
      if(notLinkedData.length  > 0){
        await tx.categoryToEmailEntry.createMany({
          data:notLinkedData.map((data)=>({
            emailEntryId:data.id,
            categoryId:categoryId as string
          }))
        })
      }



      return [...addNewEmails, ...notLinkedData]

    })

    return NextResponse.json({
      success: true,
      added: resultTx.length,
      skipped: invalidRows.length,
      invalid: invalidRows, // if you want to show it in frontend
    });

  } catch (error) {

    console.error("error happend while adding emails", error)
    return NextResponse.json({ success: false, message: "error while adding emails" }, { status: 500 })

  }

}

📩 Invite Email Logic

🎯 Problem:

You want to:

Avoid inviting the same email twice to a topic.
Prevent abuse — no spammy repeated invites.
Limit unnecessary costs — SMTP isn’t free 💸.
✅ Track email usage — this system uses emailQuota tracking, which is explained separately.

🧠 Solution:

Check if an invite was already sent for that emailId + topicId.
Store the status (SENT or FAILED) in DB.
Update user’s emailUsage count only for successful sends.
Use Promise.allSettled to:
- Offload email sending in parallel.
- Ensure that one failed email doesn't stop others — unlike Promise.all.
- Useful for batch jobs where partial success is okay.
- Lets you track both fulfilled and rejected results — so you can log failures, retry, or inform the user.

import { prisma } from "../../../lib/prisma";
import { NextResponse, NextRequest } from "next/server";
import crypto from "crypto";
import { validateQuota } from "@/lib/emailQuota";
import { sendInviteEmail } from "@/lib/sendInvite";

type InviteResult = {
  status: "SENT" | "FAILED";
  emailEntryId: string;
  token: string;
  errorMessage: string | null;
};
// type of response to track success/failure of a promise.

export async function POST(req: NextRequest) {
  try {
    const formData = await req.formData();
    const emailIds = formData.getAll("emailIds") as string[];
    const topicId = formData.get("topicId") as string;
    const workspaceId = formData.get("workspaceId") as string;

    if (!emailIds?.length || !topicId || !workspaceId) {
      return NextResponse.json({ success: false, message: "Invalid form data" }, { status: 400 });
    }

    const quotaError = await validateQuota(workspaceId);
    if (quotaError) return quotaError;
    // till now everything is preety staightforward i hope

    // now we check how many emailIds were already used for invite

    const existing = await prisma.invitation.findMany({
      where: { emailEntryId: { in: emailIds }, topicId },
      select: { emailEntryId: true },
    });
     // we have used set to map values emailId (database generated Id not real one thats normalized :) ) 
    const alreadyInvited = new Set(existing.map((e) => e.emailEntryId));
    // this gives us new ids to invite
    const toInvite = emailIds.filter((id) => !alreadyInvited.has(id));

   // if nothing new then send that emails/invitations are already sent out
    if (!toInvite.length) {
      return NextResponse.json({ success: false, message: "All invites already sent" });
    }

   // now we get real world emails ids only for new/unused emailIds

    const emailEntries = await prisma.emailEntry.findMany({
      where: { id: { in: toInvite } },
    });
   // topic for which the emails need to be send off
    const topic = await prisma.topic.findUnique({
      where: { id: topicId },
      select: { title: true, description: true },
    });

    if (!topic) {
      return NextResponse.json({ success: false, message: "Topic not found" });
    }
  // lesson how to use Promise.allSettled with custom values to later filter the fulfilled/rejected Promises (personal message ignore)

  // we have used Promise.allSettled here so that codes can run in parallel and things get offloaded to worker threads as well
  // see explanation for better understanding why this is used

    const result = await Promise.allSettled(
      emailEntries.map((entry)=>{
         const token = crypto.randomUUID() // this token will be used to validate invitation in future
         const inviteLink = `${process.env.DOMAIN}/invite/?token=${token}`
         return sendInviteEmail({
          to:entry.email,
          inviteLink,
          topicDescription:topic.description,
          topicTitle:topic.title    // till this fairly simple stuff 
         }).then<InviteResult>(()=>({ // now we catch values in result as InviteResult type for filtering success/failed email sent attempts
          status:'SENT' as const,
          emailEntryId:entry.id,
          token,
          errorMessage:null
         }))
         .catch<InviteResult>((error)=>({
           status:'FAILED' as const,
          emailEntryId:entry.id,
          token,
          errorMessage:error?.message || "Unknown error"
         }))
      })
    )
    // now we filter how many were sent successfully and how many were not

    const successfulInvite = result.filter((r): r is PromiseFulfilledResult<InviteResult> => r.status === "fulfilled")
    .map((r)=>r.value)
    .filter((r)=>r.status === "SENT")


    const failedInvite = result.filter((r): r is PromiseFulfilledResult<InviteResult> => r.status ==="rejected")
    .map((r)=>r.value)
    .filter((r)=> r.status === "FAILED")

    console.log(failedInvite,"failedInvite")

    console.log(successfulInvite, "successfulInvite")

    //we can add the expiryDate here for inviteSubmission.
     // checking success length then adding them in database and then 

    if(successfulInvite.length > 0){
      await prisma.$transaction(
        successfulInvite.map((invite)=>
          prisma.invitation.create({
            data:{
              emailEntryId:invite.emailEntryId,
              token: invite.token,
              topicId,
              inviteStatus:"SENT",
              sentAt:new Date(),
              error:null
            }
          })
        )
      )
    }

      // we also add failed once in 

    if(failedInvite.length > 0){
      await prisma.$transaction(
        failedInvite.map((invite)=>
          prisma.invitation.create({
            data:{
              emailEntryId:invite.emailEntryId,
              topicId,
              token: invite.token,
              inviteStatus:"FAILED",
              error:invite.errorMessage,
            }
          })
        )
      )
    }
   // once everything is done we update users emailUsage count
       await prisma.emailUsage.update({
      where:{
        workspaceId
      },
      data:{
        sentCount:{increment: successfulInvite.length}
      }
    })

    return NextResponse.json({
      success: true,
      message: "Processed invites",
      total: emailEntries.length,
      sent:successfulInvite.length,
      failed:successfulInvite.length
    });

  } catch (error) {
    console.error("Send invite error:", error);
    return NextResponse.json({ success: false, message: "Internal Server Error" }, { status: 500 });
  }
}

`EmailQuota` Code-

import { auth } from "@clerk/nextjs/server";
import { prisma } from "@/lib/prisma";
import { NextResponse } from "next/server";

export async function validateQuota(workspaceId: string) {
  const startOfMonth = new Date();
  startOfMonth.setDate(1);
  startOfMonth.setHours(0, 0, 0, 0);

  const { userId } = await auth();

  if (!userId) {
    return NextResponse.json({ success: false, message: "Please log in before inviting." });
  }

  // Ensure usage entry exists or is reset for the new month
  const existingUsage = await prisma.emailUsage.findUnique({ where: { workspaceId } });

  if (!existingUsage) {
    await prisma.emailUsage.create({ data: { workspaceId, month: startOfMonth, sentCount: 0 } });
  } else if (existingUsage.month.getTime() < startOfMonth.getTime()) {
    await prisma.emailUsage.update({
      where: { workspaceId },
      data: { sentCount: 0, month: startOfMonth },
    });
  }

  const emailUsage = await prisma.emailUsage.findUnique({ where: { workspaceId } });

  const subscription = await prisma.activeSubscription.findFirst({
    where: { clerkId: userId, isCancelled: false },
  });

  // Handle free users
  if (!subscription && emailUsage && emailUsage.sentCount >= 500) {
    return NextResponse.json({
      success: false,
      message: "Free tier exhausted. Wait until next month or upgrade.",
    });
  }

  // Handle subscribed users with a pricing plan limit
  if (subscription && emailUsage) {
    const pricing = await prisma.pricing.findUnique({
      where: { id: subscription.pricingId },
      select: { emailUsageLimit: true },
    });

    if (
      pricing?.emailUsageLimit !== null &&
      pricing?.emailUsageLimit !== undefined &&
      emailUsage.sentCount >= pricing.emailUsageLimit
    ) {
      return NextResponse.json({
        success: false,
        message: "You have exhausted your quota for this month based on your plan.",
      });
    }
  }

  return null; // All good
}

💳 Payments

There's not much to optimize in the payment flow itself, but a few deliberate design choices made things clean and secure.

First, the frontend only sends a pricingId — this maps to the actual price on the backend, so users can't tamper with payment amounts. This separation makes the flow safer: the backend controls the price; the frontend just selects a plan.

We've also prevented subscription stacking — a user can't subscribe to multiple plans at once. This made sense for our use case, where simplicity was more important than supporting plan upgrades/downgrades.

A key design decision here is that payment is tied directly to the clientId (via Clerk) rather than the workspace. This allows users to get started immediately — they don't have to first create a workspace to purchase a subscription. Even if they later delete the workspace, their plan benefits stay intact, since they're tied to the user, not the workspace.

We use a transaction to ensure everything (activating a plan, saving the order, creating payment records) happens atomically — no inconsistent state if something fails midway.

I’ve also added a bit of redundant data by linking the active subscription directly to clerkId. Since this is mostly read-heavy data, it's worth the small duplication to avoid traversing from orders → payments → subscriptions every time.

I won’t go deep into Razorpay’s payment lifecycle here — this blog focuses on the business logic and trade-offs I made, not payment gateway internals

Order creation code

import { NextRequest, NextResponse } from "next/server";
import Razorpay from "razorpay";
import z from "zod";
import { prisma } from "../../../lib/prisma";
import { auth } from "@clerk/nextjs/server";
import { OrderStatus } from "@prisma/client";

type RazorpayOrderResponse = {
  id: string;
  entity: "order";
  amount: number;
  amount_paid: number;
  amount_due: number;
  currency: string;
  receipt: string;
  offer_id: string | null;
  status: "created" | "attempted" | "paid";
  attempts: number;
  notes: Record<string, string>;
  created_at: number;
};

// const Subscription = z.enum(["MONTHLY", "QUARTERLY", "HALF_YEARLY", "YEARLY"]);

const orderSchema = z.object({
  pricingId: z.string(),
  clerkId: z.string(),
});

if (!process.env.RAZOR_KEY_ID || !process.env.RAZOR_SECRET_ID) {
  throw new Error("Razorpay environment variables are missing");
}

const razorPay = new Razorpay({
  key_id: process.env.RAZOR_KEY_ID as string,
  key_secret: process.env.RAZOR_SECRET_ID as string,
});

// we are taking pricing plan for order creation 
// find the plan user want to subscribe 
// then create a order for that subscription plan
// if user has already an active plan we are not letting them stack plans

export async function POST(req: NextRequest) {
  try {
    const body = await req.json();

    const parsedData = orderSchema.safeParse(body);

    if (!parsedData.success) {
      return NextResponse.json(
        {
          success: false,
          message: `validation failed: ${parsedData.error.message}`,
        },
        { status: 400 }
      );
    }

    // lets check active subscription

    const checkSubscription = await prisma.activeSubscription.findFirst({
      where: {
        clerkId: parsedData.data.clerkId,
        isCancelled: false,
        expiryDate: {
          gt: new Date(),
        },
      },
    });

    if (checkSubscription) {
      return NextResponse.json(
        { success: true, message: "You already have an active subscription" },
        { status: 200 }
      );
    }
   // check subscription user want to pay for
    const fetchPricingPlan = await prisma.pricing.findUnique({
      where: {
        id: parsedData.data.pricingId,
      },
    });

    if (!fetchPricingPlan) {
      return NextResponse.json(
        {
          success: false,
          message: "could not find the plan",
        },
        { status: 404 }
      );
    }
    // create new order 
    const createNewOrder = (await razorPay.orders.create({
      amount: fetchPricingPlan.price,
      currency: fetchPricingPlan.currency,
      receipt: parsedData.data.clerkId,
      notes: {
        Subscription: fetchPricingPlan.subscription,
        clerkId: parsedData.data.clerkId,
      },
    })) as RazorpayOrderResponse;

    await prisma.order.create({
      data: {
        amount: fetchPricingPlan.price,
        clerkId: parsedData.data.clerkId,
        subscription: fetchPricingPlan.subscription,
        razorPayOrderId: createNewOrder.id,
        pricingId: parsedData.data.pricingId,
        status:"CREATED"
      },
    });

    return NextResponse.json({
      success: true,
      order: createNewOrder,
    });
  } catch (error) {
    console.error("error happened while creating the order: ", error);
    return NextResponse.json(
      {
        success: false,
        message: "Internal Error happend Try Again Sorry for inconvience",
      },
      { status: 500 }
    );
  }
}

Payments Code

import { NextRequest, NextResponse } from "next/server";
import crypto from "crypto"
import { prisma } from "@/lib/prisma";
import { auth } from "@clerk/nextjs/server";

export async function POST(req: NextRequest) {

    try {

        const body = await req.json();

        const { razorpay_order_id, razorpay_payment_id, razorpay_signature } = body;

        const hmac = crypto.createHmac("sha256", process.env.RAZOR_SECRET_ID!)

        hmac.update(`${razorpay_order_id}|${razorpay_payment_id}`);

        const generatedSign = hmac.digest("hex")

        const isValid = generatedSign === razorpay_signature

        if (!isValid) {
            return NextResponse.json({
                success: false,
                message: "payment data tampered"
            })
        }

        const { userId } = await auth()

        if (!userId) {
            return NextResponse.json({
                success: false,
                message: "missing auth at server"
            })
        }

        const getOrder = await prisma.order.findUnique({
            where: {
                clerkId: userId,
                razorPayOrderId: razorpay_order_id
            }
        })

        if (!getOrder) {
            return NextResponse.json({
                success: false,
                message: "linked order could not be found"
            })
        }

        const updateTx = await prisma.$transaction(async (tx) => {
            await tx.order.update({
                where: {
                    id: getOrder.id
                },
                data: {
                    status: "PAID"
                }
            })

            const payments = await tx.payment.create({
                data: {
                    razorPayPaymentId: razorpay_payment_id,
                    razorPayOrderId: razorpay_order_id,
                    razorPaySignature: razorpay_signature,
                    orderId: getOrder.id,
                    status: "SUCCESS",
                    isVerified: true,
                }
            })

            const fetchPlan = await tx.pricing.findUnique({
                where: {
                    id: getOrder.pricingId
                }
            })

            if (!fetchPlan?.validity) {
                throw new Error("Pricing plan missing validity");
            }

            // Calculate expiry date
            const expiryDate = new Date();
            expiryDate.setDate(expiryDate.getDate() + fetchPlan.validity);

            const subs = await tx.activeSubscription.create({
                data: {
                    clerkId: userId,
                    paymentId: payments.id,
                    pricingId: getOrder.pricingId,
                    expiryDate: expiryDate
                }
            });

            return subs;

        })

        return NextResponse.json({
            success:true,
            message:"Payment Linked successfully.",
            data:updateTx
        })

    } catch (error) {

        console.error("error happend while trying to verify the secret", error);
        return NextResponse.json({
            success: false,
            message: "error happend at our side."
        }, { status: 500 })

    }

}

🚧 Wrapping Up

This marks the end of my blog. The current implementation handles a lot — from invite creation to email dispatch and retry logic.

But let’s be honest: it’s not failproof.

Right now, failed email invites are only tracked (thanks to database), but we don't yet have a system to reprocess them automatically. To build a more resilient backend, a message broker like RabbitMQ or a managed queue system (like Supabase Edge Functions with retries or Resend webhooks) could be introduced.

This would mean:

A separate, persistent job server.
Better fault tolerance.
Smarter retries and dead-letter queues.

The diagram I’ve added is a rough visual of where this might go — a system that scales better and handles edge cases more gracefully.

But for now, this is where I pause the journey.

🔄 Future Plans

⏳ Replace basic retry logic with a queue (RabbitMQ / Resend / Supabase functions).
🔁 Implement smart retries + dead-letter tracking.
🧪 Add alerting/monitoring for failed jobs.
🧱 Make the backend more fault-tolerant and distributed.
📈 Eventually move to a dedicated worker service for background jobs.

Backend Diagram For Future

💬 A Note to Readers

If I’ve made mistakes — I want to learn. I’m still figuring things out and it’s a bitter pill to swallow sometimes when a month’s work still feels incomplete. But if that’s what it takes to grow into a better developer, I’m here for it.

Feedback and criticism are more than welcome.

Thanks for reading.

What 3 Days of Debugging WebSockets Taught Me

Prashant Swaroop — Sun, 07 Sep 2025 06:16:49 +0000

I thought building a chat app would be easy. Then I spent three days debugging phantom WebSocket bugs.

Everybody can whip up a toy chat app. The real pain starts when you want to make it maintainable. These three lessons saved me from drowning in ghost bugs. If you’re building anything real with WebSockets, I hope they save you too.

⚔️ Lesson 1: Draw a Hard Line Between Client→Server and Server→Client Messages

In my first attempt, I shoved everything into a single .on("message") handler. End result: total chaos. Messages firing left and right, no clue who said what, and me drowning in logs.

The fix was stupidly simple:

Client → Server: only chats, receipts, typing events.

Server → Client: only info, errors, and routing payloads.

Once I separated these flows, the routing logic only lived where it should, and the server stopped losing its mind. Debugging went from “WTF is this?” to “oh, that’s exactly where it broke.”

Here’s the mental model that finally clicked for me:

    ws.on("message", (data, isBinary) => {

      if (isBinary) {
        logger.info("we have a binary payload in on messages! not handling that")
        return;
      }

      const recievedMessage: Envelope | null = parseEnvelope(data)

      if (recievedMessage == null) {
        logger.info("some weird message format recieved")
        return;
      }

      switch (recievedMessage.type) {

        case "chat":
          handleChatMessages(ws, recievedMessage, userToWs, user.id)
          break;

        case "ack":
          handleAck(ws, recievedMessage, userToWs, user.id)
          break;

        default:
          logger.info("you have sent an invalid choice.")
          break;
      }

    })

    // as you can see we only need to handle two types of messages!

2. Don’t mutate the payload schema mid-flight

Biggest rookie mistake I made: sneaking extra fields into my payloads because “eh, quick fix.” Guess what? Three days of phantom bugs later, I realized I was the ghost haunting my own system.

Rule of thumb:

Define your schema once.
Never mutate it in transit.
If you need optional stuff → build it optional into the schema.

Your future self will thank you.

import { z } from "zod";

/**
 * Client → Server: Chat message
 */
export const ChatMessageSchema = z.object({
  type: z.literal("chat"),
  to: z.string(),
  from: z.string(),
  messageId: z.string(),
  message: z.string(),
  mode: z.enum(["offline", "online"]),
  timestamp: z.number(),
  streamId: z.string().optional(), // should be string, not object
});

/**
 * Client → Server: Acknowledgement
 */
export const ChatAckSchema = z.object({
  type: z.literal("ack"),
  to: z.string(),
  from: z.string(),
  messageId: z.string(),
  timestamp: z.number(),
  streamId: z.string().optional(),
  ackType: z.enum(["read", "delivered"]),
});

/**
 * Server → Client: System info
 * Example: "you are connected", "server restarting", etc.
 */
export const SystemInfoSchema = z.object({
  type: z.literal("system"),
  message: z.string(),
});

/**
 * Server → Client: Error info
 * Covers internal / external components.
 */
export const SystemErrorSchema = z.object({
  type: z.literal("error"),
  component:z.string(),
  message: z.string(),
});

/**
 * Envelope: every message in/out must be one of these.
 */
export const EnvelopeSchema = z.union([
  ChatMessageSchema,
  ChatAckSchema,
  SystemInfoSchema,
  SystemErrorSchema,
]);

// ------------ Types ------------
export type ChatMessage = z.infer<typeof ChatMessageSchema>;
export type ChatAck = z.infer<typeof ChatAckSchema>;
export type SystemInfo = z.infer<typeof SystemInfoSchema>;
export type SystemError = z.infer<typeof SystemErrorSchema>;
export type Envelope = z.infer<typeof EnvelopeSchema>;

// as you can see even my message schema carries option redisstream section
// this helps in me marking which mode of message was delivered

3. Log every client exit (and don’t let React gaslight you)

Here’s a cursed one: I was testing my socket server with a React client. Connections kept dying with random exit codes like 1006 and 1005. I thought my server was broken. I debugged like a madman for three days straight.

The real culprit? React’s Strict Mode mounting/unmounting sockets dropping connection on and off.

Two takeaways:

Log how and when each client exits. It’ll save you hours.
If you’re testing with React → disable Strict Mode or just use a plain JS client.

Once I did that, the ghosts vanished and my server behaved like it should.

    ws.on("close", async (code, reason) => {
      console.log("❌ WS closed:", code, reason.toString());

      // 1. Global presence cleanup
      await terminateUserFromRedis(user.mobileNo)

      // 2. In-memory maps cleanup
      userToWs.delete(user.mobileNo);  // userId → ws map
      wsToUser.delete(ws);             // ws → userId map
      activeConnection.delete(ws);     // ws → liveness flag

      // 3. Logging
      logger.info(`User disconnected: ${user.mobileNo}`);
    });

    // this alone will help you in understand why any connection drops!
    // its your insurance against connections dropping left and right

🏁 Closing Thoughts

Toy chat apps are easy. Debuggable chat apps are hard. The sooner you:

draw hard lines between client and server messages,

respect your schemas, and

log religiously,

…the less you’ll fear WebSockets, and the faster you’ll build systems you can actually trust.

How I Survived My First Full-Stack App with Next.js App Router

Prashant Swaroop — Sun, 20 Jul 2025 09:53:53 +0000

The story begins—as it always does—with a tutorial.

I was watching yet another video and thought: “Let’s build a full stack app.” I already had a background in React, and I’d made a few full stack projects before. So this time, I chose Next.js. It looked easy, especially with the new App Router.

Why Next.js? Because it’s React at the front, backend APIs included, and server actions baked right in. No need for separate Express servers or wiring up extra routers. Also, the assumption was simple: everything is a server component unless you slap a "use client" on top. I was in.

✨ Why I Fell in Love with the App Router

One of the best things about Next.js is the App Router. You don’t need to install React Router and define routes in App.jsx. Just drop a file in the /app folder, and boom—it’s a route. It's simple. It’s fast. It works.

🤯 First Battle: The UI Fear

Here’s my harsh truth—I suck at design.

My pages looked ugly. And that really messes with you. It triggers imposter syndrome. I’d open VS Code, freeze, and think: What do I even build here? The spiral begins: “Am I even cut out for frontend dev?”

Sound familiar? Been there. This time, I didn’t let it win.

Here's how I beat the block:

Took breaks when stuck.
Drew wireframes, even if they were ugly. Just enough to give me direction.
Used inspiration from other websites. Seriously, 90% of the internet uses the same layout tricks. Why not learn from them?
Tools like Google Stitch, v0.dev, and Bolt helped generate page ideas and inspiration.

Any progress is better than no progress. Remember that.

❤️ Server Actions

God bless Server Actions.

No more creating an API route or writing fetch calls and handling them manually. Need to read from the server? Just keep the page component as a server component, use a Server Action to grab the data, and pass it down to your client components. Done.

You can use server actions inside client components too, but there are caveats. I won’t pretend I know them all—this project was me figuring things out on the fly. So I won’t preach, but here’s what worked for me:

Keep data fetching in server components.
Use server actions to mutate or fetch data.
If using forms, yes—you can still call server actions from client components.

🧠 How I Wrote Ugly Code—Fast

Not gonna lie. I was a messy developer in the beginning.

Every time I made a new page/component, I didn't care about reusability. Things got chaotic fast.

But I followed one rule: put every component inside a well-named folder. For example: /components/dashboard/Table.tsx. Later, when I needed it somewhere else, I refactored it—added props, defined interfaces, added type safety—and made it reusable.

So... am I a great React developer? Maybe not.

Am I resourceful and fast? Yes.

Best case: smart developer.

Worst case: functional chaos.

💌 The Email Saga

Now I understand why dev’s complain about bad DX (Developer Experience) on Twitter.

Until now, I had a chill life—React + Vite, everything worked like magic. But for this project, I needed to send emails inviting users to give feedback.

I initially tried Mailjet — looked promising, solid docs, decent limits. But then... everything broke after sending just 5 emails.

I got hit with a "temporary restriction" and no real explanation. Just a vague message and complete silence. I waited three days, hoping the ban would lift. Spoiler: it didn’t.

That’s when I realized how important good developer experience really is.

If I ever build a dev tool, I’m writing great docs, clear errors, and probably a fun YouTube guide.

So, I ditched Mailjet and moved to Resend — and this time, everything just worked. Fast setup, friendly DX, and no cryptic errors.

❤️ Huge shoutout to Resend.

🚫 No hard feelings, Mailjet — but that experience wasn’t it.

💀 The Broken Database Horror

After surviving all that, I wanted to brag on LinkedIn: “Hey look! I integrated payments!” Even if they were test payments—still, it’s progress.

But the horror unfolded quickly.

Understanding how payments work end-to-end—from initiation to confirmation—is critical. If you don’t, you’ll keep breaking your schema with every little change.

What I learned:

If you're dealing with third-party APIs or external systems, always:

Track their status (pending, success, failure)
Use enum fields to reflect the state
Expect that some parts of the flow are out of your control

Know what you're storing and when. Or prepare to suffer. And yes, it will become a dev horror story.

🧹 Linting + TypeScript Woes

I used to think linting was just that one VS Code extension that makes code pretty.

Then I ran npm run build.

Boom. 10,000+ lines of errors. Why? It tried to lint the auto-generated code too.

So yeah, I had to:

Fix unused variables
Replace any types
Update configs to ignore generated folders

Lesson learned: don't skip linting. TypeScript isn’t just for safety—it’s a build-saver.

🚀 Deployment & Production Nightmares

I’d spent a month building this project. Now it was time to ship. Resume-ready, you know?

I used Vercel. Guess what?

Vercel kept trying to render server pages as static. My build kept failing.

Turns out: Vercel will try to statically generate everything unless you tell it not to.

Solution:

export const dynamic = "force-dynamic";

Boom. Now it knows your page is meant to run server-side only.

Oh, and Supabase—my free DB. Connecting it was hell.

There’s a pooled connection (for normal ops)
And a direct connection (for migrations)

But Prisma didn’t play well with pooled URLs. It caused weird, unexpected issues.

Fix:

Use Supabase’s "stable connection string" for local + migrations
Use Prisma Accelerate in production with the correct URL
Add the Accelerate URL to your .env.production

After that, things worked. Kinda.

🧘‍♂️ Final Thoughts

You may not have learned any technical tricks from this post. But that’s the point.

Things will break.

Abstractions will leak.

You’ll be stuck. Frustrated. Confused.

But you’re a builder. And builders show up.

That’s what matters.

❤️ Takeaway

Everyone can teach you code. I want to teach you a mindset.

If you remember just two things from this post:

Break things. That’s how you learn.
Draw wireframes. Ugly ones. It gives you momentum.

That’s it. You’ll be 10x faster than me if you just start.

👋 Follow My Journey

I write about my dev rants, lessons, and experiments—sometimes messy, sometimes insightful. If this resonated, follow me. I don’t just rant—I teach too.

Next up: how I broke and optimized my backend.

Till then,

Break. Fix. Weep. Shine.

— Love and peace,

Your fellow dev

🎁 Farewell & Little Sendoff Gifts for Curious Minds

Thanks for sticking around! If you're curious to poke around or steal some ideas (I won't tell), here are a few goodies:

🔗 Live App:

Create Next App

💻 GitHub Repo: https://github.com/PRASHANTSWAROOP001/feedback-nextjs-app
🧾 Wireframes (Chaos Included): https://raw.githubusercontent.com/PRASHANTSWAROOP001/contact-page/refs/heads/main/wireframe2.jpg, https://github.com/PRASHANTSWAROOP001/contact-page/blob/main/wireframe1.jpg?raw=true

I Took Another Shot at Fullstack—and I’m Glad I Did

Prashant Swaroop — Sun, 06 Jul 2025 14:11:06 +0000

I was learning Next.js and decided to build a fullstack application.

Now, let me tell you — my previous fullstack project?
An absolute nightmare.
It took me 45+ days of constant struggle. That experience convinced me:
“Maybe UI isn’t for me.”

And honestly?
The worst part of building fullstack apps, for me, is the UI.

Not because I can't write React or CSS — I can.
But the process of making things pixel perfect, of tweaking paddings and colors for hours... it's exhausting.
So I did what felt right:
I avoided frontend and dove deep into backend.

⚙️ I Went All-in on Backend

I learned how to use Postman properly, wrote two microservices with 5+ internal services each, and loved every minute of it.

The backend gave me control, clarity, and a direction.
No guessing. Just data, logic, flow.

But then I looked at job listings.

Node.js backend dev?
Great. Now prove you're fullstack too.

Everywhere I looked — they wanted fullstack devs.
Not just great backend folks — but frontend fluency too.

So I knew I had to face the thing I avoided: UI.

😵‍💫 My Relationship With UI Was... Not Good

I'm the kind of person who stares at a button and changes its color ten times.
I get stuck not because I can't build, but because I don't know what to build or how it should look.

Eventually, that spirals into frustration and the thought:

“Maybe I’m not cut out for frontend.”

Which could still be true.
I don’t enjoy making beautiful UIs. I rely heavily on shadcn/ui, Tailwind, and copy-paste responsiveness like grid-cols-1 md:grid-cols-3 and hope it works 😅

💥 This Time, I Took a Different Approach

This time, I had something I didn’t have before:
Experience. Patience. And grit from debugging backend hell.

I knew how to manage frustration. I knew when to take breaks. And I knew how not to give up when stuck.

So I gave fullstack one more try — but I did it my way.

Here’s What Helped Me:

🧠 1. Wireframing First

I didn’t try to design the entire app.
I just wireframed one page.

Searched other websites, looked at their layout, drew boxes and lines. That’s it.
But it worked. I had direction. No more blank screen paralysis.

🧩 2. Break Components Into Small Bits

Next.js pushes you to think in client/server components.
And I had a teacher once say: "Keep most logic on the server."

So I did just that.

All interactivity — filters, popovers, dynamic tables — went into client components.
I made small, focused client components. When I noticed reuse, I added props and cleaned them up.

This alone saved me tons of time.

⚡ 3. Used Server Actions Like Magic

This feature made me fall in love with Next.js again.

No more endless API routes.
Just write a server action, await it in a server component, and pass the data down.
Simple. Powerful. Clean.

Yes, there are limits — you can't call them inside client components directly — but once you understand the rules, it’s game-changing.

💭 My Realization

Maybe I’m not a frontend dev.
Maybe you aren’t either.

But we don’t need to be pixel-perfect UI gods to build useful, beautiful, functional fullstack apps.

All we need:

A decent wireframe
Some UI inspiration
A few solid tools (Tailwind, shadcn, maybe a little v0.dev)
And a structured mindset that knows when to break, when to push

🎁 Final Thoughts

If you've ever told yourself:

“I’m bad at UI. I should just stick to backend.”

I feel you.

But trust me — you can build the frontend too.
And with time, structure, and a little patience, you might just unlock a new mental model — one that makes fullstack enjoyable again.

Cheers 🍻 and happy coding.
Thanks for sticking through this rant — hope it helped.

🔗 GitHub Repo
🔗Demo
🎥 Demo Video / Hand-drawn Wireframes
🧠 What this project solves: “A focused way to collect topic-based feedback via email invites.”

Writing My First Microservice: A Painful Yet Rewarding Journey

Prashant Swaroop — Fri, 13 Jun 2025 15:35:29 +0000

🚀 Introduction

"I thought building my first microservice would make me a dev hero—until the API Gateway nightmare hit! 😅

This post walks through the mistakes, lessons, and the microservice trenches I went through while setting up my first API gateway

😤 Pain Point #1 – API Gateway Setup

So, what even is an API Gateway?

Think of it like a traffic cop or central bouncer — every request from the frontend comes here first. It then routes the request to the correct service: Auth, Payments, Listings, etc.

It's also the only service exposed to the outside world.

😩 Why was this painful?

It sounds simple, but setup gets complex really fast.
Forwarding headers and preserving user context was tricky.
Debugging routing and rewriting paths is not very intuitive.

💥 Pain Point #2 – Forwarding Headers for Auth

Let's take an example to understand this better.

You have two microservices:

🛡️ Auth Service – handles login and JWTs
💳 Payment Service – processes payments

Both services are independent. So even if the user is authenticated through Auth, Payment doesn’t know that.

✅ Solution

Once the user logs in:

API Gateway verifies the JWT centrally.
Gateway extracts user info (userId, role, etc.).
It adds them as custom headers:
- x-user-id
- x-user-role
These are forwarded to other services (like Payment), which can trust the info and skip separate JWT validation.

This way, each downstream service doesn't need to re-verify the token. They just trust the gateway.

🔁 Choosing the Right Proxy Middleware

At first, I used express-http-proxy.

It worked, but was too verbose and required too much config.

Then I discovered http-proxy-middleware.

It’s cleaner, easier to set up, and works beautifully with Express.

⚙️ Code Walkthrough

Let’s break down how the setup looks in code.

📦 API Gateway Setup with http-proxy-middleware

import { createProxyMiddleware, Plugin } from "http-proxy-middleware"; // import the main library
import logger from "./utils/logger"; // pino logger to log things
import { RequestHandler } from "express";
import dotenv from "dotenv";
import { JwtPayload } from "jsonwebtoken";

// Interface for typed JWT payload
interface JwtUserPayload extends JwtPayload {
    userId: string;
    role: string;
    email: string;
}

// base url on which you are going to forward the request. 
// in our case we are forwarding request to auth service
const authTargetUrl: string = process.env.IDENTITY_SERVICE!; 

// 🔥 Quick note: don’t write 'localhost' when targeting localhost it has some issues in resolving this
// Use the IP like 127.0.0.1:5000 

// plugin to log proxy requests using Pino
const pinoLogPlugin: Plugin = (proxyServer) => {
    proxyServer.on('proxyReq', (proxyReq, req, res) => {
        logger.info(`[PROXY] ${req.method} ${req.url}`);
    });
};

// a pino to visually see what method are we using like PUT POST and so on
// req.url tells us about converted url, must-have for debugging

/*
🧠 How this works:

We make a request to our API Gateway, and this proxy forwards your request
to the target URL by rewriting the initial URL into something usable.

Example: 
You make a request to: http://localhost:3000/auth-route/api/auth/login
This gets converted to: http://localhost:5000/api/auth/login
*/

const authServiceProxy: RequestHandler = createProxyMiddleware({
    target: authTargetUrl, // our target url = http:localhost:5000 
    changeOrigin: true,
    pathRewrite: {
        '^/auth-route': '', // removes /auth-route from the path
    },
    plugins: [pinoLogPlugin],
    on: {
        proxyReq: (proxyReq, req, res) => {
            const fullUrl = `${proxyReq.protocol || 'http:'}//${proxyReq.getHeader('host')}${proxyReq.path || ''}`;
            logger.info(`[PROXY] Rewriting and forwarding to: ${fullUrl}`);
            // this helps us debug as this gives us converted URL
        },
        proxyRes: (proxyRes, req, res) => {
            logger.info(`[PROXY] Response status from target: ${proxyRes.statusCode}`);
            // we print here what response code we get from target service
        }
    }
});

// 2nd config with header forwarding

// base URL for listing service
const listingTargetUrl = process.env.LISTING_SERVICE!;

const listingServiceProxy: RequestHandler = createProxyMiddleware({
    target: listingTargetUrl,
    changeOrigin: true,
    pathRewrite: {
        '^/listing-route': '',
    },
    plugins: [pinoLogPlugin],
    on: {
        proxyReq: (proxyReq, req, res) => {
            const fullUrl = `${proxyReq.protocol || 'http:'}//${proxyReq.getHeader('host')}${proxyReq.path || ''}`;
            logger.info(`[PROXY] Rewriting and forwarding to: ${fullUrl}`);

            const user = (req as any).user;

            // we get the user details from an auth middleware
            // which already has decoded user id and role for us
            logger.info(`user data: ${JSON.stringify(user)}`);

            if (user) {
                proxyReq.setHeader('x-user-id', user.userId);
                proxyReq.setHeader('x-user-role', user.role);
            }

            // here we set the headers before forwarding it
        },
        proxyRes: (proxyRes, req, res) => {
            logger.info(`[PROXY] Response status from target: ${proxyRes.statusCode}`);
        }
    }
});

export { authServiceProxy, listingServiceProxy };

🚦 How it's used in `server.ts`


import { authServiceProxy, listingServiceProxy } from "./proxy";
import { verifyAccessToken } from "./middlewares/auth";

app.use("/auth-route", authServiceProxy);

// Auth middleware decodes the JWT, adds user info to req.user
app.use("/listing-route", verifyAccessToken, listingServiceProxy);

🔐 Middleware: `verifyAccessToken.ts`

Because every API gateway needs a bouncer at the door.

For those of you who appreciate seeing the nitty-gritty, or just want to copy-paste (no judgment here, we've all been there! 😉), here's the code for that verifyAccessToken middleware. This bad boy takes the incoming JWT, validates it, and then — if all's good — extracts the user's userId and role and attaches it to the request for downstream services to use.


import jwt, { JwtPayload } from "jsonwebtoken";
import logger from "../utils/logger";
import { Request, Response, NextFunction } from "express";
import dotenv from "dotenv";

dotenv.config();

const JWT_SECRET: string = process.env.JWT_SECRET!;

// Define the shape of our expected user payload in JWT
interface JwtUserPayload extends JwtPayload {
  userId: string;
  role: string;
  email: string;
}

// Extend Express Request to include the decoded user info
interface AuthenticatedRequest extends Request {
  user?: JwtUserPayload;
}

// 🧠 Middleware to verify JWT token from Authorization header
const verifyAccessToken = async (
  req: AuthenticatedRequest,
  res: Response,
  next: NextFunction
) => {
  try {
    const authHeader = req.headers.authorization;

    // Bearer <token>
    const token = authHeader?.split(" ")[1];

    if (!token) {
      logger.warn("Missing auth token in header");
      return res.status(401).json({
        success: false,
        message: "Auth token is missing",
      });
    }

    // Verify the token using our secret key
    const verifiedToken = jwt.verify(token, JWT_SECRET) as JwtUserPayload;

    // Add the decoded user info to the request object
    req.user = verifiedToken;

    next(); // ✅ All good, proceed to next middleware
  } catch (error: any) {
    logger.error("Token verification failed", error);

    return res.status(401).json({
      success: false,
      message:
        error.name === "TokenExpiredError"
          ? "Token has expired"
          : "Invalid token",
    });
  }
};

export default verifyAccessToken;

🧠 2nd Pain Point — Winston made me cry 😩

Setting up logging with Winston was a tedious process. I just couldn’t digest the fact that I had to go through the entire nitty-gritty of configuration just to get basic logs working.

Like most of us, I copy-pasted it from a blog and somehow made it work. But deep down, I knew — I didn’t have the courage to go through all that ever again.

So I did what we all do... I Perplexity’d. I Googled. I Reddit’d. And one name kept coming up again and again: Pino.

So I gave it a shot. And guess what? I fell in love ❤️

✅ Why I Chose Pino

Simple: A few lines and you’re done.
Fast: One of the fastest loggers out there.
Beautiful logs: With pino-pretty, you get color-coded logs that are a joy to read.

But fair warning — in my experience, Pino has:

Limited TypeScript IntelliSense support.
A few quirky config edges, but nothing too scary.

Still, for 90% of us, we don’t even need Pino’s advanced features. Keep it simple, log your stuff, move on.

📦 Pino Config Setup

import pino from "pino";

// Define the transport configuration for Pino
const transport: any = pino.transport({
  targets: [
    {
      // Logs saved to a file (for production logs)
      target: 'pino/file',
      level: 'info',
      options: { destination: 'logs/app.log' }
      // 💡 Make sure you create a 'logs' folder in the root of your project,
      // or this will throw an error!
    },
    {
      // Logs pretty-printed to the terminal (for development)
      target: 'pino-pretty',
      level: 'debug',
      options: {
        colorize: true,
        translateTime: 'SYS:standard', // shows readable time
        singleLine: false, // optional: makes logs cleaner
        ignore: 'pid,hostname' // ignores some metadata in terminal output
        // 💡 Make sure to install both `pino` and `pino-pretty`
      }
    }
  ]
});

// Create the logger instance
const logger = pino(transport);

export default logger;

📍 Where to Place This

You should place this logger config inside utils/logger.ts, then import it wherever you need logging:


import logger from './utils/logger';

logger.info("Server started successfully 🚀");
logger.error("Something went wrong ❌");

🛠️ 3rd Pain Point — Writing microservices is easy, keeping them alive is pain 🧟‍♂️

Let’s be honest — building microservices feels great at first.

You write one service, then another, and suddenly you're an architecture god…

But wait — how do you run RabbitMQ, Redis, Auth Service, Payment Service, API Gateway all at once?

🎯 My Experience (a Windows dev’s curse)

I was using RabbitMQ for messaging and Redis for caching. It all looked good on paper until Redis decided to be like:

“Yeah sorry, I don’t work directly on Windows, figure it out.” 💀

So each time I wanted to test my services:

I had to start WSL manually
Then do redis-cli
Then ping a message just to make sure Redis was alive and not throwing ECONNREFUSED errors all over the place

And don’t get me started on RabbitMQ's web dashboard randomly refusing to open sometimes 😵‍💫

💡 The Solution? One word: Docker 🐳

If you're even thinking about building microservices, learn Docker from Day 1.

Here’s what helped me stay sane:

Create a central docker-compose.yml file
Spin up all your services using a single command:


docker compose up -d

That’s it. Boom — Redis, RabbitMQ, API Gateway, all up and running. No more WSL drama. No more random port issues. No more service by service startup.

✅ What You Should Do

✅ Learn Docker (just enough to write a Dockerfile and docker-compose.yml)
✅ Treat every microservice as a container
✅ Never manually run Redis again
✅ Bonus: Set restart policies to make things auto-heal

Example:-

services:
  postgres:
    image: postgres:17.4
    ports:
      - "5433:5432"
    environment:
      POSTGRES_USER: user101
      POSTGRES_PASSWORD: pass101
      POSTGRES_DB: appointment
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:latest 
    ports:
      - "6380:6379"
    volumes:
      - redisdata:/data  

volumes:
    pgdata: 
    redisdata:

🚀 Closing Out: Your API Gateway Playbook

Hey, fellow dev! As someone knee-deep in microservices, I get how wild it can get. Here’s my straight-up plan to ace your API Gateway setup. Let’s roll! 💻

🛠️ 4 Steps to Nail It

Kick Off with Auth Service Build your Auth Service and test those JWTs till they’re rock-solid. No shortcuts! 🧪
Launch Your API Gateway Route frontend calls (/login, /register) through the Gateway to your Auth Service. Smooth flow, fam! 🌐
Lock Down JWTs
Drop middleware to verify JWTs and pass user info as headers:
```
`'x-user-id': user.userId,
'x-user-role': user.role`
```
Scale with More Services
Add services like Payment or Listings with a /ping route. Spot x-user-id and x-user-role in logs? You’re killing it! 🎉

🔧 Pro Tips

Level Up with Linux CLI: Hit up boot.dev for quick, backend-focused lessons. Command line swagger! 🖥️
Docker FTW: Whip up a docker-compose.yml to spin up Redis or PostgreSQL. Use named volumes to keep data safe. Start simple, scale later. 🐳

✌️ Final Vibes

You’ve wrestled the setup beast and won. Keep coding, logging, and shipping! If this sparked something, drop a like or share—it fuels the grind. Go own it! 🔥

How Social Media Handles Media Uploads: My Journey into Event-Driven Architecture

Prashant Swaroop — Wed, 28 May 2025 05:42:21 +0000

Introduction

Have you ever wondered what really happens when you upload a photo on an app like Instagram or LinkedIn?

You open the app, choose your image, and boom — you instantly see the photo on the screen. Then you add a caption, hit “Post,” and within seconds, your post is live. It feels instant. But... is it really?

Let’s pause for a second. Here’s the truth:

Your app isn't actually storing that image in a regular database. Images are heavy, and databases aren’t built to store them directly. Instead, apps use services like Cloudinary, Amazon S3, or Azure Blob Storage to store media. These services return a publicUrl and a publicId for each file.

Once the image is uploaded and the app gets this data, it then creates the post using the image URL, caption, and user details.

But here's the real brain-tickler:

When you upload a post, your image seems to appear immediately. Yet, uploading an image takes more time than saving a bit of text. So how come the post shows up so fast?

Is the image really uploaded instantly? Is your post created before the image is even fully processed?

These questions got me hooked. 🧠

So I did what any dev would do: stared at a whiteboard too long, grilled ChatGPT endlessly, and eventually... got it.

In this blog, I’ll walk you through my thought process, the options I considered, the trade-offs, and the final approach using RabbitMQ to simulate how real-world apps handle media uploads behind the scenes.

Trust me — this was fun to build, and I hope reading it will be just as fun. Let’s go! 🚀

Extreme Naive Solution 🫠 The Monolith Way (Easy Peasy)

Let’s start with the most straightforward approach — a good old monolith.

Here’s the plan:

We create a createPost function in our backend that accepts a caption and mediaUrls. Pretty standard, right?

Here's how it would go down:

The user uploads a photo.
On the backend, you hit Cloudinary (or S3, etc.) and await the upload response.
While the upload is in progress, the user can go ahead and write their caption.
Once you get the media URL back, boom! You now have everything to create the post — the caption and the image.

Seems simple enough. So what's the problem?

🪫 The Problem: It Feels Slow

You can't create the post until the image is uploaded. That means the user has to wait — and waiting = friction.

Even if it’s just 2-3 seconds, that’s enough to kill the “instant” vibe users are used to.

🧃 A Fake Instant Experience?

Sure, you could save the image temporarily in `localStorage` and show the user a preview — making it look like the upload was instant.

But here’s the catch:

You still don’t have the imageUrl from Cloudinary, so you can't actually create the post. That snappy UI? It’s just a mirage — a visual trick. Sooner or later, reality (and async logic) will catch up.

Verdict

This monolith-style approach works — but it’s not smooth.

You’re mixing concerns, delaying the response, and risking a poor UX. Not ideal for modern apps.

🚀 The Optimized Microservice Version

Before we dive in, here’s a quick recap:

In a microservice world, each core functionality — like auth (user identity), post (creating & managing posts), or media (uploading files) — runs as its own service on separate servers. Clean separation, clean scaling.

Let’s talk about one of the smarter ways to connect these services: webhooks.

🔹 Method 1: Webhooks — Trigger and Forget

What are webhooks?

Webhooks are a way for one service to notify another when something happens — without needing the caller to wait. It’s a decoupled pattern where, once an event is triggered, the sender can move on, and the listener handles it asynchronously.

Imagine this:

The media service finishes uploading a file
It automatically calls the post service’s webhook endpoint
The post service reacts — e.g., attaches the media ID to the post

Simple, elegant, and powerful — especially when you want to keep services loosely coupled.

⚖️ Tradeoffs

✅ Pros:

Decoupled communication – services don’t block or depend tightly on each other
Simple to implement – great for quick wins or small projects
Faster user experience – the client doesn’t wait for everything to finish

❌ Cons:

No built-in retry or buffering – if the post service is down, the webhook call is lost
Low fault tolerance – you'd have to manually implement retries, logging, or queuing
Doesn’t scale well – becomes harder to manage in larger systems

📌 Note:

I won’t go deeper into webhooks here — this article focuses more on RabbitMQ and event-driven architecture. But if this pattern interests you, it’s worth exploring further. Just know that while webhooks are great for simple use cases, they often fall short in production-grade, fault-tolerant systems — and that’s where queues truly shine.

🔹 Let’s Start With a Basic Question:

If services are hosted on different servers…

How do they talk to each other?

And even more importantly — why should they care to communicate at all?

Let’s take a real-world example:

Imagine you just created a new post on a social media app.

To improve performance, the app might use caching to store recent posts — so users see fresh content fast.

Now here’s the problem:

When your post gets created, how does the search or feed service (hosted elsewhere) know that the cached posts are outdated?

You need to tell it:

“Hey, someone just posted something new. Please update the feed!”

You could fire a POST request from one service to another. But…

What if the other service is down?
What if you need to tell multiple services?
What if this direct communication makes your system fragile and tightly coupled?

That’s where simple API calls fall apart. You need something better.

💡 What You Need Instead: A Message Broker

Think of a message broker like RabbitMQ as a reliable postman 📨

It takes a message from one service (like NEW_POST_CREATED)
Delivers it to all the services that care (like feed, search, analytics)
It can retry, queue, and decouple services cleanly

This is exactly how modern systems communicate — using events, queues, and publish-subscribe patterns.

How RabbitMQ Works:

Let’s briefly understand the 4 key components in RabbitMQ using a real-world example:

🔹 Publisher

The service that sends the event.

📌 Example: Media service publishes an event after an image is uploaded successfully.

🔹 Event = Message + Payload

The event is the actual data being sent through RabbitMQ.

It’s made of:

Message: A string identifier like 'media.success' to indicate what kind of event it is.
Payload: The actual data sent (e.g. draftId, mediaId, publicUrl, userId).

🔹 Channel (aka Queue)

Think of a channel like a pipe or named queue that connects publishers and subscribers.

We name channels to distinguish different event types or workflows.

The channel is responsible for carrying the event from the publisher to one or more subscribers.

🔹 Subscriber (aka Consumer)

A service that listens to a specific message on a specific channel.

It only acts on relevant events — filtered by message type.

📌 Example: The Post service listens for media.success and updates the post with the image URL once it receives the event.

✅ Summary of Your Key Idea:

“A message is an identifier. An event is the combination of message + payload. A channel is a named pipe that carries the event, and a subscriber listens for only relevant messages to act upon.”

🧰 Method 2: Real-World Media Uploads Using RabbitMQ

Now that you know:

How microservices communicate
Why they need to communicate
What a message broker is
How RabbitMQ works...

Let’s see how it all comes together in a real-world app.

🖼️ Flow: Uploading Media with RabbitMQ

Here’s how media uploads work using event-driven communication:

User uploads an image → it hits the Media Service.
The image uploads in the background while the user writes the caption.
We allow the user to hit "Post" — even if media upload isn’t complete yet.
The Post Service stores this post in draft state.
Once the media upload finishes, Media Service publishes an event: media.success.
The Post Service (subscriber) listens for this event.
It updates the corresponding draft post with mediaId and mediaUrl.
The post is marked live and the user is notified.
✅ All of this happens asynchronously, using **draftId** as a shared link between the services.

🌟 Why This Works Well

⚡ Fast user experience (no waiting on uploads)
🔁 Async & fault-tolerant
🧱 Decoupled, scalable, and clean architecture

⚖️ Pros and Cons of Using RabbitMQ

So far, RabbitMQ seems magical — but like every tool, it has trade-offs. Let’s break them down:

✅ Pros

Loose Coupling Between Services
- Services don’t need to know about each other — just publish or subscribe to events. This makes scaling and updating easier.
Asynchronous Processing = Faster User Experience
- Offloading tasks like image processing or sending emails to background jobs keeps your app snappy for users.
Reliable Delivery
- RabbitMQ uses message acknowledgments and persistence, meaning messages won’t just disappear if something crashes mid-process.
Scalable Architecture
- Want to process 1,000 images at once? Just scale up consumers. RabbitMQ helps decouple load from user interaction.
Retry and Dead Letter Queues (DLQs)
- If something goes wrong, failed messages can be retried or moved to a DLQ for debugging later. You don’t lose important events.

⚠️ Cons

Increased Complexity
- Now you’re managing RabbitMQ itself, plus writing consumers, handling retries, and monitoring failures. More moving parts = more things to maintain.
Operational Overhead
- RabbitMQ is another service to deploy, secure, and monitor. You'll need alerting in place for failures, queue backlogs, or memory issues.
Harder Debugging
- With async behavior, bugs can feel like ghosts. Tracing an error from post creation → media upload → queue → consumer can get tricky.
Potential Message Loss
- If not configured properly (e.g., queues not durable, no acknowledgments), you can lose messages on crashes or reboots.
Latency (Sometimes)
- Although async improves UX, the actual task (like showing the uploaded image) might take longer to fully process compared to inline logic.

🧯 What If RabbitMQ Goes Down?

Good question.

Publish Fails? Your service should catch the error and either retry or log it for a retry job later.
Consumer Crashes? Messages stay in the queue until a consumer comes back online.
Broker Crash? If queues aren’t marked as durable, messages may be lost. Always enable durability for production queues.
DLQ (Dead Letter Queue): Failed messages can be routed to a special queue for investigation instead of being lost or retried endlessly.

💡 Tip: Use monitoring tools like Prometheus + Grafana or RabbitMQ's built-in dashboard to keep tabs on queues, consumers, and delivery rates.

TALK IS CHEAP SHOW ME THE CODE AND EXPLAIN

Boiler plate code

Here's a simple boilerplate setup to use RabbitMQ in a Node.js app.
It includes functions to connect, publish, and consume events using a topic exchange

connectToRabbitMq() this function is straightforward just connects to RabbitMQ and create a channel named after const EXCHANGE_NAME = 'FACEBOOK_EVENTS'.

publishEvent(routingKey, message) this publishes message to routingKey.

function consumeEvent(routingKey, callback)

The consumeEvent function allows a service to listen for a specific event. It sets up a temporary queue, binds it to the correct routing key, and then starts consuming messages. Every time a new message arrives, it runs your callback function and tells RabbitMQ that the message was handled successfully using channel.ack()

import ampqlib from "amqplib" // nodejs library to work with rabbitmq
import logger from "./logger.js"
import dotenv from "dotenv"

dotenv.config();

let channel = null
let connection = null

console.log(process.env.RABBITMQ_URL)

const EXCHANGE_NAME = 'FACEBOOK_EVENTS'

// code to connect with rabbitMq with a spacified channel name

async function connectToRabbitMq() {
    try {
        connection = await ampqlib.connect(process.env.RABBITMQ_URL);
        channel = await connection.createChannel()
        await channel.assertExchange(EXCHANGE_NAME,"topic",{durable:false})
        logger.info("Connected to rabbit mq");
        return channel
    } catch (error) {
        logger.error("Error connecting to rabbit mq", error);

    }
}

// function to publish a message
// the routingKey is identifier which will be passed for ex. 'media.success'

async function publishEvent(routingKey, message) {
    console.log("ROUTING KEY RECEIVED:", routingKey);// used for debugging 
    console.log("IS STRING?", typeof routingKey);
    logger.info("key: ", routingKey)
if(!channel){
    await connectToRabbitMq();
    // if not connected connect to rabbitMq 
}

// once conncected publish the message with routing key and message.

channel.publish(EXCHANGE_NAME, routingKey, Buffer.from(JSON.stringify(message)))

logger.info("Event Published at", routingKey);

}

// Function to subscribe to a specific event (routingKey)
// Whenever a message with that key is published, this function will call the provided callback

async function consumeEvent(routingKey, callback) {
    // If not connected to RabbitMQ yet, connect first
    if (!channel) {
        await connectToRabbitMq();
    }

    // Create a temporary exclusive queue just for this consumer
    const q = await channel.assertQueue("", { exclusive: true });

    // Bind this queue to the exchange using the routingKey
    // So only messages with that routingKey will go to this queue
    await channel.bindQueue(q.queue, EXCHANGE_NAME, routingKey);

    // Start listening to the queue for incoming messages
    channel.consume(q.queue, (msg) => {
        if (msg !== null) {
            // Parse the message from Buffer to JSON
            const content = JSON.parse(msg.content.toString());

            // Call the user-provided callback function with the message content
            callback(content);

            // Acknowledge the message (let RabbitMQ know it was processed successfully)
            channel.ack(msg);
        }
    });

    // Log what we're subscribed to
    logger.info(`Subscribed to event '${routingKey}' from exchange '${EXCHANGE_NAME}'`);
}

export  {connectToRabbitMq, publishEvent, consumeEvent}

Media Controller Publishing Messages Code:-

const uploadMedia = async(req, res)=>{
    logger.info("Starting media upload");

    try {

        if(!req.file){
            logger.error("No file found. Add a file and try again.")
            return res.status(400).json({
                success:false,
                message:"No file found. Please add a file and try again."
            })
        }

        const {originalname, mimetype, buffer} = req.file

        const userId = req.user; // userId for authenticated users

        const {draftId} = req.body;

        logger.info(`File details: name=${originalname}, type=${mimetype}`);
        logger.info("upload to cloudinary started")

        const cloudinaryUploadResult = await uploadMediaToCloudinary(req.file);
        logger.info(`Cloudinary Upload successfully. Public Id ${cloudinaryUploadResult.public_id}`)

        const newlyCreatedMedia = new Media({
           publicId: cloudinaryUploadResult.public_id,
           originalName:originalname,
           mimeType:mimetype,
           url: cloudinaryUploadResult.secure_url,
           userId
        })

        await newlyCreatedMedia.save();
        // added this to test the automated post updation with mediaIds
        await publishEvent("media.success", {
            draftId: draftId,
            publicUrl: newlyCreatedMedia.url,
            userId:userId,
            mediaId: newlyCreatedMedia._id
        })

        res.json({
            success:true,
            mediaId:newlyCreatedMedia._id,
            url: newlyCreatedMedia.url,
            message:"Media Upload is successful"
        })

    } catch (error) {
        logger.error("Error happend while uploading.", error)

        res.status(500).json({
            success:false,
            message:"Internal Server Error Happend At Our Side"
        })

    }

}

Post Service Consuming message `"media.success"`

async function startServer(){
    try {
        await connectToRabbitMq();
        await consumeEvent("media.success",updatePostWithMedia)
        app.listen(PORT, ()=>{
            logger.info(`Post service started listening on port ${PORT}`);
        })
    } catch (error) {
        logger.error("Failed to connect to server")
        process.exit(1)
    }
}
startServer();

finally handling post update with function `updatePostWithMedia`

import logger from "../utils/logger.js";
import Post from "../model/post.js";

async function updatePostWithMedia(event) {
    logger.info(`updatePost is intialized for event ${event}`);

    try {

        console.log("event", event)
        const findPostWithDraftId = await Post.find({draftId: event.draftId})

        if(!findPostWithDraftId){
            logger.warn(`No post could be found associated: ${event.draftId}`);
            return
        }

       const updatedPostDetails =  await Post.findOneAndUpdate({draftId:event.draftId}, {$set:{mediaIds:[event.mediaId]}}, {new:true})

       logger.info(`Updated post is: ${updatedPostDetails}`)

    } catch (error) {
        logger.error(`Error happend while updating post with draftId: ${event?.draftId}`)
    }

}

export default updatePostWithMedia;

💫 Wrapping Up

Building this mini real-world social media app has been nothing short of fun, frustrating, and absolutely worth it.

You only truly appreciate RabbitMQ when you see your database update itself without you lifting a finger. That first time it works? You will jump out of your seat and yell: "Yo, it’s actually working!"

That’s the magic of event-driven architecture.

And once you feel it — not just understand it — you're hooked.

So go ahead: take the concepts here, clone the repo, and mess with the code.

Trigger new events. Chain them. Break things. Fix them.

You'll start falling in love with backend systems, architecture patterns, and this beautiful chaos called event-driven programming.

And hey — don’t just build to get it done or pad your resume.

Live a little.

Mess with code.
Weep.
Cry.
Fix it.
Take pride.

😩 I once debugged a RabbitMQ event flow for three hours — turned out it was a typo.

Was I mad? Sure.

Was I proud? Absolutely.

Much love and peace to all who made it this far.

I’ll drop the GitHub link below — fork it, break your localhost, make it better.

Peace out. 💻🔥

https://github.com/PRASHANTSWAROOP001/Social-Media-Microservice

https://documenter.getpostman.com/view/38176982/2sB2qUmjeV

How I Built A Secure, Anonymous Feedback Platform From Scratch

Prashant Swaroop — Fri, 09 May 2025 16:09:45 +0000

Motivation and Need

We've all experienced institutions — colleges, companies, organizations — where management collects feedback.

But when it comes to submitting complaints, the process often feels tedious, intimidating, or unclear.

Sometimes it's so complicated that people just give up.

Even if you do manage to submit a complaint, there's no guarantee you won’t face backlash from the administration or individuals involved.

⚡ I wanted to solve this.

I wanted to make a transparent and safe feedback process where:

The admin can invite people to submit feedback or complaints,
But the identity of the user remains hidden,
Ensuring honest feedback without fear.

Thus, I built an Anonymous Feedback Backend system.

Current Mechanism

From what I’ve seen, feedback is often collected using tools like Google Forms.

At first glance, this seems convenient.

But if you look deeper, it’s actually flawed — and here’s why:

Most forms collect your email automatically.
Every feedback you submit gets tied to your email.
Emails are deeply personal — they can be used to identify you easily.

This completely defeats the purpose of honest feedback.

If users know their identity could be revealed —

they will hesitate, filter their words, or worse, stay silent.

And beyond identification, there’s another hidden problem:

There’s no other proper way to verify that the feedback is authentic without collecting personal data.

This is the gap I wanted to fix.

Building a system that ensures:

Only invited users can submit feedback,
But their identity stays completely hidden,
Enabling true, fearless feedback.

My Solution

I built an app that tries to fill this gap.

Let’s quickly walk through how it works:

As usual, an admin creates an account.
Then, the admin creates topics — each with a title and description — for which they want to collect feedback.
Now, the admin uploads user details (name, email, and topicId — which is visible on the frontend).
After the emails are uploaded, a token is generated for each user.

This token is used for verification but is not associated with your email inside the system.
Users receive the token on their email.

When they want to submit feedback, they must enter both their email and the token.
Once verified, users can safely submit feedback anonymously.

Note:

The email is only used once — just to verify that you actually received the invitation.

When submitting feedback, only the token is sent — no personal email data is stored or exposed.

#Relax 😌

Er Diagram

How the Database Design Protects User Privacy

Let's begin with how feedback is only tied to the topic table.

In the feedback table, you can clearly see that no personal data like user email is stored.

Admins can view submitted feedbacks using only the topicId and their own adminId. Beyond that, there is no way to trace which email submitted which feedback.

Challenges:

Challenge 1: Validating legitimate users without storing personal data

To solve this, we require the user to submit both their email and token when giving feedback.

The EmailTopics table validates whether this email was invited for that topic.
The token is unique and tied to a specific topicId. It allows us to authorize feedback submissions without exposing personal user info.

Challenge 2: Supporting multiple feedback invitations for the same user

One user may be invited to submit feedback on multiple topics.

To support this, we designed a one-to-many relationship:
- One email → Many topics (EmailTopics table)
- One topic → Many emails (EmailTopics table)

Thus, this approach balances admin control, user privacy, and flexibility.

How Feedback Submission Works Under the Hood

We use both email and token to validate each end user during feedback submission.

Email helps us verify whether the user was actually invited to submit feedback.
Token helps us validate multiple things:
- Whether the token is valid and exists.
- Whether it is tied to a specific topicId.
- Whether the topic still exists (it could have been deleted by the admin midway).
- Whether the user has already submitted feedback (if yes, they won't be allowed to submit again).

This dual validation ensures feedback submissions are secure, one-time, and tied only to authorized users, without storing any personal information inside the feedback itself.

const loginUsingToken = async (req: Request, res: Response):Promise<void> => {
    try {
      const { email, token } = userLoginSchema.parse(req.body);

      const [searchEmail, searchToken] = await Promise.all([
        prisma.email.findUnique({ where: { email } }),
        prisma.token.findUnique({ where: { token } }),
      ]);

      if (!searchEmail || !searchToken) {
         res.status(400).json({
          success: false,
          message: "Auth failure against token and email provided.",
        });
        return;
      }

      // Check token expiry
      if (new Date() > searchToken.expiresAt) {
        res.status(409).json({
          success: false,
          message: "We are no longer accepting feedback. Feedback time is over.",
        });
        return;
      }

      // Check if token is used
      if (searchToken.isUsed) {
        res.status(409).json({
          success: false,
          message: "Token has already been used to submit feedback.",
        });
        return;
      }

      // Check if email is associated with the topic from token
      const isAssociated = await prisma.email.findFirst({
        where: {
          id: searchEmail.id,
          topics: {
            some: { id: searchToken.topicId },
          },
        },
      });

      if (!isAssociated) {
        res.status(401).json({
          success: false,
          message: "You are not allowed to submit feedback to this topic.",
        });
        return;
      }

      // All good
       res.json({
        success: true,
        message: "Logged in successfully",
        tokenId: searchToken.id,
        topicId: searchToken.topicId,
      });

    } catch (error) {
      console.error("Error during token login:", error);

      if (error instanceof Prisma.PrismaClientKnownRequestError) {
         res.status(500).json({
          success: false,
          message: "Internal server error happened at our side (DB)",
        });

        return;
      }

      res.status(500).json({
        success: false,
        message: "Internal server error happened at our side.",
      });

      return;
    }
  };

Mistakes I Made in v0

I totally forgot to add a logout route for the admin.

(The only way out was letting the JWT expire — not a great thing to do, apparently.)
I created three separate routes:
1. Uploading emails
2. Generating tokens
3. Sending emails
  
  This created a lot of friction for the end users, who now had to make too many decisions manually.
I was using memory storage for processing uploaded CSV files.

This was not scalable — I should have used a blob or file service.

Since I was saving uploads to a local /uploads folder, it broke in deployment (because cloud servers have temporary file storage that often resets or errors out).
Looking back...

This gives me chills — a lot of rookie mistakes were made here.

What I Fixed in v1

For the auth system — I didn’t just create a logout endpoint.

I went beyond expectations. (Not just flexing, it’s the real deal, brahh. 😎)
I built a full authentication system with:
- Refresh Tokens
- Session Management
- IP and device tracking
- Expiry tracking for each session
- Secure storage of refresh tokens inside **HttpOnly cookies**.
On logout, we now clear the refresh token (mark it revoked), terminate the session, and save when/where/how it was terminated.

This makes the auth system robust, secure, and modern in every sense.

About the endpoints problem:

I reduced three endpoints to just two.

I automated two flows and merged them together.

Again, went a bit beyond normal expectations.

I used transactions to merge uploading emails and generating tokens into a single atomic operation.

Now it’s automated, more robust, and error-resistant

For the storage problem:

I stopped using disk storage.
I used memory storage instead.
Once the file is available in RAM, we parse it directly from buffers and send all the email data using a middleware function — no more temp files!

✅ This made the whole system faster, more scalable, and ready for real-world deployment.

Talk Is Cheap Show me the code PRASHANT you flex too much we shall see your code 🤔

Logout endpoint code

const logoutAdmin = async (req:Request, res:Response)=>{

  try {

    const refreshToken = req.cookies.refreshToken;

    if(!refreshToken){
      res.status(400).json({
        success:false,
        message:"No refresh cookie could be found"
      })

      return;
    }

    const validateRefreshToken = await prisma.refreshToken.findUnique({
      where:{
        id:refreshToken
      }
    })

    if(!validateRefreshToken){
      res.status(400).json({
        success:false,
        message:"Invalid refresh token!"
      })
      return;
    }
    else if(validateRefreshToken.revoked == true ||validateRefreshToken.expiresAt <= new Date()){
      res.status(400).json({
        success:false,
        message:"Expired or already used refresh tokens"
      })

      return;
    }

    await prisma.refreshToken.update({where:{id:validateRefreshToken.id}, data:{revoked:true}})

    await prisma.session.update({where:{refreshToken:validateRefreshToken.id}, data:{revoked:true, revokedAt: new Date()}})

    res.clearCookie("refreshToken")

    res.json({
      success:true,
      message:"Logged out successfully"
    })

  } catch (error) {
    console.error("Error happened while logging out", error)
    res.status(500).json({
      success:false,
      message:"Internal server error"
    })

  }

}

🔄 Refresh Access Token Endpoint

Since my access tokens are short-lived (for better security),

I built a refresh access token endpoint to allow users (admins) to stay logged in without forcing them to sign in again and again.

Just to be honest — I added this because I felt like it 😎 — but also because real-world auth flows need this for a good user experience.

This endpoint checks the refresh token (securely stored in HttpOnly cookies),

verifies it, and issues a new access token without touching the user session unnecessarily.

It's a small addition but it makes the auth system feel buttery smooth.

const renewAccessToken = async (req:Request, res:Response)=>{
  try {

    const refreshToken = req.cookies.refreshToken;

    if(!refreshToken){
      res.status(400).json({
        success:false,
        message:"Refresh Token in unavailable"
      })
      return;
    }

    const validateRefreshToken = await prisma.refreshToken.findUnique({
      where:{
        id:refreshToken
      }
    })

    if(!validateRefreshToken){
      res.status(400).json({
        success:false,
        message:"Invalid refresh token!"
      })
      return;
    }
    else if(validateRefreshToken.revoked == true ||validateRefreshToken.expiresAt <= new Date()){
      res.status(400).json({
        success:false,
        message:"Expired or already used refresh tokens. Please login again."
      })
      return;
    }

    const adminDetails = await prisma.admin.findUnique({
      where:{
        id:validateRefreshToken.adminId
      }
    })

    const accessToken = jwt.sign(
      {
        name: adminDetails?.name,
        id: validateRefreshToken.adminId,
        email: adminDetails?.email,
      },
      JWT_SECRET,
      {
        algorithm: "HS256",
        issuer: "ADMIN",
        expiresIn: "15m",
      }
    );

    res.json({
      success:true,
      message:"Token generated successfully",
      accessToken
    })


  } catch (error) {

    console.error("Error happened while refreshing access token", error);

    res.status(500).json({
      success:false,
      message:"Internal server error happened at our end"
    })

  }
}

Finally, the best thing — saved for last:

I love the Prisma developers from the bottom of my heart.

They made atomicity and transactions come to life with such simple syntax.

I literally jumped out of my chair when I got my transaction code working for the first time! 😄

Until now, I had only heard about rollback, atomicity, and consistency...

but implementing it myself felt absolutely surreal.

Big corporations use transactions to power things like UPI payments, net banking, and huge financial systems.

And today, my small little app uses it too. ✨

Enough talk — here’s the code.

Go ahead, implement it yourself.

Fall in love with the beauty of low-level programming. 🚀

const saveEmails = async (req:RequestWithPayload, res:Response)=>{
    try {

        const id:number = req.user?.id!

        const topicId = req.params.id; // to create and save tokens 

        if(!topicId){
            res.status(400).json({
                success:false,
                message:"To send emails in next process. it needs topicId as params."
            })
        }

        const emailsWithTopics = req.emailsWithTopics

        console.log(emailsWithTopics, "email with topics")

        const dataToInsert = (req.emailsWithTopics ?? []).map(entry => ({
            name: entry.name || null,
            email: entry.email,
            topicId: parseInt(entry.topicId),
            adminId: id,
        }))

// Main Part 
        await prisma.$transaction(async(tx)=>{

            for (const entry of dataToInsert){
               const email = await tx.email.upsert({
                    where:{
                        email: entry.email
                    },
                    update:{
                        name:entry.name
                    },
                    create:{
                        email:entry.email,
                        name:entry.name,
                        admin: {connect: {id: entry.adminId}} //adminId:entry.adminId
                    }
                })
// first we saved each emails 
// now we update each emails so that it can be associated with topics 
                await tx.email.update({
                    where:{
                        id:email.id
                    },
                    data:{
                        topics: {connect: {id: parseInt(topicId)}}
                    }
                })
            }

            const emailCount = await tx.email.count({
                where:{
                    topics:{
                        some:{
                            id: parseInt(topicId)
                        }
                    }
                }
            })
            // we counted no of emails created/saved now will generate unique token for this


            // generateTokens against emails
            const nTokens = await createNToken(emailCount);

            // mapout tokens to save in database
            const tokenToInsert = nTokens.map((val)=>({
                token:val,
                topicId:parseInt(topicId),
                expiresAt:new Date(Date.now() + 7 * 24 * 60 * 60 * 1000)
            }))

            // save tokens to database

            await tx.token.createMany({
                data: tokenToInsert,
            })

            // finally end of transaction.
        })

        res.status(200).json({
            success:true,
            message:"Emails and Tokens are successfully added to database 🥳"
        })


    } catch (error) {

        console.error("Error happened at processing transaction 😔", error);
        res.status(500).json({
            success:false,
            message:"Internal server error"
        })

        return;

    }
}

🎤🎙️End

This is why we build.

This is why we code.

This is why we fall in love with tech.

I have add GitHub link and postman link, go fork it make it bad ,ugly mess, weep, cry fix it.

GitHub Link:-https://github.com/PRASHANTSWAROOP001/-Anonymous-Feedback-System

Postman Link:- https://documenter.getpostman.com/view/38176982/2sB2j1gXe1