DEV Community: Riturathin Sharma

A small architectural shift that made our product feel instant.

Riturathin Sharma — Tue, 24 Feb 2026 07:26:51 +0000

A few months ago, we had a critical problem:

Slow dashboards
Complaints about “laggy UI”
Backend team saying APIs were fast
Frontend team saying rendering was optimized

Everyone was right.
But the product was still slow.

The real issue wasn’t performance.

It was architecture timing.

We were recomputing personalization on every user interaction instead of designing the system around perceived responsiveness.

So instead of optimizing components, we changed the mental model.

❌ Old Thinking

User Action → API → Personalization → Compute → Render UI

Every interaction paid the full cost.

✅ New Thinking

Move intelligence earlier in the lifecycle.

User Login
   ↓
Session Context Build
   ↓
Precomputed UI State
   ↓
Instant Interaction

We introduced session-scoped computation.

A lightweight orchestration layer prepared UI data before users needed it.

Example (simplified)

// Before: compute on every request
async function getDashboard(userId) {
  const recommendations = await computeRecommendations(userId);
  return renderDashboard(recommendations);
}

// After: compute once per session
async function buildSessionContext(userId) {
  const recommendations = await computeRecommendations(userId);

  cache.set(`session:${userId}`, {
    recommendations,
    timestamp: Date.now(),
  });
}

function getDashboard(userId) {
  const sessionData = cache.get(`session:${userId}`);
  return renderDashboard(sessionData.recommendations);
}

Result was amazing

• 42% faster perceived load time
• API calls reduced significantly
• Engineers stopped fighting across layers
• Users described the app as “instant” — without major infra scaling

No fancy framework.
No rewrite.
Just moving computation to the right moment.

What this taught me

Great engineering isn’t about writing more code.

It’s about deciding:

When computation should happen
Where complexity should live
What the user should feel, not just what the system does

I enjoy solving problems exactly like this — where UX, systems thinking, and engineering intersect. I spend most of my time working on performance-driven UI architecture and developer platforms.

Frontend Architecture
Platform UI
Performance & scalability
AI-assisted developer experiences

Conversations with teams tackling similar challenges are always interesting. Always happy to connect and discuss architecture, trade-offs, or product thinking.

Supabase: Why Modern AI Applications Are Choosing Postgres Again

Riturathin Sharma — Sat, 21 Feb 2026 08:00:57 +0000

Backend complexity is quietly becoming optional.

For years, building a production application meant assembling a familiar stack:

A backend framework (Node/Express, Django, etc.)
Authentication system
Database APIs
File storage
Realtime infrastructure
Permissions layer
Deployment pipelines

Even before writing actual product logic, engineers spent weeks building infrastructure.

Then tools like Supabase appeared — and something interesting happened.

Developers started shipping full-stack applications without writing traditional backend code.

This article explains what Supabase actually is, how it works technically, and why it’s becoming especially important in AI and RAG-based applications.

What Is Supabase?

Supabase is an open-source Backend-as-a-Service (BaaS) built around PostgreSQL.

Instead of replacing databases with proprietary systems, Supabase does something different:

It turns PostgreSQL into a complete backend platform.

Supabase combines:

PostgreSQL database
Authentication
Auto-generated APIs
Realtime subscriptions
File storage
Serverless edge functions

All managed under a single platform.

Think of it as:

PostgreSQL + Backend Infrastructure = Supabase
The Core Idea: Your Database Is the Backend

Traditional architecture looks like this:

Frontend → Backend Server → Database

Supabase simplifies it to:

Frontend → Supabase → PostgreSQL

The backend layer doesn’t disappear — it becomes automated.

When you create a table in Supabase:

REST APIs are generated automatically
Permissions are enforced via database policies
Realtime listeners become available instantly
Your database schema effectively defines your API.

Why PostgreSQL Matters

Many backend platforms abstract databases away. Supabase does the opposite.

You get full PostgreSQL capabilities:

relational modeling
joins and transactions
indexing
SQL queries
extensions ecosystem

This is important because real applications eventually need relational data.

Example:

SELECT users.name, projects.title
FROM users
JOIN projects ON users.id = projects.owner_id;

This kind of query becomes painful in NoSQL-first systems but natural in Postgres.

