DEV Community: Nainik Mehta

Solving the Invisible Update Bug: Read-Your-Writes Guide

Nainik Mehta — Fri, 11 Sep 2026 07:31:43 +0000

The Invisible Update: Understanding Read-Your-Writes Consistency

We have all been there. You update your profile settings, click "Save," and the page reloads. For a split second, everything looks correct—then, you hit refresh, and your changes vanish. The old data is back. You panic, re-type your changes, hit save again, and suddenly, your previous update reappears.

This is the classic "invisible update" bug. It is a textbook failure of read-your-writes consistency in distributed systems. While it may seem like a simple UI glitch, it is actually a profound architectural challenge that highlights the friction between database scalability and user experience.

What Is Happening Under the Hood?

In modern web applications, we rarely read and write from the same database instance. To achieve high availability and handle massive read traffic, we use a primary-replica architecture.

The primary database handles all write operations, while read replicas handle the heavy lifting of serving GET requests. The problem arises during the replication process:

The Write: Your application sends an UPDATE command to the primary database. It commits successfully.
The Replication: The primary database writes the change to its Write-Ahead Log (WAL) and asynchronously propagates that change to the read replicas.
The Read: Milliseconds after the write, the user’s browser triggers a GET request. Your load balancer, attempting to distribute traffic, routes this read to a replica that hasn't yet processed the WAL entry from the primary.

The replica returns the stale data. The user thinks their data is gone. Five seconds later, the replication catches up, and the data "magically" reappears. This is the definition of eventual consistency failing the user's expectation of immediate feedback.

The Anti-Pattern: The Lazy Hack

Early in my career, we tried to solve this with a "lazy hack": routing all reads to the primary database for 10 seconds after any write.

While this technically solves the consistency issue, it is a performance nightmare. By routing all post-write traffic to the primary, you negate the benefits of having read replicas. Under high load, this causes a stampede on the primary database, leading to increased latency and potential outages. It is fragile, unscalable, and ultimately, a band-aid on a systemic issue.

Three Robust Solutions for Modern Systems

If you want to maintain scale without sacrificing user trust, you need to implement more sophisticated strategies.

1. LSN-Based Routing (The Gold Standard)

The most reliable way to ensure consistency is to track the state of the database using a Log Sequence Number (LSN) or a Global Transaction ID (GTID).

Instead of guessing how long replication takes, we track the specific point in the transaction log where the user's write occurred.

The Workflow:

When a write completes, the database returns the LSN of that transaction.
Store this lastWriteLSN in a fast cache like Redis, scoped to the user session (e.g., user:123:last_lsn).
When a read request arrives, the application queries the replica’s current LSN.
If replicaLSN >= userLastWriteLSN, the replica is "up to date" and safe to read from.
If not, the application routes the read to the primary.

// Conceptual logic for LSN-based routing
async function getConsistentRead(userId, query) {
  const userLastLSN = await redis.get(`user:${userId}:last_lsn`);
  const replicaLSN = await db.replica.execute('SELECT pg_last_wal_replay_lsn()');

  if (replicaLSN >= userLastLSN) {
    return db.replica.query(query);
  }

  // Fallback to primary for strict consistency
  return db.primary.query(query);
}

2. Define Strict 'Trust Boundaries'

Not every piece of data requires strong consistency. Applying the same strict routing logic to your entire application is overkill.

Instead, define "trust boundaries."

High-Trust Data: Billing info, security settings, passwords, and account status. These should always be read from the primary database to ensure the user sees the absolute truth.
Low-Trust Data: Activity feeds, non-critical dashboards, or public profiles. These are perfect candidates for eventual consistency.

By segregating your data, you reduce the load on the primary database while keeping the most critical user interactions consistent.

3. Leverage Optimistic UI

Sometimes, the best infrastructure fix is actually a client-side fix. Optimistic UI is a pattern where the frontend updates to reflect the user's action immediately, assuming the server request will succeed.

In frameworks like React or Next.js, instead of waiting for a full server re-fetch, you update your local state (e.g., React Query or SWR cache) as soon as the API returns a 200 OK. By bypassing the immediate read from the server, you avoid the replication lag issue entirely. If the request fails, you simply roll back the state and show an error message.

Conclusion: Balancing Consistency and Scale

System architecture is always a series of trade-offs. Forcing global strong consistency kills your ability to scale reads, but ignoring replication lag destroys user trust.

The key is to be intentional. Use Optimistic UI for immediate feedback, define Trust Boundaries to protect critical data, and implement LSN-based routing when you absolutely need to guarantee that a user sees their own writes.

How does your team handle database replication lag in production? Let's discuss in the comments.

Fix Next.js Parallel Routes 404 on Refresh | App Router Guide

Nainik Mehta — Thu, 10 Sep 2026 13:01:59 +0000

The Frustration of the Disappearing Dashboard

You’ve spent weeks architecting the perfect Next.js dashboard. You’ve leveraged the App Router’s power to implement parallel routes, creating a sophisticated, multi-pane UI that feels like a native desktop application. The client-side routing is buttery smooth, the state management is locked in, and the user experience is top-tier.

Then, you deploy to production. You send the link to a stakeholder or a beta tester. They open the dashboard, navigate through a few tabs, and—out of habit—hit Cmd + R to refresh the page.

Instead of the dashboard reloading, they are greeted by a stark, unfriendly 404 error page.

If you’ve experienced this, you aren't failing as a developer; you’ve simply hit one of the most common "gotchas" in the Next.js App Router ecosystem. Understanding why this happens—and how to fix it—is the difference between a prototype and a production-ready enterprise application.

Soft Navigation vs. Hard Refresh: The Root Cause

To understand why this happens, we have to look at how Next.js handles routing under the hood. The App Router makes a clear distinction between "soft" and "hard" navigation.

The Magic of Soft Navigation

When a user clicks a link within your application, Next.js performs a soft navigation. It doesn’t reload the entire page. Instead, it fetches the necessary data and components for the new route and patches the DOM. Crucially, it preserves the state of your parallel route slots. If a slot doesn't have a new component to render for the current URL, Next.js simply leaves the existing component in place. This is why everything looks perfect while the user is clicking around.

