DEV Community: Bharath Kumar

How I Replaced react-calendar with a Timezone-Safe UnifiedDatePicker in a Production OSS Codebase

Bharath Kumar — Sat, 23 May 2026 05:25:45 +0000

How I Replaced react-calendar with a Timezone-Safe UnifiedDatePicker in a Production OSS Codebase

A deep dive into adapter patterns, UTC boundary semantics, and the surprisingly subtle bugs that live inside date pickers.

The Setup

Formbricks is an open-source survey and experience management platform built on Next.js. The codebase had accumulated multiple date picker implementations over time:

A legacy react-calendar component wrapped in a custom DatePicker
Two separate react-day-picker v9 implementations in different parts of the app
Native <input type="date"> elements scattered across the contacts and segments UI

Each one handled dates differently. None of them handled timezones correctly.

Issue #7774 asked for a single unified component. This is the story of building it.

The Problem: Two Separate Bugs, One Root Cause

Before writing any code, I audited every existing date picker call site. Two patterns kept appearing.

Bug 1: new Date(string) in onChange handlers

// In attribute-field-row.tsx (before)
onChange={(e) => {
  const dateValue = e.target.value ? new Date(e.target.value).toISOString() : "";
  valueField.onChange(dateValue);
}}

When a user in IST (UTC+5:30) types 2024-05-20 into a native date input, the browser parses it as 2024-05-20T00:00:00+05:30. Calling .toISOString() converts that to 2024-05-19T18:30:00.000Z. The stored value is May 19th. The user selected May 20th.

Bug 2: The custom range picker used setHours instead of UTC

// In CustomFilter.tsx (before)
const startOfRange = new Date(date);
startOfRange.setHours(0, 0, 0, 0); // local midnight, not UTC midnight

setHours operates in local time. For a user in IST, "midnight" is UTC-5:30, meaning the stored start-of-day is 18:30:00Z the previous day. Every range query was silently off.

Both bugs share the same root cause: implicit reliance on local timezone behavior in a system where dates are stored and queried in UTC.

The Architecture Decision: An Adapter Layer

The fix isn't just replacing the components. It's establishing a single boundary where date values enter and leave the system, and making timezone handling explicit at that boundary.

I introduced apps/web/lib/date-picker-adapter.ts with one core abstraction:

/**
 * Explicit calendar components — the safe intermediate representation.
 * All parsing produces a CalendarDate; all serialization consumes one.
 * month is 1-indexed (1 = January, 12 = December).
 */
export interface CalendarDate {
  readonly year: number;
  readonly month: number; // 1–12
  readonly day: number;
}

CalendarDate is a plain integer triple. No timezone, no implicit behavior. It's what a user sees on their screen when they click a day — just year, month, day. Every parsing path produces one. Every serialization path consumes one.

The adapter supports three serialization modes, each covering a different use case in the app:

export type AdapterMode = "contact-iso" | "segment-range" | "analysis";

export type ModeValue<M extends AdapterMode> =
  M extends "contact-iso"   ? string :           // "2024-03-15T00:00:00.000Z"
  M extends "segment-range" ? [string, string] : // ["2024-03-01T...", "2024-03-31T..."]
  M extends "analysis"      ? DateRange :        // { from: Date, to: Date }
  never;

The mapped type gives consuming components full type inference — serializeToMode("contact-iso", cd) returns string, serializeToMode("segment-range", cd1, cd2) returns [string, string]. No casting needed at call sites.

The Key Insight: Two Different Date Sources

The most important design decision in the adapter is having two separate functions for extracting CalendarDate from a Date object.

/**
 * For stored/persisted dates — uses UTC getters.
 * Safe on any Date constructed via Date.UTC().
 */
export function fromUTCDate(date: Date): CalendarDate {
  return {
    year:  date.getUTCFullYear(),
    month: date.getUTCMonth() + 1,
    day:   date.getUTCDate(),
  };
}

/**
 * For browser UI interactions — uses LOCAL getters.
 * react-day-picker constructs onSelect dates at local midnight.
 * UTC getters would shift the day for IST/JST users.
 */
