DEV Community: Shivam

Building Real-Time Group Chat with Redis Streams and SSE in Next.js

Shivam — Mon, 18 May 2026 20:59:19 +0000

One of the features we’re most proud of at Fledgr is Circles — real-time campus group chats designed to feel instant without relying on traditional WebSockets.

Getting there was a lot less straightforward than we expected.

Why We Didn’t Use WebSockets

At first, WebSockets seemed like the obvious choice.

The problem is deployment constraints.

Since Fledgr runs on Vercel, persistent WebSocket connections inside serverless functions aren’t really an option. You either introduce a separate socket infrastructure or work within the platform’s limits.

We chose the second route.

Instead of WebSockets, we built the real-time layer using Server-Sent Events (SSE).

SSE is essentially a long-lived HTTP response where the server continuously streams updates while the client listens using the browser’s native EventSource API.

It’s unidirectional, which works perfectly for chat message delivery:

Messages are streamed from server → client
Sending messages still happens through normal POST requests

Simple architecture. Fewer moving parts.

At least in theory.

The 60-Second Problem on Vercel

The first issue showed up immediately.

Vercel serverless functions time out after roughly 60 seconds.

That means your SSE stream gets terminated every single minute.

For a real-time chat system, that’s obviously a problem.

The mistake would’ve been trying to “fight” the platform.

Instead, we designed around the limitation.

Designing Around Forced Disconnects

Rather than waiting for Vercel to kill the connection unexpectedly, we close the SSE stream ourselves after ~55 seconds.

The browser automatically reconnects using EventSource, usually within a second or two.

On reconnect, the client sends the last received message ID, and the server resumes streaming from that point forward.

The result:

No visible interruptions
No dropped messages
No manual reconnect logic on the client
Reconnection feels invisible to users

Once we stopped treating reconnects as failures and started treating them as part of the architecture, the system became much simpler.

Why We Chose Redis Streams Instead of Pub/Sub

The backend streaming layer uses Redis Streams with XREAD.

We specifically avoided Redis Pub/Sub for one reason:

Reconnection safety.

Pub/Sub is fire-and-forget.

If a client disconnects for even a moment, any messages sent during that gap are permanently lost.

That doesn’t work well with SSE reconnect behavior.

Redis Streams solve this cleanly because clients can reconnect using the last processed message ID and continue reading from where they left off.

```txt id="pw1jlwm"
XREAD STREAMS circle:messages




That tiny detail ended up being one of the most important architectural decisions in the system.

---

## Stream Persistence Strategy

We don’t use Redis as permanent message storage.

Messages are still written to the main database.

Redis Streams only exist as the real-time transport layer.

Because of that, we aggressively cap stream lengths and let Redis automatically trim older entries.



```txt id="rk5q3sj"
MAXLEN ~ 1000

This keeps memory usage predictable while still giving reconnecting clients enough history to catch up safely.

What We’d Probably Do Differently

If we weren’t on Vercel, we’d probably use WebSockets.

The SSE + reconnect pattern works surprisingly well, but it introduces complexity that native socket infrastructure simply avoids.

A lot of architectural decisions end up being shaped around the 60-second execution ceiling:

Reconnect handling
Message replay
Stream resumption
Client synchronization

Those aren’t impossible problems, but they’re problems you wouldn’t normally choose to have.

Final Thoughts

That said, this setup has been extremely solid for us in production at Fledgr.

Circles now supports real-time campus conversations without running a dedicated socket server or maintaining separate infrastructure outside Vercel.

If you’re building on Vercel and need real-time features without introducing WebSocket infrastructure, this pattern is absolutely viable.

It’s not the most obvious solution — but under real-world constraints, it ended up being one of the most reliable ones we found.

CSRF Protection That Actually Works in a Next.js 16 + React 19 App

Shivam — Mon, 18 May 2026 20:57:45 +0000

When we were building Fledgr, CSRF protection was one of those areas where most advice felt either outdated or unnecessarily complicated.

A lot of apps either:

Rely entirely on SameSite cookies
Add a heavy CSRF library without understanding what it’s doing
Or skip protection altogether because “modern browsers already handle it”

None of those approaches felt great to us.

So we ended up implementing a lightweight CSRF layer that’s now used across every state-mutating route in production.

Why `SameSite` Alone Isn’t Enough

SameSite=Strict definitely helps.

It prevents cookies from being attached to most cross-site requests, which blocks a large class of CSRF attacks automatically.

But relying on it alone has a few problems:

Browser behavior can vary
Redirect edge cases still exist
Many frameworks default to SameSite=Lax
Lax still allows cookies on top-level navigations

So while SameSite is an important security layer, we never treated it as the entire solution.

The Pattern We Use: Double-Submit Cookies

The approach we settled on is the classic double-submit cookie pattern.

The flow is simple:

Generate a CSRF token server-side
Store it in a cookie
Require every POST, PUT, PATCH, and DELETE request to include the same token in a custom header
Verify both values match on the server