The Reality of Hard Refresh

A hard refresh (hitting the refresh button or Cmd + R) forces the browser to request the page from the server from scratch. Next.js must now perform a full server-side render of the entire layout. It parses the current URL and attempts to resolve a matching route for every single parallel slot defined in your directory structure.

If a slot doesn't have a route that matches the current URL, Next.js hits a wall. It doesn't have the "previous state" to fall back on because it is rebuilding from zero. Lacking a defined path for that specific URL within that specific slot, the framework defaults to the safest option: throwing a 404.

The Solution: The Power of `default.js`

The fix for this behavior is remarkably straightforward, yet it is frequently missed during initial development because soft navigation masks the underlying issue.

To prevent the 404, you must provide Next.js with a fallback for every slot. This is handled by the default.js file.

Implementing the Fallback Pattern

When you add a default.js file to a slot, you are essentially telling Next.js: "If you can't find a matching page for the current URL in this slot, render this default component instead."

Here is a minimal example of how to implement this:

// app/@analytics/default.js

import AnalyticsFallback from '@/components/AnalyticsFallback';

export default function DefaultAnalytics() {
  // You can render a loading state, a placeholder, 
  // or even null to keep the UI clean.
  return <AnalyticsFallback />;
}

By adding this file, you ensure that even during a cold hard refresh, the slot has something valid to render. The 404 is avoided, and your dashboard remains intact.

The Silent Killer: Greedy Catch-All Routes

While default.js solves the majority of these issues, there is a secondary culprit that often trips up developers: "greedy" catch-all routes.

If you have a slot containing a folder like [...nextauth] or any standard catch-all route, it can aggressively intercept URLs that were intended for other parts of your application. These routes are designed to match everything, which often causes them to hijack the resolution process for your slots.

The Fix: Optional Catch-Alls

If you find that your catch-all routes are causing unexpected behavior or interfering with your fallback mechanism, consider swapping them for optional catch-all routes. By using the [[...slug]] syntax, you make the route optional, which prevents the folder from being overly aggressive in its matching logic. This allows the Next.js router to resolve your slots more predictably.

Best Practices for Scaling Layouts

Always Define default.js: Treat default.js as a mandatory file for every slot in your parallel routing architecture. Don't wait for a bug report to add them.
Audit Your Catch-Alls: If you are using [...slug] patterns, ensure they are strictly necessary. If they are causing routing conflicts, refactor to [[...slug]].
Test Hard Refreshes Often: During development, don't just rely on clicking links. Regularly perform hard refreshes on different views of your dashboard to ensure the state is being hydrated correctly.
Leverage Loading States: Use loading.js alongside default.js to provide a seamless transition while the server resolves the slots.

Final Thoughts

Parallel routes are a powerful tool for building complex, modular UIs in Next.js. While the 404-on-refresh issue can be frustrating, it is a predictable consequence of how server-side routing works. By proactively implementing default.js fallbacks and keeping an eye on your catch-all route definitions, you can build dashboards that are as robust as they are beautiful.

Have you encountered similar issues while scaling your Next.js architecture? What other strategies do you use to keep your layouts stable? Let's discuss in the comments.

Why React 19's use() API Can Break the Rules of Hooks

Nainik Mehta — Thu, 10 Sep 2026 07:31:37 +0000

The Paradigm Shift: React 19 and the `use` API

For years, the "Rules of Hooks" have been the foundational dogma of React development. Since the introduction of Hooks in 2018, developers have lived by the mantra: Hooks must be called at the top level, never inside loops, conditions, or nested functions. This restriction was not arbitrary—it was a technical necessity for React’s reconciliation engine to maintain state consistency across re-renders.

However, React 19 has arrived, and it has done the unthinkable: it has officially broken these rules. With the introduction of the new use API, React is moving toward a more flexible, declarative future. But how can a framework that relies so heavily on call-order tracking suddenly allow conditional hooks? The answer lies in a fundamental shift from stateful tracking to stateless evaluation.

Why the Rules of Hooks Existed

To understand why use is revolutionary, we must first understand why we couldn't use useState or useEffect conditionally.

React tracks hooks using an internal linked list or array. When your component renders, React executes your hooks in the exact order they appear in your code. If you have three useState calls, React maps them to index 0, 1, and 2 in its internal memory.

If you were to wrap one of those calls in an if statement, and that condition evaluated to false, the sequence of calls would shift. React would look for the second hook, but instead of finding the expected state, it would find the third hook. The application would lose its "place," leading to unpredictable bugs and crashes.

How the `use` API Changes the Game

The use API is fundamentally different because it is stateless. It does not rely on a fixed call order because it does not store state in the same way useState does.

Instead, use reads the current value of a resource—such as a Promise or a Context—on every single render. Because it doesn't need to maintain a persistent index in a list of hooks, it can be called inside if statements, loops, and even within the render body of a component without confusing the reconciler.

Integration with Suspense and Error Boundaries

The power of use extends beyond mere flexibility; it is designed to work natively with the React Suspense and Error Boundary architecture:

Pending: If you pass a Promise to use and it is still pending, the component suspends. React will display the nearest Suspense fallback.
Resolved: Once the Promise resolves, use returns the value, and the component re-renders with the data.
Rejected: If the Promise is rejected, use throws the error, which is caught by the nearest Error Boundary.

This declarative approach removes the need for manual loading and error state variables, significantly reducing boilerplate code.

The Pitfall: Avoiding Infinite Re-render Loops

While use offers incredible power, it introduces a dangerous pitfall: the infinite re-render loop. Because use suspends when a Promise is pending, the component unmounts and re-renders when the state changes. If you define a new Promise directly inside your component's render body, that Promise is recreated on every single render.

Consider this anti-pattern:

// DANGEROUS: This causes an infinite loop
function UserProfile({ userId }) {
  // A new promise is created every time the component renders
  const data = use(fetchData(userId)); 
  return <div>{data.name}</div>;
}

Because fetchData(userId) returns a new Promise on every render, React sees a new pending resource, suspends, re-renders, and repeats the cycle indefinitely.