export function toCalendarDate(date: Date): CalendarDate {
  return {
    year:  date.getFullYear(),
    month: date.getMonth() + 1,
    day:   date.getDate(),
  };
}

Why two functions? Because Date objects from two different sources behave differently:

Stored values come back from the database as ISO strings like "2024-03-15T00:00:00.000Z". When parsed, the UTC getters give the correct calendar date regardless of local timezone.
UI click events from react-day-picker give you a Date constructed at local midnight. An IST user clicking May 20th gets Date("2024-05-20T00:00:00+05:30"). The UTC date on that object is May 19th. Using getUTCDate() here would give you the wrong day.

Mixing these two functions is the bug. Using them correctly is the fix.

In the component, every onSelect callback uses toCalendarDate:

const handleSingleSelect = useCallback(
  (selectedDay: Date | undefined) => {
    if (!selectedDay) return;
    const cd = toCalendarDate(selectedDay); // local getters — UI event
    const iso = serializeToMode("contact-iso", cd);
    onContactIsoChange(iso);
  },
  [onContactIsoChange]
);

Every parsing path for stored values uses fromUTCDate:

function parseAnalysis(value: DateRange): { from: CalendarDate | null; to: CalendarDate | null } {
  return {
    from: value.from ? fromUTCDate(value.from) : null, // UTC getters — stored value
    to:   value.to   ? fromUTCDate(value.to)   : null,
  };
}

Strict Parsing: Rejecting What `new Date()` Silently Accepts

The adapter's parseYMDString function never calls new Date(string). Instead it uses a regex to extract integer components and validates them explicitly:

export function parseYMDString(s: string): CalendarDate | null {
  const match = /^(\d{4})-(\d{2})-(\d{2})/.exec(s);
  if (!match) return null;

  const year  = parseInt(match[1], 10);
  const month = parseInt(match[2], 10);
  const day   = parseInt(match[3], 10);

  if (!isValidCalendarDate(year, month, day)) return null;
  return { year, month, day };
}

isValidCalendarDate checks for logical overflows — Feb 31, Apr 31, Feb 29 on non-leap years:

export function isValidCalendarDate(year: number, month: number, day: number): boolean {
  if (!Number.isInteger(year) || !Number.isInteger(month) || !Number.isInteger(day)) return false;
  if (month < 1 || month > 12) return false;
  if (day < 1 || day > daysInMonth(year, month)) return false;
  return true;
}

Why does this matter? new Date("2024-02-31") in JavaScript doesn't throw — it silently normalizes to March 2nd. If corrupted data enters the database as "2024-02-31", a system using new Date() would silently accept it and display a wrong date. The strict parser returns null instead, surfacing the corruption.

The Bug We Caught in Code Review

The first implementation of serializeSegmentRange looked like this:

// BUGGY: applies UTC boundaries before ordering
function serializeSegmentRange(from: CalendarDate, to: CalendarDate): [string, string] {
  const [orderedFrom, orderedTo] = enforceRangeOrder(
    toUTCStart(from), // from → 00:00:00.000Z
    toUTCEnd(to)      // to   → 23:59:59.999Z
  );
  return [orderedFrom.toISOString(), orderedTo.toISOString()];
}

The test auto-swaps a reversed range failed:

Expected: "2024-03-01T00:00:00.000Z"
Received: "2024-03-01T23:59:59.999Z"

When from is March 31 and to is March 1 (reversed), the code first applies UTC boundaries: March 31 gets 00:00:00 and March 1 gets 23:59:59. Then enforceRangeOrder swaps the Date objects chronologically. Now March 1 has the 23:59:59 boundary and March 31 has 00:00:00 — completely wrong.

The fix is to swap the CalendarDate integers before applying UTC boundaries:

// CORRECT: swap CalendarDates first, then apply boundaries
function serializeSegmentRange(from: CalendarDate, to: CalendarDate): [string, string] {
  const [orderedFrom, orderedTo] = isCalendarDateAfter(from, to) ? [to, from] : [from, to];
  return [toUTCStart(orderedFrom).toISOString(), toUTCEnd(orderedTo).toISOString()];
}

This is a subtle but important distinction: range ordering must happen at the calendar layer, not the Date layer, because the UTC boundaries are directional — they belong to specific ends of the range, not to specific dates.

Migrating CustomFilter: Removing Four States and Three Handlers

The most complex migration was CustomFilter.tsx, which handled the survey analysis date filter. The original had a hand-rolled range picker built directly in the component:

// Before: 4 states driving a manual state machine
const [filterRange, setFilterRange] = useState(...)
const [selectingDate, setSelectingDate] = useState<DateSelected>(DateSelected.FROM)
const [isDatePickerOpen, setIsDatePickerOpen] = useState<boolean>(false)
const [hoveredRange, setHoveredRange] = useState<DateRange | null>(null)

These four states powered a handleDateChange function that tracked whether the user was picking the "from" or "to" date, managed hover highlighting, and handled edge cases like clicking a start date after the current end date. 80 lines of logic.

After the migration:

// After: one state, one memo
const [showCustomPicker, setShowCustomPicker] = useState<boolean>(() => {
  if (dateRange.from && dateRange.to) {
    const label = getDateRangeLabel(dateRange.from, dateRange.to, t);
    return label === getFilterDropDownLabels(t).CUSTOM_RANGE;
  }
  return false;
});

const filterRangeLabel = useMemo(() => {
  if (!dateRange.from || !dateRange.to) return getFilterDropDownLabels(t).ALL_TIME;
  return getDateRangeLabel(dateRange.from, dateRange.to, t);
}, [dateRange.from, dateRange.to, t]);

The filterRange state was replaced by a derived memo — it's now impossible for the displayed label to diverge from the actual dateRange context value. The showCustomPicker initializer uses a lazy function to correctly restore the custom picker state on page load if the user had previously set a custom range.

The DatePicker component handles all internal state for range selection, hover highlighting, and popover management. The parent component just passes a value and onChange:

{showCustomPicker && (
  <DatePicker
    mode="analysis"
    value={dateRange.from && dateRange.to ? { from: dateRange.from, to: dateRange.to } : undefined}
    onChange={(range) => {
      if (range.from && range.to) {
        setDateRange({ from: range.from, to: range.to });
      }
    }}
    onClearDate={() => {
      setShowCustomPicker(false);
      setDateRange({ from: undefined, to: getTodayDate() });
    }}
  />
)}

Net result: -80 lines of stateful logic, +15 lines of declarative props.

UTC Boundary Semantics

One decision worth explaining explicitly: why 23:59:59.999Z for end-of-day instead of 00:00:00.000Z of the next day?

export function toUTCEnd(cd: CalendarDate, hour = 23, minute = 59): Date {
  return new Date(Date.UTC(cd.year, cd.month - 1, cd.day, hour, minute, 59, 999));
}

The Formbricks backend uses inclusive range queries: WHERE timestamp >= from AND timestamp <= to. An event timestamped at 2024-03-31T23:59:45.000Z falls inside a range that ends at 2024-03-31T23:59:59.999Z. It would fall outside a range that ends at 2024-04-01T00:00:00.000Z only if the query uses < instead of <=.

Using 23:59:59.999Z makes the boundary semantics explicit and inclusive by default. If you know your backend uses exclusive upper bounds, adjust accordingly — that's a one-line change in toUTCEnd.

When time overrides are provided for analysis mode, the seconds/ms stay at their maximum values:

// User sets end time to 17:30 → stored as 17:30:59.999Z, not 17:30:00.000Z
// This ensures events at exactly 17:30:XX are captured

What We Left Out and Why

Survey editor date inputs (validation-rule-value-input.tsx): The maintainer explicitly said not to touch survey UI in this PR — it would slow down the merge. This is the right call. Scope discipline matters more than completeness.