Automatic APIs (Without Writing a Backend)

Supabase exposes database tables as secure APIs automatically.

Example (JavaScript client):

const { data } = await supabase
  .from("projects")
  .select("*");

No server routes.
No controllers.
No ORM setup.

The API layer is generated directly from your schema.

Authentication Without Reinventing Login Systems

Supabase Auth includes:

Email/password login
OAuth providers (Google, GitHub, etc.)
Magic links
JWT-based sessions

But the technically interesting part is how authorization works.

Row Level Security (RLS): Security at the Database Layer

Instead of enforcing permissions in backend code, Supabase uses PostgreSQL Row Level Security.

Example policy:

CREATE POLICY "Users can see their own data"
ON projects
FOR SELECT
USING (auth.uid() = owner_id);

This means:

Even if APIs are accessed directly,the database itself enforces access rules.
Security moves closer to the data — where it belongs.
Realtime Systems Without WebSockets
Supabase streams database changes in real time.

When data changes:

Database update → Realtime event → UI update

Use cases:

chat applications
collaborative tools
dashboards
live notifications

No custom websocket infrastructure required.

Why Supabase Is Exploding in AI Development

Here’s where things get especially interesting.

Modern AI applications need:

user data
conversation history
embeddings
semantic search
realtime responses
secure execution environments Supabase supports this stack surprisingly well.

1. Vector Storage with pgvector

Postgres extension pgvector allows storing embeddings directly in the database.

Text → Embedding → Stored in Postgres → Similarity search

This enables Retrieval Augmented Generation (RAG) systems without separate vector databases.

2. Unified Data + AI Context

Instead of:

App DB + Vector DB + Auth System + API Server

You can use:

Supabase (single platform)

Relational data and embeddings live together.

3. Edge Functions for AI Workflows

Edge functions allow secure execution of:

LLM API calls
document processing
background jobs
webhooks

This becomes the orchestration layer for AI pipelines.

Architectural Shift: Backend-Light Applications

Supabase represents a broader shift:

Engineers are moving from infrastructure engineering to product intelligence engineering.

Instead of building systems around databases, we configure platforms on top of databases.

The developer focus shifts toward:

UX
AI workflows
data modeling
system design

Supabase vs Firebase (Quick Comparison)

Feature Supabase Firebase
Database PostgreSQL NoSQL
SQL Support ✅ ❌
Open Source ✅ ❌
Vendor Lock-in Low High
Relational Queries Excellent Limited
When Supabase Is a Great Choice

Supabase works particularly well for:

✅ AI applications (RAG, copilots)
✅ SaaS platforms
✅ dashboards
✅ collaborative tools
✅ MVPs that need production scalability

When You Might Not Use It

You may prefer a custom backend if:

you need highly complex backend business logic
heavy background processing dominates the system
strict on-prem enterprise constraints exist

Final Thoughts

Supabase isn’t just a productivity tool — it reflects a deeper architectural change.

PostgreSQL is evolving from “database” to application platform.

And as AI-driven products grow, platforms that reduce infrastructure complexity while keeping architectural flexibility will likely define the next generation of web development.

The interesting question isn’t whether Supabase replaces backend engineering.

It’s whether backend engineering itself is being redefined.

Evolution of Frontend Architecture

Riturathin Sharma — Mon, 09 Feb 2026 18:08:41 +0000

One pattern I’ve consistently seen across high-scale frontend systems is this:

Most scaling problems are not React problems. They’re architecture problems.

Framework choice matters far less than how you design boundaries, ownership, and evolution paths.

In the past few years working on enterprise platforms and real-time systems, a few principles have proven far more impactful than any specific library:

• Clear ownership boundaries > shared complexity
Micro-frontends, when done right, are less about technology and more about enabling independent evolution.

• Performance is decided at architecture time, not optimization time
Rendering strategy, data flow, and component isolation matter far more than memoization tweaks later.

• Design systems are scaling primitives, not UI libraries
They reduce cognitive load, align teams, and enable velocity at organizational scale.

• Frontend architecture is platform engineering
The role evolves from building features → to building systems that make building features faster and safer.

At scale, frontend engineering becomes less about components and more about systems design, constraints, and long-term maintainability.

Curious how others have seen frontend architecture evolve as systems and teams scale.

