DEV Community: Akshay Sarak

📦 Container Queries Changed Everything for Me

Akshay Sarak — Sun, 14 Jun 2026 17:08:58 +0000

For a long time, I believed responsive design meant writing media queries for different screen sizes. It felt like the only correct way to make interfaces adapt. So, like most developers early on, I built layouts around viewport breakpoints: mobile, tablet, desktop — each carefully tuned to match screen width.

It felt organised at first. However, over time, that sense of control gradually started breaking down.

💥 The Problem Begins Quietly

Initially, everything seemed smooth. Layouts responded correctly, components adjusted based on screen size, and most UI elements behaved as expected. There was a strong sense of predictability when designing for fixed breakpoints.

But problems didn’t appear immediately. They started quietly. A component that looked perfect on a page would break when reused inside a sidebar. The same card that worked in a grid layout would collapse inside a modal. Small layout inconsistencies started appearing in different parts of the application.

What once felt like a reliable responsive system slowly transformed into a collection of components that behaved differently depending on where they were placed.

🧠 The Real Issue Was Never Responsiveness

Initially, I thought responsive design meant adapting everything to screen sizes. That made sense when pages were the primary unit of design.

However, the real problem was that I wasn’t designing for components; I was designing for screens.

In real applications, components are reused across different contexts. A component doesn’t care about the full viewport — it only cares about the space available to it inside its parent container.

When this distinction is ignored, responsiveness becomes inconsistent and fragile.

⚙️ The Shift: Container-Based Thinking

Switching from media queries to container queries didn’t feel like a small CSS upgrade at first. It felt like a shift in how I think about UI structure.

Rather than designing components based on global breakpoints, each component started responding to its own container. A layout no longer depended on screen size assumptions. Instead, it adapted based on actual available space.

This structure changes your perspective on design. Instead of managing global responsiveness rules, you start building components that are self-aware of their environment.

⚡ Container Queries’ Arrival

Media queries alone are not sufficient for modern component-based systems. As applications grow, relying only on viewport-based logic introduces too many constraints.

Container queries changed this.

The first major improvement is local responsiveness. Components adapt based on their parent container instead of the global viewport.

The second improvement is true reusability. The same component can behave differently in a grid, sidebar, modal, or full-page layout without requiring separate styles.

The third improvement is reduced dependency on breakpoints. Layout decisions move closer to the component itself instead of being scattered across global CSS rules.

This transforms responsive design from being page-driven to being component-driven.

🧠 The Mental Shift

The most significant change isn’t technical, but conceptual.

Initially, the mindset was to design for devices, assuming that screen size is the primary factor in layout decisions.

However, working with container queries shifts this perspective. Instead of designing for screens, you start designing for space. Instead of asking what device is being used, you start asking how much room the component actually has.

Container queries don’t replace media queries; they redefine what responsiveness means in a component-driven world.

🚀 What Actually Improved

Once container queries are introduced, the improvements become immediately noticeable in real UI systems.

Components become truly reusable without layout overrides. Styling becomes more predictable because it reacts to actual container dimensions. Design systems become easier to maintain because responsiveness is encapsulated inside components rather than spread across breakpoints.

Instead of rewriting styles for different layouts, the same component simply adapts itself naturally to its environment.

⚠️ Container Queries Aren’t a Full Replacement

While powerful, container queries are not a complete replacement for media queries. Global layout decisions still require viewport awareness, especially for page-level structure and major breakpoints.

Without proper balance, relying only on container queries can lead to confusion in large layout systems. Both approaches need to coexist depending on the level of design control required.

🧩 When Container Queries Make Sense

Container queries are most useful when building reusable components, design systems, and modular UI architectures where components are expected to live in multiple contexts.

However, if the layout is strictly page-based and components are not reused across different containers, traditional media queries may still be sufficient.

🔮 Final Thought

I didn’t adopt container queries because they were new or modern. I started using them because media queries stopped matching how I naturally think about UI systems.

Once you begin designing for components instead of screens, responsiveness stops feeling like a set of breakpoints and starts feeling like a property of the component itself.

Building a RAG pipeline in a weekend

Akshay Sarak — Sun, 14 Jun 2026 16:58:32 +0000

For a long time, I assumed building AI applications meant working with complex research papers, large ML pipelines, and systems that were far beyond typical full-stack development. Things like embeddings, vector databases, and retrieval systems felt like separate worlds from normal web apps.

So whenever I thought about “AI-powered features,” I instinctively focused on the model itself and assumed the rest would be the hard part.