Storybook story: The issue asked for one. We didn't ship it. Why? The UnifiedDatePicker lives in apps/web/modules/ui/components/ but Formbricks' Storybook is configured to include only packages/survey-ui/src/. Adding a story requires extending the Storybook config with apps/web path aliases and mocking useTranslation and Next.js imports. That's a separate PR.

Calling this out honestly in the PR description is better than shipping a half-baked story or pretending it doesn't exist.

Process Lessons

A few things from this experience that apply beyond this specific PR:

Read the actual file before writing the replacement. Every migration started with cat-ing the current implementation. The existing DatePickerProps had three new props added since the previous PR attempt (clearButtonId, clearButtonLabel, locale). Missing one would have broken the build silently.

Verify against the real codebase, not your mental model. I assumed DateRange from react-day-picker was { from: Date; to: Date }. It's actually { from: Date | undefined; to?: Date | undefined } — to is optional, not required. That changes how you handle the analysis mode display text.

Manual testing means actually clicking. TypeScript and ESLint tell you the code compiles and follows style rules. They don't tell you if the popover opens in the wrong direction, if the calendar highlights the selected range correctly, or if the time inputs update the filter state in real time. Those require a browser.

One commit per logical change, verified at commit time. The commit history is documentation. A reviewer reading fix(contacts): migrate date-filter-value to UnifiedDatePicker (segment-range mode) knows exactly what changed and why. A commit called fixes and stuff tells them nothing.

The Final Diff

6 commits, 9 files, 1,011 additions, 366 deletions:

feat(date-picker): add datePickerAdapter with UTC normalization and 3 modes
feat(date-picker): implement UnifiedDatePicker component with react-day-picker v9
chore(date-picker): remove react-calendar dependency
fix(contacts): migrate date-filter-value to UnifiedDatePicker (segment-range mode)
fix(contacts): migrate attribute-field-row to UnifiedDatePicker (contact-iso mode)
fix(analysis): migrate CustomFilter to UnifiedDatePicker (analysis mode)

All CI checks passing. Waiting on maintainer review.

The PR is open at formbricks/formbricks#8103. If you're working on something similar — replacing fragmented date handling in a Next.js app — the adapter pattern scales well. The key is establishing one boundary where timezone semantics are made explicit, and keeping everything else ignorant of timezones entirely.

The Silent Bug: How a DOM Click Target Issue Was Breaking Formbricks Surveys

Bharath Kumar — Sun, 19 Apr 2026 08:18:02 +0000

Here's something that will frustrate you once you see it.
You set up a Formbricks survey trigger. Configure it to fire when a user clicks .submit-btn. Deploy it. Test it yourself — works perfectly. Ship it.
Then nothing happens. Zero surveys triggered. No errors. No warnings. Just silence.
That's the bug I fixed in PR #7327. And the reason it's interesting isn't the fix itself — it's what it taught me about how SDKs fail in the real world.

What Was Actually Breaking
The Formbricks JS SDK lets you trigger surveys based on user actions — including CSS selector click actions. You tell it "when someone clicks .feedback-btn, show this survey."
The SDK listened for click events and checked if the clicked element matched your selector:
typescriptif (!targetElement.matches(".feedback-btn")) {
return false // action dropped, survey never shows
}
Looks fine. Works fine — until your button has any content inside it.
html
...
Give Feedback

Now when a user clicks the SVG icon inside the button, event.target is the — not the .feedback-btn. The .matches() check runs against the SVG. It returns false. The survey is dropped silently.
The only way to trigger the survey was to click the exact 1-2px padding of the button where no child element exists. Which nobody does.

Why Nobody Reported It Directly
This is the part that stuck with me.
The bug had almost certainly been there for a while. But nobody filed an issue saying "event.target doesn't match the selector for nested elements." They filed issues saying "the survey trigger doesn't work reliably" or "only fires sometimes." They assumed it was a configuration problem and gave up.
The bug was invisible because it failed silently. No console error. No warning. Just... nothing.
This is a classic SDK failure mode — the kind that's hard to debug because the feedback loop is broken. The user did everything right. The SDK said nothing. The survey never showed.