Rethinking State Management in React: A UI Architect’s Deep Dive Into “State Boundaries”

Riturathin Sharma — Wed, 26 Nov 2025 08:24:58 +0000

In the React ecosystem, we’ve spent years debating which state management library to use — Redux, MobX, Recoil, Zustand, Jotai, XState, and the ever-humble React Context.

But the real architectural question we often forget is far more fundamental:

Where should state live?
How far should it travel?
And how do we prevent state from becoming a silent source of UI slowdown?

Let's discuss in depth on an unglamorous yet powerful topic that every UI architect should obsess about:

State Boundaries — The Most Important Concept in Scalable React Apps

State boundaries define how far a piece of state is allowed to influence the UI.

If your components re-render “too much,” lag under load, or behave unpredictably, the root cause 90% of the time is:

Your state boundaries are broken.

Let’s understand this architecturally.

1. Why State Boundaries Matter More Than the Library You Choose

Most engineers think state problems are library problems:

“Redux is too verbose”

“Context causes re-renders”

“Zustand feels easier”

“useState is enough for everything”

“React Query replaces global state”

…but performance issues rarely stem from the library. They stem from incorrect scoping.

Poor state boundaries → excess re-renders → wasted CPU → janky UI.

A simple example:

// ❌ Anti-pattern
<App>
  <Navbar user={user} />
  <Sidebar user={user} />
  <Dashboard user={user} />
</App>

You’ve just created a gigantic state boundary — one tiny state change in user will re-render half the application.

Now imagine 200 components relying on the same global state.
This is how “React feels slow” stories are born.

2. The Architect’s Rule: “State Should Be as Local as Possible”

React is built on the idea of locality of state.

A simple rule:

Move state down until it stops mattering to everyone above it.
Move shared state up only when two siblings need it.

Micro Example:

A toggle button controlling its own UI.

function Toggle() {
  const [on, setOn] = useState(false);
  return <button onClick={() => setOn(!on)}>{on ? "ON" : "OFF"}</button>
}

Perfectly local. No need for global state. No need for context. Zero re-renders outside the component.

Macro Example:

A user object needed by 15 components across the page.

Context or Zustand makes sense here.

But what if only two components need the user’s theme preference?
Then create a smaller local boundary:

User State (global)
├── Theme Preference (local to UI shell)
└── User Metadata (local to specific feature)

Architectures break when everything is global “just in case.”

3. The Hidden Performance Killer: “Derived State Leaks”

A subtle but deadly anti-pattern:

const user = useUserStore(state => state.user);

const isAdmin = user.role === 'admin';  `// ❌ derived but inside` global boundary

This component now re-renders whenever anything inside user changes — phone number, profile pic, status, anything.

Fix: keep derived state as close to its usage as possible.

const isAdmin = useUserStore(state => state.user.role === 'admin'); // ✔ only re-renders when role changes

You've just reduced re-renders by 90%.

4. State Machines: Creating Predictable Boundaries

One of the cleanest ways to define strict state boundaries is using UI state machines (XState or custom).

Example: A checkout UI.

const checkoutMachine = {
  id: "checkout",
  initial: "cart",
  states: {
    cart: { on: { NEXT: "address" }},
    address: { on: { NEXT: "payment", BACK: "cart" }},
    payment: { on: { NEXT: "review", BACK: "address" }},
    review: { on: { SUBMIT: "complete", BACK: "payment" }},
    complete: {}
  }
}

Here, each boundary is a strict, predictable “mode.”

Why is this beneficial?

- UI cannot accidentally access out-of-scope state
- Reduces invalid transitions
- Less conditional UI logic (“if cart then… else if payment then…”)
- Fewer re-renders since each state is independent

5. How to Design State Boundaries in a Real Project (Architect’s Checklist)

✔ Step 1:
Identify State Types

Local UI state (modals, text inputs)
Server state (React Query / SWR)
Global app state (theme, auth, settings)
Ephemeral UI logic (hover, focus, scroll)

✔ Step 2: Assign State Ownership

Local state → useState, useReducer
Shared UI state → Context (carefully)
Large-scale global logic → Zustand / Redux
Data fetching → React Query
Flow control → state machines

✔ Step 3: Prevent State Leakage