That assumption turned out to be wrong.

🔍 The Problem Starts Quietly

Initially, everything seemed simple on the surface. You take a document, pass a query to an LLM, and expect intelligent responses. The system appears to work, and for small examples, it does.

However, as soon as real data enters the picture, problems start appearing. The model begins hallucinating facts. It confidently answers questions that are not present in your documents. It struggles with domain-specific knowledge. Even worse, it behaves differently depending on how the question is phrased.

Nothing seems broken at the system level, but the outputs are no longer reliable.

The surprising part is that the model itself isn’t failing in the traditional sense. The issue is that it simply doesn’t have access to the right context.

Something fundamental is missing.

🧠 The Real Issue Was Never the Model

My first instinct was to assume the model needed improvement. Maybe better prompting, maybe a stronger model, maybe fine-tuning.

However, after breaking down the problem, it became clear that the model wasn’t the real issue.

The real issue was missing context at runtime.

LLMs are trained on general knowledge, but they are not aware of your private documents, product data, or application-specific information. Every question is answered based on probability, not grounded truth.

So even when the model sounds confident, it is often guessing.

The problem wasn’t intelligence.

The problem was access.

📊 Understanding the Cost of Missing Context

Many developers assume that prompting alone is enough to control model behavior.

In reality, prompt engineering without context has strict limitations.

An LLM must rely entirely on what it already knows, which means:

private data is invisible
domain-specific knowledge is incomplete
factual grounding is inconsistent
answers degrade as complexity increases

Individually, these issues seem minor. Collectively, they make production AI unreliable.

A model without context may look smart.

But it is not grounded.

⚡ Retrieval Changed Everything

Rather than trying to force the model to “know more,” the approach shifts completely.

Instead of increasing model intelligence, we introduce retrieval.

This is where the RAG pipeline begins.

Before generating an answer, the system first searches relevant documents. Only the most relevant chunks are passed into the model as context.

Now the model is no longer answering blindly.

It is answering with reference material.

🔬 Pattern #1: Chunking Changes Everything

One of the first critical insights is that documents cannot be treated as whole units.

Large documents must be split into smaller chunks so they can be meaningfully retrieved.

At first, this seems like a simple preprocessing step, but it directly affects system accuracy.

Poor chunking leads to irrelevant retrieval. Good chunking leads to precise answers.

The quality of the entire system often depends more on chunking strategy than on the model itself.

🧠 Pattern #2: Embeddings Are Not Just Data

The next step is converting text into embeddings.

Initially, embeddings feel like a technical detail. Just a way to store text in vector form.

But in reality, embeddings define how the system understands meaning.

Similar ideas are placed closer together in vector space, even if the wording is different. This enables semantic search instead of keyword search.

At this point, the system stops matching words and starts matching intent.

🗄️ Pattern #3: Retrieval Becomes the Real Intelligence Layer

Once embeddings are stored in a vector database like MongoDB Atlas Vector Search, retrieval becomes the most important part of the system.

When a query is made, it is also converted into an embedding. The system then searches for the closest semantic matches and retrieves relevant chunks.

This step becomes the real intelligence layer of the architecture.

The model is no longer responsible for “knowing everything.”

It is only responsible for reasoning over retrieved context.

🤖 Pattern #4: Generation Becomes Grounded

Once relevant context is retrieved, it is passed into the LLM along with the user query.

Instead of asking:

“Answer this question”

The system now asks:

“Answer this question using the provided context”

This single shift changes everything.

Responses become more accurate, more stable, and more aligned with real data.

The model stops hallucinating because it is no longer operating in isolation.

⚡ What Actually Improved

Once the RAG pipeline is in place, the behavior of the system changes noticeably.

Responses become grounded in actual documents. Hallucinations reduce significantly. Domain-specific accuracy improves. The system becomes capable of answering questions it could never handle before.

The application does not become more intelligent.

It becomes more informed.

🏛️ RAG Is Not an AI Feature

Before building this, I thought RAG was an advanced AI technique.

What I learned instead is that RAG is a system design pattern.

It combines:

search systems
data pipelines
vector databases
LLM reasoning

At its core, it is not about artificial intelligence.

It is about combining retrieval with generation in a controlled way.

🔮 Final Thought

RAG systems rarely fail because of the model.

They fail because of poor retrieval design.

By the time outputs look wrong, the issue is usually already in chunking, embeddings, or search quality.

The biggest lesson wasn’t learning how to use an LLM.

It was understanding that modern AI systems are not just models — they are architectures built around information flow.