The Solution: Stable Promises

To use use effectively in production, your Promises must be stable. They should be cached outside the render body. This is typically handled by:

Server Components: Fetching data on the server and passing it down.
Route Loaders: Fetching data at the routing layer (like in React Router or Next.js).
Cache Mechanisms: Using libraries like React Query or a custom memoized cache that returns the same Promise reference across renders.

Is `use` a Replacement for Everything?

It is tempting to view use as a "better hook" that replaces useContext or even useEffect. However, it is important to note that use is not a silver bullet.

While it is a superior way to consume Context conditionally, it is not a replacement for useEffect. You still need useEffect for side effects that require cleanup logic, such as:

Attaching and removing event listeners.
Managing WebSocket subscriptions.
Interacting with imperative browser APIs.

Conclusion

React 19’s use API represents a significant evolution in how we build user interfaces. By allowing us to break the traditional Rules of Hooks, React is enabling more declarative, cleaner, and more readable code.

However, this power comes with the responsibility of understanding the underlying architecture. As we transition to this new model, the difference between a high-performing app and one plagued by memory leaks and infinite loops will be a deep understanding of how data flows through the component lifecycle.

Are you ready to embrace the stateless nature of the use API, or will you keep your data fetching logic within the safety of useEffect for the time being? The future of React is here—use it wisely.

Database-per-Service is a Trap: Try Logical Schemas

Nainik Mehta — Thu, 10 Sep 2026 03:01:30 +0000

The Database-per-Service Fallacy

For many engineering teams, the "database-per-service" pattern has become the de facto gold standard for microservices architecture. We are taught that to truly decouple services, we must enforce physical data isolation. If a service owns its data, it should own its database.

However, for a 15-person engineering team, this "best practice" often becomes a massive anchor. You find yourself spending more time managing distributed transactions and Kafka topics than building features that actually deliver value to your users.

If you are struggling with complex Saga orchestrators just to join a User table with an Order table, you have likely fallen into a common architectural trap: premature optimization.

The Cost of Premature Isolation

When startups and mid-sized teams rush to split their databases, they often create a "distributed monolith"—a system that suffers from the complexity of microservices without gaining any of the benefits of scalability.

By forcing physical isolation too early, you inherit several significant operational burdens:

Distributed Consistency Nightmares: Without ACID-compliant transactions across services, you are forced to implement complex patterns like Sagas or distributed locks.
Latency Spikes: Simple read operations that could have been a single SQL join now require multiple network hops between services.
Operational Overkill: You end up maintaining complex event-driven pipelines simply to keep data synchronized across boundaries.

I recall a project where we migrated a billing service to its own database. Suddenly, a simple check to see if a client was active required a network call from the subscription service. We spent weeks debugging race conditions and implementing retry queues and outbox patterns. It was a massive waste of engineering cycles that could have been spent on product growth.

The Pragmatic Alternative: Logical Schemas

The alternative is not to abandon modularity, but to rethink where you enforce it. You can achieve clear ownership boundaries without the overhead of multiple database instances by using logical schemas.

In a system like PostgreSQL, you can isolate your data using namespaces (schemas) within a single physical instance.

Example: Implementing Logical Isolation in Postgres

Instead of creating two separate databases, organize your tables into logical schemas. This allows you to maintain clean code boundaries while keeping the data accessible.

-- Create distinct schemas for service ownership
CREATE SCHEMA users;
CREATE SCHEMA billing;

-- Define tables within their respective schemas
CREATE TABLE users.profiles (
    id UUID PRIMARY KEY,
    email TEXT NOT NULL,
    status TEXT
);

CREATE TABLE billing.invoices (
    id UUID PRIMARY KEY,
    user_id UUID REFERENCES users.profiles(id),
    amount DECIMAL
);

-- You can still perform efficient, ACID-compliant joins
SELECT i.id, u.email 
FROM billing.invoices i
JOIN users.profiles u ON i.user_id = u.id
WHERE u.status = 'active';

Why Logical Schemas Win

Using logical schemas provides the best of both worlds:

Clear Ownership: Your application code connects to the database with a search path restricted to its own schema, enforcing logical separation.
Future-Proofing: If a specific service grows to the point where it truly needs its own hardware, moving a schema to a separate database instance is a straightforward migration.
Pragmatism: When you need to perform cross-service reporting or complex queries, you aren't fighting against your own infrastructure. You have the full power of SQL at your fingertips.

Conclusion: Build for Your Current Scale

A recent industry report noted that 34% of practitioners admit that multiple microservices end up managing the same tables anyway. We must stop paying the "distributed systems tax" before we have even reached product-market fit.

Keep your stack simple. Build clean boundaries within a single database, and only reach for physical isolation when your team size, traffic, and data volume actually demand it. Your future self—and your velocity—will thank you.

Resilient AI: Multi-Provider LLM Fallback Routing Guide

Nainik Mehta — Wed, 09 Sep 2026 13:02:12 +0000

The Case for Resilience in AI Architecture

In the early days of integrating Large Language Models (LLMs) into production applications, developers often treated them like standard third-party APIs. You pick a provider, integrate their SDK, and call it a day. However, the landscape of 2023 and 2024 proved that relying on a single provider is a significant operational risk.

From major outages at OpenAI to service disruptions at Anthropic, the reality has become clear: LLM gateway fallback routing is no longer an optional optimization—it is a production necessity. If your AI feature is hardcoded to a single provider’s SDK, your application’s uptime is strictly bounded by theirs. If they go down, you go down.

Moving Beyond Single-Provider Dependency

Last quarter, we faced a critical turning point in our analytics engine. We noticed that a single 503 error from our primary LLM was causing our entire user onboarding flow to crash. The user experience was brittle, and the business impact was immediate. We decided to migrate our architecture to a multi-provider fallback pattern.

The goal was simple: decouple our product uptime from the status of any single AI provider. By implementing a tiered routing architecture, we ensured that if our primary model fails, the system automatically redirects the request to a secondary, and if necessary, a tertiary model.

Implementing the Fallback Pattern