Map state slices with selectors
Avoid passing entire objects down props
Memoize expensive selectors
Use “compound component patterns” for local boundaries

✔ Step 4: Measure before optimizing

Use:

React DevTools Profiler
Flamegraph
Why Did You Render (WDR)
Browser performance panel

If a boundary causes 30+ rerenders, consider splitting it.

Example: A Poorly Architected Component Tree

<App>
  <UserProvider>          // global and huge
    <Layout>
      <Sidebar />
      <Dashboard />
      <Notifications />
      <Search />
      <Profile />
    </Layout>
  </UserProvider>
</App>

If user changes → everything re-renders.

Same App With Better State Boundaries

<App>
  <AuthProvider> // only login/logout
    <Layout>
      <UserPreferencesProvider> // theme, language
        <Sidebar />
        <Profile />
      </UserPreferencesProvider>

      <Dashboard /> // fetches its own data

      <NotificationProvider>
        <Notifications />
      </NotificationProvider>

      <Search /> // local debounced state
    </Layout>
  </AuthProvider>
</App>

Each provider now has:

isolated re-renders
purpose-specific state
predictable ownership
This is real UI architecture.

The Takeaway (And What Most Engineers Miss)

React doesn’t get slow because:
“React is slow”
“Context is bad”
“Redux is heavy”

React gets slow because state boundaries are drawn carelessly.

A UI Architect’s job isn’t to decide between Redux or Zustand.
It is to decide where state should live and where it shouldn’t.

When boundaries are clean:

Features become independent

Re-renders shrink

Debugging becomes trivial

Onboarding becomes easier

Performance becomes natural—not an afterthought

Final Thoughts

In a world obsessed with new React libraries, one of the most traditional—and most overlooked—topics remains the true pillar of scalable UI architecture:

State Boundaries decide whether your React app survives scale or collapses under it.

If you master this, tools become replaceable.
Architecture becomes future-proof.
Teams become faster.

And your React UI becomes predictable, fast, and delightful.

Rethinking Frontend Scalability: The “UI Composition Architecture” Pattern for Large React Applications

Riturathin Sharma — Thu, 20 Nov 2025 11:13:56 +0000

When your React application grows beyond a few feature modules, you begin to feel pain:
• Components become too tightly coupled
• Teams accidentally overwrite each other’s UI behavior
• Feature releases require risky regression cycles
• Reusable components… aren’t really reusable
• Code reviews turn into debates on folder structure

As UI Architects, our job is to design UI systems that scale, not just UI screens.

One of the most powerful architectural approaches I’ve used in large-scale frontend apps (50+ developers, multi-year lifespan) is the UI Composition Architecture.

This post breaks down the pattern with concepts, diagrams, examples, and real-world React code you can try immediately.

What Problem Does UI Composition Solve?

Traditional React architecture looks like this:

Pages → Feature Modules → Widgets → Components → UI Elements

Works great… until:
• Two teams need to extend the same screen
• A feature needs to plug into multiple pages
• A global rule (e.g., dark theme, tracking, A/B test) must wrap UI without modifying every page
• You need to ship new UI without touching “core” code

UI Composition flips the mental model.

Instead of pages owning components, components own behaviors, and pages compose them.

⸻

The Core Idea: Behavior is a Plugin, Not a Hardcoded Feature

Instead of a giant “God Page,” you have:

Base Layout + Registrable UI Slots

┌─────────────────────────────┐
│ Page Layout │
│ ┌──────────┐ ┌──────────┐ │
│ │ Slot A │ │ Slot B │ │
│ └──────────┘ └──────────┘ │
│ ┌──────────┐ │
│ │ Slot C │ │
│ └──────────┘ │
└─────────────────────────────┘

  ↓ Features register ↓

Feature 1 → Slot A
Feature 2 → Slot B
Feature 3 → Slot C

This makes UI extensible, testable, and team-friendly.

⸻

A Real Example: Pluggable Dashboard Widgets in React

Consider a dashboard where different teams own different widgets.

Define a Slot Component

// framework/Slot.js

export const Slot = ({ name, registry }) => {
  const Component = registry[name];
  return Component ? <Component /> : null;
};

Create a Central Widget Registry

// framework/registry.js

export const widgetRegistry = {};

 export const registerWidget = (name, component) => {
   widgetRegistry[name] = component;
 };