Once you start thinking in that direction, building AI applications stops feeling like research and starts feeling like engineering.

The Real Cost of Re-renders in React..💸

Akshay Sarak — Sun, 14 Jun 2026 15:43:16 +0000

For a long time, I assumed React performance issues were usually caused by slow APIs, inefficient algorithms, or expensive database queries. Re-renders never felt like a serious concern. After all, React is designed to update the UI efficiently.

So whenever I noticed a sluggish interface, I instinctively looked everywhere except the component tree.

That assumption turned out to be wrong.

🔍 The Problem Starts Quietly

Initially, everything seemed fine. Components rendered correctly, interactions felt responsive, and development was smooth. There were no obvious signs of performance issues.

However, as the application grew, small delays began to appear. A simple interaction would occasionally feel sluggish. Certain screens became noticeably slower after new features were added. Nothing seemed broken, but the experience no longer felt as responsive as it once had.

The surprising part was that the backend wasn't the problem. Network requests were fast, database queries were efficient, and API responses arrived quickly. Yet users still experienced delays.

Something else was happening beneath the surface.

🧠 The Real Issue Was Never React

My first instinct was to blame React itself. Surely the framework was doing too much work.

However, after profiling the application, it became clear that React wasn't the problem.

The real issue was unnecessary rendering.

A single state update was triggering large portions of the component tree to render again. Components that had no relationship to the changed data were still executing their render logic. What appeared to be one update was actually dozens of updates happening throughout the application.

The problem wasn't that React was slow.

The problem was that I was asking React to do far more work than necessary.

📊 Understanding the Cost of Re-renders

Many developers assume that if the UI doesn't visibly change, a re-render doesn't matter.

In reality, every render still has a cost.

React must execute component functions, evaluate hooks, recalculate JSX, compare virtual DOM trees, and determine whether updates should be committed to the browser.

Individually, these operations are inexpensive. Collectively, they become surprisingly costly when repeated across a large application.

A single unnecessary render may not matter.

Hundreds of unnecessary renders absolutely do.

⚡ Profiling Changed Everything

Rather than immediately reaching for optimisation techniques, I decided to measure the problem first.

Using the React Profiler revealed something I hadn't expected.

The application wasn't suffering from a single expensive component. Instead, it was suffering from a large number of inexpensive components rendering repeatedly.

The issue wasn't concentrated in one place.

It was distributed throughout the system.

That changed how I approached optimisation entirely.

🔬 Pattern #1: Keep State Close to Where It's Used

One of the biggest issues came from state placement.

Over time, state had gradually moved higher and higher in the component hierarchy. It seemed convenient at first, but every update forced large sections of the application to render again.

The solution wasn't adding optimisation hooks.

It was improving architecture.

By keeping state closer to the components that actually consumed it, render boundaries became smaller and updates became more isolated.

The result was fewer unnecessary renders and a much more predictable component tree.

🔗 Pattern #2: Stabilise References Intentionally

The second issue involved objects and functions being recreated on every render.

From React's perspective, a newly created object is different from the previous one, even if it contains the same values. The same applies to functions.

This meant child components were re-rendering simply because their props appeared to change.

Using tools like React.memo, useMemo, and useCallback helped stabilise these references and reduce unnecessary updates.

The important lesson wasn't to memoise everything.

It was to understand why a component was rendering in the first place.

🏗️ Pattern #3: Create Better Rendering Boundaries

Several components had gradually accumulated too many responsibilities.

They handled state, data fetching, business logic, and UI rendering all at once.

As these components grew, even small changes caused large portions of the interface to re-render.

Breaking them into smaller, focused components introduced natural rendering boundaries. Updates became more targeted, and React had significantly less work to perform.

Sometimes performance improvements don't come from optimisation.

They come from better component design.

⚡ What Actually Improved

Once these changes were applied, the difference was immediately noticeable.

Render counts dropped significantly. User interactions became more responsive. Profiling traces became cleaner and easier to reason about. Most importantly, the screen that previously took nearly 800ms to update was now completing the same interaction in roughly 60ms.

The application didn't gain any new features.

It simply stopped performing unnecessary work.

🏛️ Performance Is Often an Architecture Problem

Before this experience, I viewed React performance primarily as an optimisation problem.

I assumed the solution was more memoisation, more hooks, or more advanced techniques.

What I learned instead was that performance is often a consequence of architecture.

Poor state boundaries create unnecessary renders. Large components create unnecessary work. Unstable references create unnecessary updates.