The implementation doesn't have to be complex. At its core, it is about wrapping your LLM calls in a resilient retry and fallback mechanism. Here is a simplified example of how we implemented this logic inside our Next.js edge route:

async function getAIResponse(prompt: string) {
  // Attempt primary model (e.g., Claude 3.5 Sonnet)
  return await callPrimaryLLM(prompt)
    .catch(async (err) => {
      console.warn('Primary LLM failed, initiating fallback:', err);

      // Attempt tier-2 model (e.g., GPT-4o)
      try {
        return await callFallbackLLM(prompt);
      } catch (fallbackErr) {
        console.error('Tier-2 fallback also failed:', fallbackErr);
        // Optional: Trigger a final, cost-effective model or return a cached response
        return await callFinalSafetyModel(prompt);
      }
    });
}

Key Engineering Takeaways

Migrating to a multi-provider strategy taught us several lessons that are essential for any production-grade system.

1. Standardize Your Schemas

The biggest hurdle in swapping providers is the differences in their response formats. To solve this, you must use a unified interface. Whether you use the Vercel AI SDK or build your own internal abstraction layer, ensure your frontend parsing logic remains agnostic of the underlying model provider. This allows you to swap providers or add new ones without refactoring your entire codebase.

2. Monitor the Latency Penalty

Fallbacks are not "free." They add execution time. If your primary request waits 10 seconds to timeout before triggering a fallback, your user has already abandoned the page. In interactive UI contexts, set aggressive timeouts (e.g., 3–4 seconds) for the primary call. If it doesn't respond within that window, fail fast and trigger the fallback immediately.

3. Track Your Costs

Tiered routing is a powerful tool, but it can be dangerous for your budget. If your primary model fails during a high-traffic period, you might accidentally route thousands of requests to a significantly more expensive model. Always implement real-time alerting on fallback usage so you can identify if a provider is consistently failing and adjust your routing logic accordingly.

Conclusion

Building for production-grade AI means embracing the mindset that things will fail. Relying on a single provider is a gamble with your user experience. By implementing a robust LLM gateway fallback routing strategy, you can achieve near-perfect uptime and gain the flexibility to adapt to the rapidly changing AI landscape.

Are you handling LLM downtime in your production apps? Are you using self-hosted gateways, custom middleware, or third-party routers? Let’s discuss in the comments.

React Context Is Not State Management: Stop Using It

Nainik Mehta — Wed, 09 Sep 2026 03:01:52 +0000

The Architectural Trap: Why React Context Isn't a State Manager

In the modern React ecosystem, "prop drilling" is often cited as the ultimate developer productivity killer. To solve it, many teams reflexively reach for React Context. It’s built-in, it’s easy to use, and it seems to solve the problem of passing data through deeply nested component trees.

However, after auditing dozens of enterprise-grade React codebases, I have identified a recurring architectural pattern that is quietly crippling application performance: using React Context as a high-frequency state management tool.

It is time to clarify a fundamental truth: React Context is a dependency injection tool, not a state manager. When you use it for the wrong purpose, you aren't just writing messy code—you are creating a performance bottleneck that will eventually choke your main thread.

The Mechanics of the Performance Hit

To understand why Context fails under high-frequency updates, we have to look at how React handles re-renders. When a value provided by a Context.Provider changes, React notifies every single component that consumes that context.

Crucially, this process bypasses React.memo. If your component consumes a context, it will re-render whenever the context value changes, regardless of whether the specific data the component cares about has actually changed.

The "Inline Object" Anti-Pattern

The most common mistake I see involves passing an object literal directly into the provider:

// The Anti-Pattern
<Context.Provider value={{ state, dispatch }}>
  {children}
</Context.Provider>

Because React uses Object.is for reference equality checks, the object { state, dispatch } is re-created on every single render of the parent component. Even if state hasn't changed, the reference has. This forces a massive, unnecessary cascade of re-renders across your entire component tree.

A Real-World Performance Impact

We recently audited an enterprise dashboard featuring a complex form with 50+ fields. Users reported that typing in the fields felt sluggish and unresponsive. After profiling the application, we found the update latency was a staggering 250ms per keystroke.

By migrating the high-velocity UI state from a monolithic React Context to Zustand, we achieved a dramatic improvement. Zustand leverages atomic, selector-based subscriptions. This means that when a user types in a single input field, only that specific component re-renders.

The result? Update latency dropped from 250ms to a buttery-smooth 12ms.

When Should You Actually Use Context?

React Context is not "bad"—it is simply a specialized tool. It excels at managing low-velocity global data that rarely changes.

Here is the rule of thumb I recommend for your architecture:

Low-Velocity Data Only: Use Context for data that changes infrequently, such as UI themes, user authentication status, or locale settings.
Split Your Contexts: If you must use Context for state, split your providers. Separate your StateContext from your DispatchContext. This ensures that components only interested in calling a dispatch function do not re-render when the state changes.
External Stores for High-Frequency Data: For anything that changes on every keystroke, mouse movement, or real-time data stream, move that state into an external store like Zustand or Jotai. These libraries utilize useSyncExternalStore under the hood, providing a performant, predictable way to manage state without triggering global re-renders.

Conclusion: Stop Choking Your Main Thread

As we move through 2025, the complexity of our frontends continues to grow. We need to be more disciplined about our architectural choices. Stop using React Context as a catch-all solution. Your users deserve a responsive interface, and your main thread deserves a break.

What is your go-to state management tool for React apps in 2025? Let’s discuss in the comments.

Systems Architecture for Agentic AI in Next.js | Nainik Mehta

Nainik Mehta — Tue, 08 Sep 2026 13:01:35 +0000

The Agentic Bottleneck

As we move deeper into 2026, the promise of agentic AI is everywhere. However, a silent crisis is brewing in the developer community: most agentic applications feel like slow, brittle wrappers around LLM APIs. Why? Because we are still trying to force these complex, multi-step systems into the rigid, monolithic request-response patterns of the past.