The Dashboard Layout Uses Slots

// pages/Dashboard.jsx

import { Slot } from "../framework/Slot";
 import { widgetRegistry } from "../framework/registry";

 export default function Dashboard() {
  return (
    <div className="dashboard">
      <div className="left-panel">
        <Slot name="weather" registry={widgetRegistry} />
        <Slot name="news" registry={widgetRegistry} />
      </div>

      <div className="right-panel">
        <Slot name="profile" registry={widgetRegistry} />
        <Slot name="trends" registry={widgetRegistry} />
      </div>
    </div>
  );
}

Teams Independently Register New Widgets

Team weather:

`
import { registerWidget } from "../../framework/registry";

const WeatherWidget = () => (

☀️ Current Temperature: 28°C
);

registerWidget("weather", WeatherWidget);
`

Team trends:

// features/trends/index.js

`
import { registerWidget } from "../../framework/registry";

const TrendsWidget = () => (

📈 Trending Searches: React, AI
);

registerWidget("trends", TrendsWidget);
`

Result?

Without modifying Dashboard.jsx, you can add:
• A new widget
• A new behavior
• A different version (A/B testing)
• User-based personalization

This pattern scales incredibly well in real enterprise applications.

⸻

Why This Pattern Works (Architectural Advantages)

✔ Zero coupling

Features plug into slots — no imports, no dependencies, no cross-team breaking changes.

✔ Continuous Delivery

Teams ship independently without touching layout code.

✔ Powerful Customization

Just register different components per tenant, role, or feature flag.

✔ Perfect for Micro-Frontends

Each widget can even be loaded as a federated module (Module Federation).

✔ Enables “Dynamic UI”

UI becomes a dynamic system, not a static tree.

⸻

Optional: Slot with Props Injection

A more advanced slot allows the layout to pass context:

export const Slot = ({ name, registry, props }) => {
const Component = registry[name];
return Component ? : null;
};

Now we can do:

Widget:

const WeatherWidget = ({ city }) => (

Weather in {city}: 29°C
);

Real-World Use Cases You Can Implement

Role-based UI
• Admin sees 6 widgets
• User sees 3
• Guest sees only 1
No branching logic on the page.
Marketplace Extensibility

Plugins from 3rd-party developers.

Experimentation (A/B Testing)

Theming

Slots can even swap different component trees for entire themes.

Multi-tenant SaaS

Different clients get different UI behavior.

⸻

Final Thoughts

As UI Architects, our goal is to build systems that:
• allow rapid iteration
• scale organizationally
• remain flexible for years
• empower teams to build without stepping on each other

UI Composition Architecture is one of the most pragmatic and powerful ways to achieve that.

If your app feels “rigid” or “hard to extend,” try introducing Slots + Registries into your architecture — your future self (and your developers) will thank you.

Implementing custom functions in Arrays

Riturathin Sharma — Tue, 10 Jan 2023 08:13:58 +0000

There are quite a lot of handy functions in Javascript arrays that developers can easily use. Some of these are higher-order-functions like map, reduce and filter. Apart from these there are lot of other functions too like flatten, splice etc. We would be looking into re-creating some of the functions out of scratch.

Flatten

Flatten method takes a depth as parameter and converts an array containing arrays into an array of plain primitives.

e.g

let arr = [1,2,[3,4],5]; arr.flat(1); // outputs [1,2,3,4,5]

We can pass any numeric value to flatten the Array data-structure to the level of depths. Let's try to mock this function and create our own custom implementation.

First let's go ahead and create a function called myFlatFn that takes an array. Initially we will try to implement the function in such a way that it doen't take any flattening parameter. We will try to return the entire array flattened into a single array.

For this, we need to think of a recursive approach. We will take a for loop for looping through all the elements. We need to check if at any index, the value is an array or not. If it's an array, we will pass the array at that index into our custom myFlatFn. We then return the array from the function.

After this the callstack moves back to the original index + 1 and we continue to repeat the above steps till we have traversed the entire array. In the final step we return our result. Code is written below

Array.prototype.myFlatFn = function() { 
   let res = [];
   if( depth === undefined ) {
      for( let i = 0 ; i < this.length; i++ ) {
         if( !Array.isArray(this[i]) ) res.push(this[i]);
         else{
            let flattened = this[i].myFlatFn();
            res = [...res, ...flattened ]
         }
      }
   }

return res
}