How Common Was This Really?
Extremely common. This affects virtually every real-world button.
Modern design systems — shadcn/ui, Radix UI, MUI, Headless UI — almost always put content inside buttons. Icon buttons. Buttons with text wrappers. Buttons with badges. Every single one of these would silently fail with the old behavior.
When I demonstrated the reproduction to Dhruwang:

Click the SVG → Survey does not trigger ❌
Click the text → Survey does not trigger ❌
Click the 1-2px button edge → Survey triggers ✅

His response: "Looks good 🚀" — merged.

The Fix: .closest() as a Fallback
The solution is a DOM method called .closest(). It walks up the DOM tree from the clicked element until it finds an ancestor that matches the selector.
typescript// Before — only checks the exact clicked element
if (!targetElement.matches(selector)) return false

// After — falls back to checking ancestors
const matchesDirectly = targetElement.matches(cssSelector)

if (!matchesDirectly) {
const ancestor = targetElement.closest(cssSelector)
if (!ancestor) return false
matchedElement = ancestor // use the button, not the SVG
}
When the user clicks the SVG icon, .closest(".feedback-btn") walks up the DOM, finds the parent button, and returns it. The survey fires correctly.
Performance note: .closest() is only called as a fallback. If the direct match succeeds — which it does for simple elements — the code takes the same fast path as before. No regression for the common case.

What This Taught Me About SDK Design
Three things that I keep coming back to:

Silent failures are worse than loud failures. An error in the console is annoying. A survey that silently never fires is a support ticket three weeks later when the customer asks why they have zero responses. SDKs that fail silently destroy trust slowly. If the fix fails for some reason, it should say so.
The gap between "works in testing" and "works in production" is the DOM. In testing you click the button. In production users click whatever their cursor lands on — which is almost always a child element. The SDK has to handle the messy reality of how people actually interact with interfaces, not the clean version you test with.
Event delegation is harder than it looks. event.target gives you the most specific element that was clicked. That's often not the element you care about. Any SDK that listens to click events and matches CSS selectors needs to account for this — otherwise it breaks on every button with an icon.

The Regression Tests
I added three tests that fail on the old code and pass on the new:
✅ Clicking a child inside .my-btn → action fires correctly
✅ Clicking an element with no matching ancestor → correctly returns false

✅ Clicking the target directly → .closest() is not called (fast path preserved)
The third test matters. It confirms the fix doesn't slow down the common case. .closest() is only invoked when the direct match fails.
232 tests. 19 files. All passing.