React wasn't slow.

My component structure was.

🔮 Final Thought

Performance issues rarely appear overnight. They accumulate gradually as applications grow and complexity increases.

That is what makes them difficult to spot.

By the time users notice lag, the underlying rendering problem has often existed for months.

The biggest lesson wasn't learning a new optimisation technique.

It was understanding that every state update has a cost, and every re-render should have a reason.

Once you start thinking about React through that lens, performance stops being something you fix at the end and becomes something you design for from the beginning.

Why I stopped fighting monorepos..

Akshay Sarak — Sun, 14 Jun 2026 14:54:06 +0000

For a long time, I believed monorepos were overkill. They seemed like something only “big companies” used because they had too much code and not enough structure. So, like most developers early on, I split everything into separate repositories: frontend in one, backend in another, and shared code in a “cleanly isolated” place.

It felt organised at first. However, over time, that sense of clarity gradually eroded.

💥 The Problem Begins Quietly

Initially, everything seemed smooth. Each repository was independent, each service isolated, and there was no visible coupling between systems. This gave a strong sense of clean architecture.

But problems didn’t appear immediately. They started quietly. A shared function might be updated in one place, but another repository wouldn’t reflect that change. Types slowly diverged, and imports that once worked silently stopped. Eventually, bugs only appeared in production, not during development.

What once felt like a clean separation slowly transformed into multiple systems that no longer fully agreed with each other.

🧠 The Real Issue Was Never Separation

Initially, I thought I was practising proper modular design by splitting everything into different repositories. I believed I was reducing complexity.

However, the real problem was that I wasn’t separating concerns; I was separating context.

In real applications, much logic is naturally shared. Validation rules, API contracts, UI components, utility functions, and types aren’t independent pieces. They’re part of the same system.

When this shared logic is split across multiple repositories, complexity doesn’t disappear; it simply shifts into synchronisation problems between systems.

⚙️ The Shift: Monorepo Thinking

Switching to a monorepo didn’t feel like a tooling decision at first. It felt like a shift in how I thought about code structure.

Rather than maintaining separate repositories for frontend, backend and shared logic, everything consolidated into a single structured system. Logically, applications and packages remain distinct but reside within a unified codebase.

This structure shifts your perspective on code relationships. Instead of managing multiple independent systems, you now oversee a connected one.

⚡ Turborepo’s Arrival

Monorepos alone aren’t sufficient for efficient problem-solving. Without appropriate tooling, they can become cumbersome and slow.

Turborepo revolutionised this.

The first major improvement is intelligent caching. Rather than rebuilding everything repeatedly, only the system’s changing components are rebuilt.

The second improvement is pipeline execution. Tasks like build, test and lint run in a structured dependency order automatically, eliminating manual management.

The third improvement is dependency graph awareness. The system comprehends package connections, eliminating the need for manual coordination.

This transforms the monorepo from feeling heavy to efficient.

🧠 The Mental Shift

The most significant change isn’t technical, but mental.

Initially, the mindset was to split code to reduce complexity, assuming separation inherently simplifies system management.

However, working with monorepos shifts this perspective. Instead of splitting code to reduce complexity, you group it to control it.

Monorepos don’t eliminate complexity; they make it visible, structured and easier to manage as a single system.

🚀 What Actually Improved

Once everything migrated to a monorepo, the improvements became evident in daily development.

Shared code became genuinely shared rather than duplicated, improving type safety as everything existed in a single synchronised system. Testing became more consistent due to a single source of truth, leading to a more predictable and less fragmented developer experience.

Instead of switching between multiple repositories, everything resided in one place, creating a more connected workflow.

⚠️ Monorepos Aren’t a Magic Solution

While powerful, monorepos aren’t magic and come with their own challenges. Initial setup becomes more complex, CI/CD pipelines require advanced features and discipline is needed to maintain the structure. Tooling also plays a crucial role in ensuring efficiency.

Without proper structure, a monorepo can become just as messy as multiple separate repositories.

🧩 When Monorepos Make Sense

Monorepos are suitable when multiple applications share logic, components are reused across projects, strict type consistency is essential and scalability is a priority.

However, if systems are truly independent and don’t share meaningful logic, a monorepo may introduce unnecessary overhead rather than solving problems.

🔮 Final Thought

I didn’t adopt monorepos because they were trendy or popular. I switched because multiple repositories conflicted with my natural system thinking.

Once you view software as a connected system rather than isolated parts, monorepos cease feeling like an option and become a structure that finally makes sense.