```ts id="vkwx9v"
const headerToken = request.headers.get("x-csrf-token");
const cookieToken = cookies().get("csrf_token")?.value;

if (!headerToken || headerToken !== cookieToken) {
return Response.json(
{ error: "Invalid request" },
{ status: 403 }
);
}




The important detail here is the security boundary.

A malicious site can sometimes trigger a request that includes cookies automatically.

What it *can’t* do is read the CSRF cookie and inject its value into a custom header.

That separation is what makes the pattern effective.

---

## Centralising Protection with `withApi()`

One thing we wanted to avoid was developers forgetting to add CSRF checks on new routes.

So instead of manually verifying tokens everywhere, we moved the logic into a shared wrapper we call `withApi()`.

Every state-mutating route passes through it automatically.

The wrapper handles:

* CSRF verification
* Authentication resolution
* Rate limiting
* Error formatting
* Request validation

That means new endpoints are protected by default rather than depending on memory or code review.

---

## Never Use Raw `fetch()` on the Client

Another lesson we learned pretty quickly:

If developers can call raw `fetch()` directly, CSRF headers eventually become inconsistent.

Someone forgets the header.
A helper gets bypassed.
A new feature ships without protection.

So we wrapped `fetch()` inside a single client utility that automatically:

* Reads the CSRF token from the cookie
* Injects the `x-csrf-token` header
* Applies shared defaults

That utility is now the only allowed way to make authenticated API requests inside the app.

One function.
Used everywhere.
No exceptions.

---

## Why the CSRF Cookie Isn’t `HttpOnly`

This usually surprises people.

The CSRF cookie needs to be readable by JavaScript so the client utility can inject it into request headers.

That means the cookie cannot be `HttpOnly`.

This is intentional.

The security model here isn’t about hiding the token from JavaScript — it’s about preventing *cross-origin attackers* from reading it.

We also set the CSRF cookie to:



```txt id="u7n3xy"
SameSite=Strict
Secure

That gives us another protection layer on top of header validation.

What This Catches in Practice

The interesting part is that this setup has already caught several mistakes during development.

Missing headers.
Incorrect client integrations.
Routes accidentally bypassing wrappers.

Without CSRF validation, some of those mistakes could have become production vulnerabilities.

Instead, requests fail immediately and visibly during development.

Final Thoughts

CSRF protection doesn’t need to be complicated, but it does need to be deliberate.

For us, the winning combination ended up being:

Double-submit cookies
Strict cookie settings
Centralised route wrappers
A single API client utility
Zero direct fetch() usage for authenticated requests

It’s lightweight, easy to reason about, and fits naturally into a modern Next.js 16 + React 19 stack.

We’ve been running this approach across Fledgr in production, and so far it’s proven both reliable and hard to misuse — which is exactly what good security infrastructure should be.

How We Handle Encrypted Database Fields in a Next.js App

Shivam — Mon, 18 May 2026 20:54:16 +0000

When we started building Fledgr, we knew pretty early that some data needed stronger protection than a locked-down database alone could provide.

Things like:

UPI IDs
Placement package figures
Anonymous post content

If a database dump ever leaked, we didn’t want sensitive information sitting there in readable form.

That led us to implement field-level encryption.

The Core Idea

Instead of using one static encryption key everywhere, we derive a unique key per field using HKDF.

That means the encryption key for a user's UPI ID is cryptographically separate from the key used for placement data or anonymous content — even though they all originate from the same master secret.

Every sensitive field gets its own context string:

db:users:upiId
db:placements:package
anon:posts:2025-01-15

The nice part is that we never store these derived keys. They’re generated only when needed.

Encryption Flow

export function encrypt(value: string, context: string): string {
  const key = deriveKey(context);
  const iv = randomBytes(12);

  const cipher = createCipheriv("aes-256-gcm", key, iv);

  const encrypted = Buffer.concat([
    cipher.update(value, "utf8"),
    cipher.final(),
  ]);

  const tag = cipher.getAuthTag();

  return Buffer.concat([iv, tag, encrypted]).toString("base64");
}

We use:

AES-256-GCM for authenticated encryption
Random 12-byte IVs
HKDF-derived contextual keys

This keeps encryption isolated across different parts of the system.

Handling Old Plaintext Data

Rolling out encryption in production usually means dealing with legacy rows that were stored before encryption existed.

We didn’t want migrations causing crashes or corrupting data, so every decrypt operation goes through a safe wrapper.

If decryption fails, we simply return the original value instead of throwing an error.

That allowed us to gradually migrate older data without downtime or breaking existing records.

Querying Encrypted Fields

One challenge with encrypted data is querying it.

You can’t directly run WHERE email = ... against encrypted values because encryption output changes every time.

To solve that, we use blind indexes.

For searchable fields like college emails, we store:

The encrypted value
A separate HMAC-based hash column

All lookup queries run against the hash instead of the encrypted field itself.

email_hash = HMAC_SHA256(email)

The actual encrypted value is never used inside query conditions.

What This Actually Protects Against

Field-level encryption is not a replacement for proper secret management.

If the master secret leaks, everything downstream is compromised too.

But that wasn’t the primary threat model we were solving for.

The goal was protecting against database-level exposure:

Misconfigured backups
Leaked database dumps
Overprivileged read replicas
Snapshot exposure
Internal read-only access gone wrong

Those are realistic risks for modern applications, and field-level encryption helps reduce the blast radius significantly.

Performance Impact

We’ve been running this setup in production at Fledgr with almost no noticeable overhead.

The derive-on-demand approach is lightweight enough that users never feel it, while still giving us much stronger isolation for sensitive data.

For us, it ended up being one of those rare security improvements that added meaningful protection without making development harder.

DEV Community: Shivam

Building Real-Time Group Chat with Redis Streams and SSE in Next.js

Why We Didn’t Use WebSockets

The 60-Second Problem on Vercel

Designing Around Forced Disconnects

Why We Chose Redis Streams Instead of Pub/Sub

Reconnection safety.

What We’d Probably Do Differently

Final Thoughts

CSRF Protection That Actually Works in a Next.js 16 + React 19 App

Why SameSite Alone Isn’t Enough

The Pattern We Use: Double-Submit Cookies

What This Catches in Practice

Final Thoughts

How We Handle Encrypted Database Fields in a Next.js App

The Core Idea

Encryption Flow

Handling Old Plaintext Data

Querying Encrypted Fields

What This Actually Protects Against

Performance Impact

Why `SameSite` Alone Isn’t Enough