Why I Picked This Up
I was exploring the Formbricks codebase looking for reliability gaps — places where the SDK could fail silently without the developer knowing. This was one of the clearest examples I found.
The issue (#7314) had been sitting open. The reproduction wasn't obvious unless you thought about how click events actually propagate through the DOM. Once I understood it, the fix was clear.
That's usually how it goes with SDK bugs. Understanding the problem takes 90% of the time. Writing the fix takes 10%.

Links

PR #7327: https://github.com/formbricks/formbricks/pull/7327
My GitHub: https://github.com/bharathkumar39293
WebhookDrop (another project in this space): https://web-hook-drop-t4k6.vercel.app

I Fixed a DoS Vulnerability in Formbricks — and Added a Second Layer Nobody Asked For

Bharath Kumar — Thu, 09 Apr 2026 11:10:45 +0000

A story about picking up a security issue, going beyond the spec, and what defense-in-depth actually means in practice

The issue

Someone opened a GitHub issue on Formbricks pointing out that the userId parameter in the SDK had no length validation. Next.js's 4MB default body limit was the only thing standing between a bad actor and the server.

The fix suggested was straightforward: add .max(255) to the Zod schema. That's it.

I picked it up the same day. But as I dug in, I realized the schema fix alone wasn't enough.

Why 255?

Before writing a single line, I thought about what userIds actually look like in production:

UUIDs: 36 characters
Emails (RFC 5321 max): 254 characters
Custom IDs: typically tens to hundreds of characters

255 covers everything real. It rejects everything abusive. The number isn't arbitrary — it's the smallest limit that breaks nothing legitimate.

The schema fix (Layer 1)

The issue pointed at one schema. I found four that needed fixing:

// packages/types/displays.ts
userId: z.string().max(255, {
  message: "User ID cannot exceed 255 characters"
}).optional()

// packages/types/js.ts
userId: z.string().max(255)  // ZJsUserIdentifyInput
userId: z.string().max(255)  // ZJsPersonSyncParams

This validates at the API boundary — if an oversized userId reaches the server, it gets rejected before touching the database.

But here's what bothered me: the payload still travels over the network first.

The SDK guard (Layer 2)

The Formbricks JS SDK runs in the browser. setUserId() is called client-side. If I only validate on the server, a 4MB string still gets serialized, sent over the network, and processed by Next.js before being rejected.

That's wasteful at best. At scale with many concurrent requests, it's a real resource drain.

So I added an early rejection guard directly in user.ts:

const MAX_USER_ID_LENGTH = 255;

if (userId.length > MAX_USER_ID_LENGTH) {
  logger.error(`UserId exceeds maximum length of ${MAX_USER_ID_LENGTH} characters`);
  return okVoid();
}

This runs before updateQueue.updateUserId() is ever called. The oversized string never leaves the browser. No network call. No server processing. No database touch.

The issue didn't ask for this. But once I saw the attack surface clearly, the schema fix alone felt incomplete.

The test

I added a unit test to lock in this behavior:

test("should reject userId longer than 255 characters and not send updates", async () => {
  const longId = "a".repeat(256);
  const result = await setUserId(longId);

  expect(result.ok).toBe(true);
  expect(mockLogger.error).toHaveBeenCalledWith(
    "UserId exceeds maximum length of 255 characters"
  );
  expect(mockUpdateQueue.updateUserId).not.toHaveBeenCalled();
  expect(mockUpdateQueue.processUpdates).not.toHaveBeenCalled();
});

The test verifies three things: the function returns cleanly, the error is logged, and the update queue is never triggered. Future refactors can't accidentally regress this silently.

What I learned

The schema fix was the correct answer to the issue as written. The SDK guard was the correct answer to the actual problem.

These are different things. Reading an issue description and reading the underlying risk are different skills. The description tells you what to change. The risk tells you why, and once you understand why, you often see that the suggested change is necessary but not sufficient.

Defense in depth isn't a fancy term. It just means: don't rely on a single check. If the client-side guard fails or gets bypassed somehow, the server-side schema catches it. If someone calls the API directly without the SDK, the schema catches it. Two independent layers, neither depending on the other.

The PR got merged. Matti left a note: "The additional validation makes sense."

That's the whole story.

Links

Merged PR: #7378
Original issue: #7375
My GitHub: bharathkumar39293

I'm a final year CS student graduating in 2026, looking for backend/infra roles. If this kind of thinking interests your team, I'd love to connect.

I Built a Rate Limiter SDK from Scratch — Here's Every Decision I Made and Why

Bharath Kumar — Sun, 05 Apr 2026 03:27:18 +0000

I'm a final-year CS student who contributes to open source — Formbricks, Trigger.dev. While doing that I kept running into the same class of problems: rate limiting, retry logic, SDK reliability.
So I built a rate limiter SDK from scratch. Not to follow a tutorial. To actually understand every decision.
This post is about those decisions — why Redis over PostgreSQL, why sliding window over fixed window, why fail-open over fail-closed, and a few others. Each one taught me something that no tutorial ever explained.
Live demo: https://rate-limiter-sdk.vercel.app
GitHub: https://github.com/bharathkumar39293/Rate-Limiter-SDK

What I built
A rate limiter that any Node.js developer can drop into their app with one npm install:
typescriptimport { RateLimiterClient } from 'rate-limiter-sdk'

const limiter = new RateLimiterClient({
apiKey: 'your-api-key',
serverUrl: 'https://your-server.com'
})

const result = await limiter.check({ userId: 'user_123', limit: 100, window: 60 })

if (!result.allowed) {
return res.status(429).json({ retryAfter: result.retryAfter })
}
One line. Everything handled. That's the goal of an SDK — hide the complexity so the developer never has to think about it.
The stack: TypeScript, Node.js, Express, Redis, PostgreSQL, Docker. Let me walk through the decisions.

Decision 1: Redis over PostgreSQL for the rate limiting logic
This was the first question I had to answer. I already know PostgreSQL. Why bring in Redis at all?
The answer is simple once you think about it.
Rate limiting happens on every single request — before anything else runs. At scale that's thousands of times per second. PostgreSQL lives on disk. Every query is a disk read. That's fine for storing user data. It's not fine for something that needs to respond in under a millisecond.
Redis lives in RAM. No disk. The difference is roughly 100 nanoseconds (Redis) vs 10 milliseconds (PostgreSQL). That's 100,000x faster.
So the rule became clear: Redis for real-time decisions. PostgreSQL for permanent history. Different jobs, different tools.

Decision 2: Sliding window over fixed window
This is the one I get asked about most. Both algorithms count requests over a time window — but they behave very differently under pressure.
Fixed window divides time into rigid buckets: 0-60s, 60-120s, and so on. Limit is 100 requests per bucket. Sounds fine.
The problem: a user can send 100 requests at second 59 and another 100 at second 61. That's 200 requests in 2 seconds — double the limit — and both batches pass the check. The bucket boundary is a hole.
Sliding window doesn't use buckets. The window always looks back exactly N seconds from right now. If you sent 100 requests in the last 60 seconds, you're blocked. Doesn't matter when the clock ticks over.
The implementation uses a Redis sorted set. Each request is stored as an entry with its timestamp as the score. To check the limit:
typescript// Remove entries older than the window
await redis.zremrangebyscore(key, 0, now - windowMs)

// Count what's left — these are all within the window
const count = await redis.zcard(key)

// Make the decision
if (count >= limit) return { allowed: false, retryAfter: ... }

// Allow — add this request
await redis.zadd(key, now, requestId)
Four lines of logic. The sliding window moves automatically because we always remove old entries before counting.
Stripe uses sliding window. Cloudflare uses sliding window. There's a reason.

Decision 3: Fail-open over fail-closed
This was the most important design decision in the SDK client — and the one that took the longest to think through.
When the rate limiter server is unreachable (network down, timeout, crash), the SDK has two options:

Fail closed → block all requests. Safe, strict.
Fail open → allow all requests. Risky, but resilient.

I chose fail-open. Here's why.
My rate limiter is a secondary service. It exists to protect the developer's app — not to be the app itself. If my server goes down and I fail closed, I just blocked every user of every app that's using my SDK. The developer's product is now broken because of my infrastructure problem.
That's a worse outcome than allowing a few extra requests temporarily.
typescript} catch (error: any) {
// Server unreachable — fail open
if (!error.response) {
console.warn('[RateLimiter] Server unreachable — failing open')
return { allowed: true, remaining: -1 }
}
return error.response.data
}
The remaining: -1 is a deliberate signal. Negative remaining means "we allowed this but couldn't actually check." Developers who want to monitor fail-open events can watch for it.
The principle: never let your secondary service take down someone's primary app.