When we first began building our agentic platform, we hit a wall. Our initial architecture relied on standard HTTP connections between our Next.js frontend and our LLM-backed backend. As soon as we introduced multi-step reasoning loops—where an agent needs to plan, tool-use, and reflect—those connections began to fail. We were fighting against API gateway timeouts, dangling sockets, and a frontend that felt sluggish, constantly waiting for a monolithic process to complete.

Rethinking Systems Architecture

To scale effectively, we realized we had to stop treating AI agents as synchronous REST endpoints. The traditional "request-response" model assumes that a user asks a question and receives an answer in a predictable timeframe. But agentic workflows are inherently unpredictable. They involve multiple steps, external tool calls, and variable processing times.

We decided to completely decouple execution from presentation. By shifting to an asynchronous, event-driven architecture, we transformed our system from a chain of fragile dependencies into a resilient, reactive pipeline.

The Event-Driven Shift

Instead of keeping an HTTP stream open directly from a Next.js serverless function to the LLM agent, we introduced a message broker. This allows us to queue agent tasks immediately. Once a task is submitted, the serverless function can return a 202 Accepted status, freeing up resources while the heavy lifting happens in the background.

Our background workers process each step of the agent's logic. To keep the UI responsive, we use a lightweight WebSocket channel to stream updates back to the browser in real-time. This allows the frontend to render optimistic UI updates, showing the user exactly what the agent is doing at any given moment.

Tracking the Thought Process

To maintain consistency across our event-driven system, we defined a standard interface for agent steps. This allows our backend workers and frontend services to communicate state changes predictably:

interface AgentStep {
  taskId: string;
  stepNumber: number;
  status: 'thinking' | 'acting' | 'done';
  output: string;
  timestamp: number;
}

By pushing these objects through our WebSocket layer, the frontend can render the agent’s internal "thought process" progressively. This doesn't just improve performance; it builds user trust by making the agent's reasoning transparent.

Results and Scalability

The impact on our platform was immediate. Our perceived UI latency dropped to sub-50ms because the frontend no longer waited for the entire agent workflow to finish before showing the first "thought."

Furthermore, because we decoupled the execution, our system now scales horizontally. We can handle thousands of concurrent multi-step reasoning sessions without worrying about serverless runtime limits or connection timeouts. We are no longer limited by the duration of a single HTTP request.

The Path Forward

If you are building in the agentic era, take this as a sign to rethink your stack. Stop forcing agents into synchronous boxes. Build for asynchronicity, embrace event-driven patterns, and prioritize real-time state streaming.

How are you handling real-time state streaming for complex AI agent workflows in your Next.js applications? Are you using WebSockets, Server-Sent Events, or something else? Let's discuss in the comments below.

How to Fix LLM Streaming Lag and React Render Storms

Nainik Mehta — Tue, 08 Sep 2026 07:31:15 +0000

The LLM 'Render Storm': Why 50 Tokens/Sec Will Lag Your React App

Generative AI is transforming how we build applications, but it has introduced a silent performance killer in frontend development: the "Render Storm." If you are building an AI-powered chat interface or a real-time document generator, you have likely encountered the challenge of streaming text.

Many developers start by piping their LLM stream directly into a React state variable. It seems logical—data comes in, you update the state, and the UI reflects the change. However, this approach is a recipe for disaster. If you aren't careful, your high-performance LLM implementation will quickly become a high-performance lag machine.

The Math Behind the Lag

To understand why this happens, we have to look at the numbers. Modern LLMs can stream tokens at speeds ranging from 30 to over 100 tokens per second.

If you are using a naive implementation where every incoming network chunk triggers a setState call, you are effectively forcing React to perform a full render cycle for every single token. At 50 tokens per second, that is 50 state updates per second.

Because these tokens arrive as asynchronous network chunks, React’s automatic batching—which usually coalesces updates within the same synchronous event loop task—cannot help you. Each token arrives as its own discrete task, forcing a re-render.

The Frame Budget Reality

To maintain a smooth 60 frames per second (FPS) experience, your application must complete its render and commit cycle within a 16.6ms frame budget. When you trigger 50 renders per second, you are consuming your entire frame budget just on reconciliation and DOM updates. The result is predictable:

Severe scroll jitter
Input latency
Dropped frames
A UI that feels "locked" or unresponsive

In a recent benchmark I conducted on a production React 18.3 build, streaming at 80 tokens per second resulted in over 40 renders per second, with average commit durations hitting 52ms. The interface was essentially unusable.

The Solution: Decouple Intake from Render

The key to solving this is to decouple your stream intake from your render cycle. You should not be letting the network dictate your frame rate. Instead, you should control the flow of updates to the UI.

The `requestAnimationFrame` Pattern

The most effective approach for 95% of use cases is to buffer incoming tokens in a mutable useRef and flush them to the state using requestAnimationFrame. This ensures that your UI updates only as often as the browser can actually paint them.

import { useState, useRef, useCallback } from 'react';

const useBufferedStream = () => {
  const [content, setContent] = useState('');
  const streamRef = useRef('');
  const requested = useRef(false);

  const handleToken = useCallback((token) => {
    streamRef.current += token;

    if (!requested.current) {
      requested.current = true;
      requestAnimationFrame(() => {
        setContent(streamRef.current);
        requested.current = false;
      });
    }
  }, []);

  return { content, handleToken };
};

By implementing this pattern, we effectively cap the render rate at 12–16 frames per second, which is perfectly aligned with the display refresh rate. In my tests, this simple change caused the average commit duration to plummet from 52ms to just 5ms. The UI became buttery smooth, even during heavy generation tasks.

When You Need More: Web Workers and Canvas

For most applications, the requestAnimationFrame buffer is sufficient. However, if you are building an application with extreme throughput requirements—say, exceeding 150 tokens per second or rendering massive amounts of markdown—you may need to offload the heavy lifting.

In these scenarios, consider:

Web Workers: Move the text processing, parsing, and measurement logic to a background thread to keep the main thread free for interaction.
Canvas Rendering: If the text volume is massive, avoid the DOM entirely. Drawing text directly to a <canvas> element bypasses the overhead of the React reconciliation tree, allowing for near-instantaneous updates regardless of token speed.

Final Thoughts