So, we have got the custom implementation for custom flat without a depth value. Now , let us try to implement the implementation when we have a depth parameter passed.

What change do we need to make to our previous implementation here? If we observe closely, we can see that the depth value will flatten the array to a point where the depth of any index of the original array is > 0 . Let's try to grab out heads around this.

Suppose , we have an array

[1,2,[3,4,[5,[6, [7,8]]]]]

and we pass a depth of let's say 2. So , we continue to flatten our array till we have a flattened structure <= 2 . it means, if we check the ...[5,6,[7,8]]] value, it is at a depth of 4. So, we need to keep flattening it to depth <= 2. Max depth will be 2. We will still be left off with a depth of 4-2 = 2. Hence , we can't flatten the ...[5,6,[7,8]]] beyond ...[6,[7,8]]. Let's try to implement the code now.

Array.prototype.myFlatFn = function(depth) { 
    let res = [];
    if( depth ===undefined ) {
      for( let i = 0 ; i < this.length; i++ ) {
        if( !Array.isArray(this[i]) ) res.push(this[i]);
        else{
          let flattened = this[i].myFlatFn();
          res = [...res, ...flattened ]
        }
      }
    }else{
        for( let i = 0 ; i < this.length; i++ ) {
        if( !Array.isArray(this[i]) ) res.push(this[i]);
        else{
           if( depth > 0 && depth ) { 
              let flattened = this[i].myFlatFn(depth-1);
              res = [...res, ...flattened ]
           }else{
              res.push(this[i])
           }
         }
      }
   }
   return res
}

The key here is the recursion which we need to handle based on whether the array element at index i is an array or not.

Let's finally refactor our code to give a more concise look.

Array.prototype.myFlatFn = function(param) { 
   let res = [], arr = this ; 
   for( let i = 0 ; i < arr.length; i++ ) {
      if( param === undefined ) {
         if( !Array.isArray(arr[i]) ) res.push(arr[i])
         else{
            let flattened = arr[i].myFlatFn();
            res = [...res, ...flattened ]
         }
      }else if( param >= 0 && param !== undefined) { 
         if( !Array.isArray(arr[i]) ) res.push(arr[i])
         else {
           let flattened = arr[i].myFlatFn(param-1);
           res = [...res, ...flattened ]
      }
    }
    else res.push(arr[i])
  }
  return res
}

So, we have successfully implemented our own flatten function. This can be extended to any array in Javascript

Map

Another useful utility function in Javascript is the map function. Along with reduce and filter, the map functions is a convenient way to perform some operation on each element of a given array. We are going to discuss each of these functions in details and try to replicate the same with our custom implementation.

First of all what does map function do. Well, it takes a function and an array and returns a modified array with each element in the array converted based on the function provided. Let's see an example

let arr = [1,2,3,4,5] ;
arr.map( el => el*el ) // Outputs the squares of each element .i.e. [ 1,4,9, 25]

The result is straightforward. It squares each element in the array. How can we achieve this?

We need to initialize an array, let's just say result and then keep pushing each element from the original array to the result array after the operation. We will try to understand this with code.

Array.prototype.customMap = function( fn ) {
   let result = [];
   for( let i of this ) 
      result.push( fn(i) )
      return result;
}

So, what have we done? We are just taking each element in the array, taking the transformer function(fn) and applying it to each of them before pushing it to the result array. Finally , we are just returning the result. Thus we have completed our custom map function too. Let's move to the filter function.

Filter

Just like map, filter also returns a modified array based on a condition being passed as a parameter and filters out all the elements that don't pass the specific condition. Let's see an example.

let arr = [1,2,3,4,5,6,7] ;
arr.filter( el => el > 3 ); // returns a new array 
[4,5,6,7] in this case

So, how can we implement this. Simple. We need to have the same "result" array and keep pushing any element that satisfies the passed condition before finally returning the result array. Let's see this with the help of code

Array.prototype.customFilter = function(condition){
   let result = [];
   for( let i of this )
      if( condition(i) ) result.push(i)
   return result
}

We have now successfully implemented a custom filter function in Javascript.