Decision 4: Fire-and-forget for PostgreSQL logging
Every request — allowed or rejected — gets logged to PostgreSQL for analytics. But I don't await the log call.
typescriptconst result = await checkRateLimit(apiKey, userId, limit, window)

// No await — fire and forget
logRequest({ apiKey, userId, allowed: result.allowed, remaining: result.remaining })

// Response goes out immediately
return res.status(result.allowed ? 200 : 429).json(result)
Why? Because the client doesn't care about logging. The decision is already made. If I await the PostgreSQL write, I'm adding ~5ms of latency to every single request — for something the client gets zero value from.
Fire-and-forget: start the operation, send the response immediately, let the log finish in the background.
The tradeoff: if the server crashes in that 5ms window, the log is lost. That's acceptable for analytics data.
The rule: never make clients wait for things they don't care about.

Decision 5: In-memory cache for API key validation
Every request needs to validate the API key against PostgreSQL. But if I hit the database on every single request, I'm adding a DB round-trip to every rate limit check — defeating the purpose of using Redis for speed.
The solution is an in-memory Set:
typescriptconst validKeys = new Set()

export async function authMiddleware(req, res, next) {
const apiKey = req.headers['x-api-key']

// Fast path — already verified
if (validKeys.has(apiKey)) return next()

// Slow path — first time seeing this key
const result = await db.query('SELECT id FROM api_keys WHERE key = $1', [apiKey])
if (result.rows.length === 0) return res.status(401).json({ error: 'Invalid API key' })

// Cache it for next time
validKeys.add(apiKey)
next()
}
First request from a key: hits PostgreSQL (~5ms). Every subsequent request: hits the Set (~0.001ms). At scale that's thousands of database queries saved per second.
The Set resets on server restart — which is fine. The DB is the source of truth. This is just a speed layer.