Don't let your AI features compromise your user experience. While it is tempting to use the simplest implementation, streaming data requires a more disciplined approach to React state management. By buffering your stream, you can ensure your application remains fast, responsive, and professional.

Are you still relying on raw setState for your streaming AI features, or have you implemented a custom buffering solution? Let me know in the comments.",article_title:

Stop Treating 'use client' Like a Code Smell in Next.js

Nainik Mehta — Tue, 08 Sep 2026 03:01:09 +0000

The "Server-Everything" Trap

In the current landscape of modern web development, the introduction of React Server Components (RSC) within the Next.js ecosystem has been nothing short of revolutionary. We have moved away from the "everything is a client component" era of the early 2020s toward a model that prioritizes initial load times, SEO, and reduced JavaScript bundles.

However, a dangerous trend has emerged: developers are treating use client as if it were a code smell. There is a prevailing, often unspoken pressure to keep components on the server at all costs, under the assumption that any client-side code is inherently "bad" for performance. I’m here to tell you that this is an overcorrection that is actively making your applications feel sluggish.

The Cost of Architectural Purity

Server Components are incredible for what they do: they eliminate database-to-client waterfalls and reduce the amount of JavaScript sent to the browser. But they were never intended to handle every single interaction.

When you force a modal toggle, a complex dropdown, or a real-time search input to perform a network roundtrip to the server for every keystroke or click, you are trading a snappy, responsive user experience for a misguided sense of architectural purity. The user doesn't care about your server-side rendering strategy; they care about how fast the button responds when they click it.

The Three-Question Audit

To avoid "client creep"—where unnecessary logic bloats your server components or, conversely, where server-side roundtrips bloat your latency—I use a simple heuristic. Before deciding whether to add the 'use client' directive, I run the component through this Three-Question Audit:

Does it use React hooks? (e.g., useState, useEffect, useContext)
Does it require event handlers? (e.g., onClick, onChange, onScroll)
Does it call browser-only APIs? (e.g., window, localStorage, navigator)

If the answer to all three is "no," it stays as a Server Component. If the answer to any of them is "yes," it becomes a Client Component. It is that simple.

Pattern 1: The "Leaf" Pattern

The biggest mistake developers make is placing the 'use client' directive at the top of a large file, effectively turning the entire sub-tree into client-side code. Instead, we should be using the Leaf Pattern.

Push the 'use client' directive as deep down the component tree as possible. For example, if you have a complex Navbar, don't make the entire component client-side just because of a mobile toggle menu. Extract the mobile menu into its own small, isolated component. By treating client components as isolated, interactive "islands," you can reduce your First Load JavaScript bundle by 40% to 60%.

Pattern 2: The "Children" Composition Pattern

What if you have a heavy server-side component that needs to be wrapped in an interactive client component? The solution is component composition. By passing Server Components as children to a Client Component, the interactive wrapper mounts on the client, but the heavy data-fetching subtree remains on the server.

// components/InteractiveWrapper.tsx
'use client';

import { useState } from 'react';

export default function InteractiveWrapper({ children }) {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>Toggle Content</button>
      {isOpen && <div>{children}</div>}
    </div>
  );
}

// app/page.tsx
import InteractiveWrapper from '@/components/InteractiveWrapper';
import HeavyServerContent from '@/components/HeavyServerContent';

export default function Page() {
  return (
    <InteractiveWrapper>
      <HeavyServerContent />
    </InteractiveWrapper>
  );
}

Conclusion: Performance is About Balance

In a recent production migration, adopting these two patterns helped us slash our JavaScript bundles by 57% and improve Time to Interactive (TTI) by up to 75%. We didn't do this by abandoning Server Components; we did it by being intentional about where we used them.

Stop treating use client as a failure. It is a vital tool in your belt for creating fluid, high-performance UI. Use the server for data fetching and static rendering, and use the client to bring your application to life. Your users will thank you for the extra milliseconds of speed.

React 19 useActionState: 3 Silent Trapdoors to Avoid

Nainik Mehta — Mon, 07 Sep 2026 13:01:19 +0000

Introduction

React 19 has introduced a suite of powerful hooks designed to simplify form handling and state management. Among these, useActionState is perhaps the most anticipated. It promises to eliminate the tedious boilerplate of useState hooks for loading states, error handling, and form submission tracking.

On the surface, it looks like a clean, declarative replacement for traditional form logic. However, as I discovered while refactoring a complex, multi-step signup process, useActionState is not a simple drop-in replacement. It introduces a paradigm shift that requires a deeper understanding of React's new concurrency model and web-standard form behavior.

If you treat it as a direct replacement for your existing useState patterns, you will likely encounter subtle, frustrating bugs in production. In this article, we will explore the three "silent trapdoors" I encountered and how to avoid them.

1. The Stale Closure Trap

The signature for the action function in useActionState is (prevState, formData) => nextState. This function is intended to be pure or at least independent of the component's render cycle.

The Problem

When you read outer component state or props directly inside your action function, you are creating a closure that captures those values at the time the component was rendered. Because the action might be executed asynchronously, the state or props it references might have changed by the time the action actually runs.

The Solution

Instead of relying on outer scope, you must extract all necessary data from the formData object passed to the action. If you have data that isn't part of the form submission (like a user ID from context), use the .bind() method to pass these values explicitly to the action function when you define it.

// AVOID: Accessing outer state directly
const [state, formAction] = useActionState(async (prevState, formData) => {
  return await submitData(formData, userId); // userId might be stale!
}, initialState);

// PREFER: Using .bind() to pass values
const boundAction = submitData.bind(null, userId);
const [state, formAction] = useActionState(boundAction, initialState);

2. The `isPending` Focus Trap

One of the most touted features of useActionState is the isPending boolean, which automatically tracks the status of the form submission. A common pattern is to disable inputs while isPending is true to prevent double submissions.

The Problem

While disabling inputs is a standard UX practice, doing so improperly causes accessibility issues. When an input field is disabled while it currently holds focus, the browser immediately strips focus from that element. If the user is navigating via keyboard, their focus is reset to the body of the document, forcing them to restart their navigation from the top of the page.