Decision 6: Plain React over Next.js for the dashboard
This one is simple but I get asked about it.
The dashboard is an internal analytics tool. It shows request counts, blocked percentages, per-user breakdowns. Nobody is Googling for it. There are no public pages to index.
Next.js is great for server-side rendering and SEO. Neither of those things matter for an internal dashboard that only authenticated users see.
Adding Next.js for this use case is overengineering. Plain React, talking to the Express API, is exactly the right tool.
The principle: use the simplest tool that solves the problem correctly.

Decision 7: 2-second timeout on every SDK call
The SDK calls my server on every limiter.check() call. If my server is slow — maybe it's under load, maybe it's in the middle of a deploy — the SDK should not hang the developer's app indefinitely.
typescriptconst response = await axios.post(serverUrl, options, {
headers: { 'x-api-key': this.apiKey },
timeout: 2000 // give up after 2 seconds
})
Two seconds is the threshold. After that, the request times out, the catch block runs, and we fail-open. The developer's app never hangs waiting for my server.

What I learned
Building this taught me something I didn't expect: the interesting part of backend engineering is almost never the happy path.
Anyone can write the code that works when everything is fine. The decisions that matter are:

What happens when Redis goes down?
What happens when the DB is slow?
What happens when two requests arrive at the same millisecond?
How do you make it fast without making it fragile?

These are the questions that show up in production. Building this project — and contributing to Formbricks and Trigger.dev — forced me to think about all of them.
That's why I built it. Not to add a line to a resume. To actually understand the problems.

Links

Live demo: https://rate-limiter-sdk.vercel.app
GitHub: https://github.com/bharathkumar39293/Rate-Limiter-SDK
My other project (webhook delivery engine): https://web-hook-drop-t4k6.vercel.app

If you're building something similar or have questions about any of these decisions — drop a comment. Happy to dig into it.

DEV Community: Bharath Kumar

How I Replaced react-calendar with a Timezone-Safe UnifiedDatePicker in a Production OSS Codebase

How I Replaced react-calendar with a Timezone-Safe UnifiedDatePicker in a Production OSS Codebase

The Setup

The Problem: Two Separate Bugs, One Root Cause

The Architecture Decision: An Adapter Layer

The Key Insight: Two Different Date Sources

Strict Parsing: Rejecting What new Date() Silently Accepts

The Bug We Caught in Code Review

Migrating CustomFilter: Removing Four States and Three Handlers

UTC Boundary Semantics

What We Left Out and Why

Process Lessons

The Final Diff

The Silent Bug: How a DOM Click Target Issue Was Breaking Formbricks Surveys

I Fixed a DoS Vulnerability in Formbricks — and Added a Second Layer Nobody Asked For

I Built a Rate Limiter SDK from Scratch — Here's Every Decision I Made and Why

Strict Parsing: Rejecting What `new Date()` Silently Accepts