The Solution

Keep your inputs interactive but provide visual feedback. Use CSS to style the input as "disabled" or "loading" without actually setting the disabled attribute on the DOM element. If you absolutely must disable the input, manage the focus state programmatically to ensure the user isn't lost.

3. Manual Triggering and Context Loss

React 19’s form hooks are designed to work seamlessly with the native <form action={...}> attribute. This allows React to track the transition lifecycle automatically.

The Problem

Developers often try to trigger these actions programmatically—for example, inside a useEffect or an onClick handler on a non-form element. When you bypass the native <form> element, you often break the internal tracking mechanism. In these cases, the isPending flag might flip back to false prematurely, before your asynchronous API call has actually resolved, leading to race conditions and UI inconsistencies.

The Solution

Lean into web-standard HTML form semantics. If you need to trigger an action, do it through a native <form> element. If you need a custom UI, consider using a hidden form or a <button type="submit"> that is styled to look like your desired UI element.

Conclusion

useActionState is an incredibly powerful tool for declarative form management, but it is not a "magic bullet." It expects you to write code that respects the browser's native form lifecycle. By avoiding stale closures, handling focus states gracefully, and sticking to native form submission patterns, you can leverage the power of React 19 without falling into these silent traps.

Have you started migrating your forms to React 19? What unexpected behaviors have you encountered? Let's discuss in the comments.

Why Your AI Agent Should Just Be a Simple while Loop

Nainik Mehta — Mon, 07 Sep 2026 03:01:24 +0000

The Case for Simplicity in Agentic Systems

In the rapidly evolving landscape of Large Language Models (LLMs), the term "AI Agent" has become synonymous with complexity. Developers are rushing to adopt heavy-duty frameworks like LangChain, CrewAI, or complex graph-based orchestration tools. While these tools have their place in research or highly specific multi-agent orchestrations, they often introduce unnecessary fragility into production environments.

The reality is that 90% of production AI agents do not need these abstractions. What you actually need is a robust, explicit native agent architecture centered around a controlled while loop.

Why Frameworks Often Fail in Production

When we think of "agents," our minds often jump to open-ended autonomy—systems that can reason, plan, and execute indefinitely. However, in production, autonomy is often a liability. Complex frameworks frequently hide the control flow behind layers of abstraction, making it nearly impossible to debug when the system enters an infinite loop or hallucinates a tool call.

By relying on a framework, you are inheriting its opinionated architecture, its overhead, and its specific way of handling state. When things go wrong, you aren't just debugging your logic; you are debugging the framework's implementation of that logic.

The Power of the 100-Line Master Loop

The most reliable AI systems currently in the wild often use a minimal master loop. Consider the recent performance of agents on the SWE-bench Verified benchmark. Several top-performing agents—some scoring as high as 76.8%—are built on fewer than 100 lines of code.

These systems succeed because they prioritize deterministic control flow over "magic." When you write the loop yourself, you have total visibility into every state transition and every tool execution.

A Minimalist Implementation

At its core, a native agent is just a loop that manages context and tool execution. Here is a simple, production-ready pattern:

async function runAgent(task, initialContext) {
  let history = initialContext;
  let steps = 0;
  const MAX_STEPS = 15;
  const budget = new BudgetTracker(5.00); // $5 limit

  while (steps < MAX_STEPS && !budget.exceeded()) {
    const response = await getLLMResponse(history);

    if (response.isFinished) {
      return response.finalAnswer;
    }

    if (response.calls) {
      const results = await executeTools(response.calls);
      history = updateHistory(history, response, results);
    }

    steps++;
  }
  throw new Error("Agent reached safety limits.");
}

Implementing Non-Negotiable Safety Brakes

Building a while loop in production is dangerous if you don't implement strict guardrails. Without them, a single bug in your prompt or a rogue model response can rack up massive API bills in minutes. Whenever I architect a native agent, I enforce three non-negotiable safety brakes:

1. Hard Iteration Limits

Never allow an agent to run indefinitely. By capping the loop at 15 to 20 steps, you force the agent to prioritize efficiency. If it hasn't solved the problem by then, it’s likely caught in a logic trap.

2. Dollar/Token Budgeting

Every session should have a hard ceiling on cost. Integrating a budget tracker that checks the token count or estimated cost before every iteration is a simple way to prevent financial disasters.

3. Repetition Detectors

Agents often get stuck in "circular reasoning," where they repeatedly call the same tool with the same arguments. By hashing tool calls and tracking them in a Set or Map, you can detect these patterns and kill the process before it wastes further resources.

Learning from Industry Leaders

Even sophisticated systems like Anthropic’s Claude Code agent rely on a single-threaded master loop. These systems are designed to manage resources actively. For example, when context utilization approaches a certain percentage (e.g., 92%), the agent triggers context compression. It summarizes history to protect performance and prevent the cost spikes associated with massive context windows.

Industry data supports this minimalist approach: roughly 68% of production agents execute fewer than 10 steps before requiring some form of human-in-the-loop validation. The "fully autonomous" dream is often less practical than a "collaborative assistant" that knows when to stop and ask for help.

Conclusion: Keep It Simple

The next time you start a project, ask yourself if you really need a graph framework or a complex agentic library. If you are building a tool to solve specific tasks—writing code, analyzing logs, or extracting data—a native agent architecture will save you weeks of debugging.

Write the loop yourself, build explicit brakes, and keep your control flow deterministic. Your production environment, and your API bill, will thank you.

Next.js 15 next/form: Stop Writing Search Form Boilerplate

Nainik Mehta — Sun, 06 Sep 2026 13:01:14 +0000

The End of Search Boilerplate

For years, building a search or filtering interface in React-based frameworks felt like a chore. We all know the drill: create a useState hook for your input, add an onSubmit handler, prevent the default behavior, manually construct a query string, and finally call router.push() to update the URL.

It’s repetitive. It’s imperative. And frankly, it’s unnecessary.

With the release of Next.js 15, we finally have a native solution that embraces the browser’s built-in capabilities rather than fighting them: the <Form /> component. This new addition is a game-changer for developer experience, allowing us to replace dozens of lines of boilerplate with a declarative, standard HTML-first approach.

The Old Way: Why We Need a Change

Think about the complexity involved in a standard search implementation:

State Syncing: You have to keep your input value in sync with the URL search parameters.
Navigation Logic: You need to handle router.push calls, ensuring you don't trigger unnecessary re-renders.
Loading States: Managing the transition between typing and the results updating often requires complex useEffect hooks or debouncing logic.
Error Handling: What happens if the navigation fails or the user hits enter while the JS bundle is still downloading?

This imperative approach is where most bugs are born. By manually managing the URL, we introduce room for race conditions and inconsistent UI states.

Introducing `next/form`

The next/form component is a drop-in replacement for the standard HTML <form> element. It is designed to handle URL encoding, navigation, and prefetching out of the box.

A Simple Example

Look at how little code you need to implement a fully functional search feature:

import Form from 'next/form';

export default function SearchBar() {
  return (
    <Form action=\"/search\">
      <input name=\"query\" placeholder=\"Search for products...\" />
      <button type=\"submit\">Search</button>
    </Form>
  );
}

When a user types a query and hits submit, Next.js automatically navigates to /search?query=your-input. It handles the URL encoding, the client-side navigation, and ensures the transition is smooth—all without writing a single line of useState or router.push.

The Engineering Win: Progressive Enhancement

The most impressive aspect of next/form isn't just the reduction of code—it’s the commitment to progressive enhancement.

In the modern web, we often assume JavaScript is always available. But what happens on a slow 3G connection? What if a user has JavaScript disabled? In the old imperative model, your search would simply break. With next/form, the component gracefully falls back to a standard HTML GET request. The application remains functional, accessible, and robust.

Performance Out of the Box

Next.js 15 also optimizes the UX through automatic prefetching. When a next/form component enters the viewport, Next.js begins prefetching the shared layout resources and the target page. This means that by the time the user actually interacts with the form, the transition feels nearly instantaneous.

Handling Mutations with Server Actions

While the primary use case for next/form is navigation-based search, it also excels at handling mutations. You can pass a Server Action directly to the action prop. This allows you to handle POST requests seamlessly, pairing perfectly with useFormStatus to provide real-time UI feedback (like disabling buttons or showing spinners) without needing to manage local state manually.

Conclusion: Embrace Declarative Patterns

It is time to stop writing imperative code for behaviors that the browser already provides natively. By leveraging next/form, we can write cleaner, more maintainable code that is inherently more accessible and performant.

Have you started migrating your search and filter UI to next/form yet? It’s time to clean up that boilerplate and let the framework do the heavy lifting.

DEV Community: Nainik Mehta

Solving the Invisible Update Bug: Read-Your-Writes Guide

The Invisible Update: Understanding Read-Your-Writes Consistency

What Is Happening Under the Hood?

The Anti-Pattern: The Lazy Hack

Three Robust Solutions for Modern Systems

1. LSN-Based Routing (The Gold Standard)

2. Define Strict 'Trust Boundaries'

3. Leverage Optimistic UI

Conclusion: Balancing Consistency and Scale

Fix Next.js Parallel Routes 404 on Refresh | App Router Guide

The Frustration of the Disappearing Dashboard

Soft Navigation vs. Hard Refresh: The Root Cause

The Magic of Soft Navigation

The Reality of Hard Refresh

The Solution: The Power of default.js

Implementing the Fallback Pattern

The Silent Killer: Greedy Catch-All Routes

The Fix: Optional Catch-Alls

Best Practices for Scaling Layouts

Final Thoughts

Why React 19's use() API Can Break the Rules of Hooks

The Paradigm Shift: React 19 and the use API

Why the Rules of Hooks Existed

How the use API Changes the Game

Integration with Suspense and Error Boundaries

The Pitfall: Avoiding Infinite Re-render Loops

The Solution: Stable Promises

Is use a Replacement for Everything?

Conclusion

Database-per-Service is a Trap: Try Logical Schemas

The Database-per-Service Fallacy

The Cost of Premature Isolation

The Pragmatic Alternative: Logical Schemas

Example: Implementing Logical Isolation in Postgres

Why Logical Schemas Win

Conclusion: Build for Your Current Scale

Resilient AI: Multi-Provider LLM Fallback Routing Guide

The Case for Resilience in AI Architecture

Moving Beyond Single-Provider Dependency

Implementing the Fallback Pattern

Key Engineering Takeaways

1. Standardize Your Schemas

2. Monitor the Latency Penalty

3. Track Your Costs

Conclusion

React Context Is Not State Management: Stop Using It

The Architectural Trap: Why React Context Isn't a State Manager

The Mechanics of the Performance Hit

The "Inline Object" Anti-Pattern

A Real-World Performance Impact

When Should You Actually Use Context?

Conclusion: Stop Choking Your Main Thread

Systems Architecture for Agentic AI in Next.js | Nainik Mehta

The Agentic Bottleneck

Rethinking Systems Architecture

The Event-Driven Shift

Tracking the Thought Process

Results and Scalability

The Path Forward

How to Fix LLM Streaming Lag and React Render Storms

The LLM 'Render Storm': Why 50 Tokens/Sec Will Lag Your React App

The Math Behind the Lag

The Frame Budget Reality

The Solution: Decouple Intake from Render

The requestAnimationFrame Pattern

When You Need More: Web Workers and Canvas

Final Thoughts

Stop Treating 'use client' Like a Code Smell in Next.js

The "Server-Everything" Trap

The Cost of Architectural Purity

The Three-Question Audit

Pattern 1: The "Leaf" Pattern

Pattern 2: The "Children" Composition Pattern

Conclusion: Performance is About Balance

React 19 useActionState: 3 Silent Trapdoors to Avoid

Introduction

1. The Stale Closure Trap

The Problem

The Solution

The Solution: The Power of `default.js`

The Paradigm Shift: React 19 and the `use` API

How the `use` API Changes the Game

Is `use` a Replacement for Everything?

The `requestAnimationFrame` Pattern

2. The `isPending` Focus Trap

Introducing `next/form`