When I started learning UI/UX design back in 2020—during those early pandemic lockdown days when we were all stuck inside—I had no idea it would fundamentally shape how I approach software development today.

The Design Obsession Begins

I remember being completely overwhelmed at first. Grids, typography, color theory, composition—it all felt like too much. But I pushed through. I'd sketch layouts on paper for hours, experiment with spacing, play with different typefaces. Figma wasn't even on my radar back then. I was just trying to understand the fundamentals through raw practice.

Then something clicked.

I realized how profound design actually is. Think of it this way: a Ferrari with a terrible interior and confusing controls wouldn't appeal to anyone, no matter how powerful the engine is. Conversely, a simple Honda Civic with an intuitive, beautiful interior can feel premium and sell exceptionally well. Design doesn't just make things look good—it makes things work good.

This principle exists across the entire development lifecycle too. In traditional waterfall methodology, the design phase often comes first, then developers build. But I learned that the best products aren't made by designers throwing mockups over the wall—they're made when designers and developers collaborate as equals.

The Bridge to Development

After spending months creating high-fidelity designs, I hit a wall. I had all these beautiful mockups, but they were static. Lifeless. I wanted to see them come alive—to feel responsive, to actually solve problems for real users. So I did what any curious person would do: I started learning React.

And I was hooked.

Building that first interactive component felt like magic. Suddenly, design wasn't just about aesthetics anymore—it was about logic, state management, user interaction. I went deeper into frontend development, then backend, and eventually into DevOps and AI. Each layer revealed something new about how systems actually work.

But here's what matters: I never stopped thinking like a designer.

How Design Made Me a Better Developer

My UI/UX background fundamentally changed how I write code today:

I think about user experience before I write a single line of code. Before architecting APIs, I sketch out the user journey. Before optimizing a database query, I consider the latency impact on the actual user experience. Before designing a system, I map out how teams will interact with it.

I understand the relationship between form and function. Just like bad UI design ruins a great product, bad system design ruins good code. I learned early that you can't just build features—you have to build experiences.

I communicate better across teams. Designers speak in flows and wireframes. Developers speak in architecture and databases. Because I've lived in both worlds, I can translate between them. This alone has made me invaluable in cross-functional teams.

I care more about what I build. When you understand design, you care about every pixel, every animation, every interaction. That mindset translates to backend development—caring about every API endpoint, every database schema, every system component. It's the difference between coding and craftsmanship.

Still Designing, Just Differently

People sometimes ask if I miss design. The truth is, I never left it. I just expanded what I design. Now I design systems. I design architectures. I design the invisible infrastructure that makes user experiences possible.

The work that got me here—those sketches on paper, those hours experimenting with layouts—they taught me something that no bootcamp can teach: how to think about problems holistically. How to see the big picture while obsessing over details. How to balance aesthetics with functionality.

If you're in a similar position—whether you're considering switching between design and development, or you're wondering if your background in one field matters in another—let me tell you: your journey is an asset, not a liability. The skills don't disappear when you pivot. They evolve.

I'm still learning. I'm still curious. And every line of code I write, I'm still thinking about the human on the other end who'll experience it.

That's what design taught me.

Building an edit profile page sounds straightforward until you realize just how much data you're dealing with.

The Problem I Didn't See Coming

A few months ago, I was tasked with building a profile edit feature. Simple enough, right? But when I started mapping out what needed to be displayed, the scope exploded:

• User details and account info

• Badges earned

• Question count

• Total upvotes received

• Number of community rooms joined

• Plus all those other contribution metrics

It was a lot. Everything a user would want to see about their presence in the community.

My initial instinct? Make an API call for each piece of data. So I created multiple endpoints and planned to call them all inside a useEffect hook on the frontend. Load them in parallel, merge the data, and we're done.

Then it hit me.

The Cost Realization

What happens when you have thousands—or millions—of users each loading their profile? Each user triggers 5, 6, or 10 separate API calls. And each of those calls hits the database. The server load multiplies. The costs multiply. Eventually, this scales into a real problem.

I needed a different approach: fetch all the data in a single API call instead.

The Complication

Here's where things got tricky. I was using MongoDB as my primary database, and I'd organized my data across multiple collections (a smart move for data integrity and organization). But now I needed to:

1. Query the user collection

2. Fetch related data from several other collections

3. Join them together based on IDs

4. Build a single payload

5. Send everything in one response

If I'd been using MySQL with foreign keys, this would've been straightforward. But MongoDB? That's different.

The Discovery

That's when I discovered MongoDB aggregation pipelines.

I knew the concept existed—I'd heard it mentioned—but I'd never actually used one. So I did what any developer does: I hit the docs, watched some YouTube tutorials, and read through blog posts until the operators started making sense.

The key stages I learned:

• $match - Filter documents (like a WHERE clause)

• $lookup - Join data from other collections (like a JOIN)

• $unwind - Deconstruct arrays into individual documents

• $project - Shape the output (choose which fields to return)

With these operators, I built a pipeline that could fetch the user data, join all the related collections, and return everything in a beautifully structured payload—all on the database server before sending it to the client.

The Result

One API call. All the data. Reduced server load. Lower costs.

What could've been expensive infrastructure scaling became an elegant database query.

A Broader Pattern

Here's something I've realized since: pipelines are everywhere in software development. CI/CD pipelines orchestrate your deployment. Data pipelines transform information. Logging pipelines aggregate and route logs. Deployment pipelines automate releases.

They're so common that I sometimes talk about them on calls, and my non-technical friends look at me confused. One asked, "Wait, when did you become a plumber?"

Fair question.

The principle is the same though: break down a complex process into distinct, sequential stages, where each stage transforms the output of the previous one. Whether you're joining databases or deploying code, the metaphor holds.

The Lesson

Before you build something expensive, think about whether there's a more elegant way to solve it. Sometimes the best solution isn't building more—it's building smarter.

And if you're working with MongoDB and multiple collections, aggregation pipelines aren't just a nice-to-know. They're a game-changer.

RAG stands for Retrieval-Augmented Generation. It's an AI architecture that combines information retrieval systems with generative AI models to produce more accurate, up-to-date, and contextually relevant responses.

Simple Analogy: Think of RAG like a student taking an open-book exam. Instead of memorizing everything (like traditional AI), the student can reference textbooks (external knowledge) to give accurate answers. This reduces the chance of making up incorrect information.

The Two Core Phases of RAG

Phase 1: Ingestion/Indexing (The Knowledge Storage Phase)

This is where we prepare and store data in a vector database for quick retrieval.

The Process:

1. Document Upload - You have a PDF (could be 100, 1000, or 10,000 pages)

2. Chunking - Breaking the document into smaller, digestible pieces

3. Vector Embeddings - Converting these chunks into mathematical representations

4. Storage - Saving these embeddings in a vector database

Why Chunking?

• LLM APIs have rate limits and token constraints

• Processing everything at once would overload servers

• Smaller chunks enable precise retrieval

Analogy: Imagine organizing a massive library. Instead of memorizing every book, you create an index card system where each card contains a summary and location. When someone asks a question, you quickly find the relevant cards instead of reading every book.

Phase 2: Retrieval/Generation

In the retrieval phase, the process unfolds in several key steps:

1. User Query - The user submits a prompt or question through the interface

2. Query Embedding - The prompt is converted into a vector embedding using the same embedding model used during the indexing phase (this consistency is crucial for accurate matching)

3. Similarity Search - The query embedding is compared against all stored embeddings in the vector database. The database uses similarity metrics (like cosine similarity or Euclidean distance) to find the most relevant chunks

4. Context Retrieval - The vector database returns the top-k most similar chunks (typically 3-5 chunks, though this is configurable based on your needs)

5. Prompt Augmentation - The retrieved context is combined with the user's original query to create an enriched prompt. This gives the LLM relevant background information

6. LLM Generation - The augmented prompt is sent to an LLM (ChatGPT, Claude, Gemini, Llama, or any other model). The LLM generates a response grounded in the retrieved context

7. Response Delivery - The final output is returned to the user

The Result: Users receive responses that are contextually accurate, grounded in your specific data source, and significantly less prone to hallucinations.

In the upcoming article I will explain how a production level RAG works, until then see ya :)

When I started doing backend development, I was building the authentication module for a project. The flow was straightforward: the frontend sent a JWT token, the backend verified and decoded it, extracted the user id, and then queried the database to confirm the user existed.

I ended up building three auth APIs: one for signup, one for login, and one for Google OAuth (login/signup). This post is about the login side—and more specifically, what I learned after it “worked.”

A couple of days in, I noticed a pattern: every time I hit a protected API, the backend repeated the same routine. JWT comes in → verify/decode → extract user id → query the database → respond. And it wasn’t a one-time thing. It happened on every request that required authentication.

That’s when I paused and asked myself: can this be faster? Instead of going to the database every time and searching through thousands of users, can I keep the frequently needed data somewhere quicker?

Coming from a frontend background, my first instinct was almost funny in hindsight: “What if I store the user in localStorage?” Then it clicked—there’s no localStorage on a server. That’s a browser feature, not something your backend can rely on.

While exploring better options, I came across Redis and the idea of in-memory caching. The promise was simple: keep hot data in RAM, fetch it in microseconds, and avoid unnecessary database queries. I dug into the docs and implemented it step by step.

Here’s what I changed: on login (and on subsequent authenticated requests), after verifying and decoding the JWT, I’d take the user id and check Redis first. If Redis had the user (or the minimal data I needed), I could skip the database call. If Redis didn’t have it, only then I’d query the main database—and immediately store the result in Redis with a TTL, so future requests could be served faster.

After doing this, I could clearly see the difference. The system stopped hitting the database for the same repeated lookups, and overall latency dropped noticeably (in my case, roughly half for those paths).

The bigger lesson for me wasn’t just “Redis is fast”—it was understanding why the bottleneck existed and how caching fits into backend thinking: reduce repeated expensive operations, and use the database for what it should do best, not for the same lookups again and again.

Introduction to React Lifecycle Phases

Every React component goes through a series of phases during its lifetime. Understanding these phases is crucial for writing efficient React applications and debugging complex component behaviors.

React's lifecycle is divided into two main phases:

1. Render Phase - Pure computation, no side effects

2. Commit Phase - DOM manipulation and side effects

Let's dive deep into each phase and understand what happens under the hood.

The Two Phases Explained

Render Phase: The Blueprint Creation

The Render Phase is where React prepares the component for display. This phase is pure and has no side effects, meaning React can pause, abort, or restart it for optimization purposes.

What happens in Render Phase:

1. Component is mounted (instance created)

2. Constructor is called (for class components)

3. Render method is executed

4. Virtual DOM tree is created

5. Reconciliation occurs (comparing trees)

class MyComponent extends React.Component {
  constructor(props) {
    super(props);
    console.log('🔧 Constructor called - Render Phase');
    this.state = { count: 0 };
  }

  render() {
    console.log('🎨 Render method called - Render Phase');
    return (
      <div>
        <h1>Count: {this.state.count}</h1>
        <button onClick={() => this.setState({ count: this.state.count + 1 })}>
          Increment
        </button>
      </div>
    );
  }
}

Commit Phase: Making It Real

The Commit Phase is where React actually updates the DOM and runs side effects. This phase cannot be interrupted and runs synchronously.

What happens in Commit Phase:

1. React updates the actual DOM

2. Layout effects run (useLayoutEffect)

3. componentDidMount is called

4. Refs are attached

5. Cleanup functions are scheduled

componentDidMount() {
  console.log('🚀 componentDidMount called - Commit Phase');
  // DOM is now updated and visible
  // Safe to make API calls, set up subscriptions, etc.

  fetch('/api/data')
    .then(response => response.json())
    .then(data => this.setState({ data }));
}

Component Batching and Optimization

One of React's most powerful optimizations is batching. When you have a parent component with multiple children, React doesn't render them one by one. Instead, it batches the process for maximum efficiency.

The Batching Process

Consider this component hierarchy:

Parent
├── Child1
└── Child2

Here's the exact order of execution:

Render Phase (Top-down):

1. Parent component mounting begins

2. Parent constructor called

3. Parent render method called

4. Child1 mounting begins

5. Child1 constructor called

6. Child1 render method called

7. Child2 mounting begins

8. Child2 constructor called

9. Child2 render method called

Commit Phase (Bottom-up): 10. Child1 componentDidMount called 11. Child2 componentDidMount called 12. Parent componentDidMount called

Why This Order Matters

The bottom-up execution in the commit phase ensures that:

• Child components are fully mounted before parent's componentDidMount

• Parent can safely access child DOM elements

• Event handlers and refs work correctly

• API calls in parent can depend on children being ready

class Parent extends React.Component {
  componentDidMount() {
    // At this point, ALL children are guaranteed to be mounted
    // Safe to query child DOM elements or call child methods
    console.log('Parent mounted - all children are ready!');
  }

  render() {
    return (
      <div>
        <Child1 ref={this.child1Ref} />
        <Child2 ref={this.child2Ref} />
      </div>
    );
  }
}

Virtual DOM vs Real DOM

Understanding the difference between Virtual DOM and Real DOM is crucial for grasping React's performance benefits.

What is Virtual DOM?

Virtual DOM is simply a JavaScript object representation of the actual DOM. When you write JSX, it gets converted into these objects during the Render Phase.

// Your JSX
<div className="container">
  <h1>Hello World</h1>
  <button onClick={handleClick}>Click me</button>
</div>

// Becomes Virtual DOM (JavaScript objects)
{
  type: 'div',
  props: {
    className: 'container',
    children: [
      {
        type: 'h1',
        props: { children: 'Hello World' }
      },
      {
        type: 'button',
        props: { 
          onClick: handleClick,
          children: 'Click me'
        }
      }
    ]
  }
}

The Journey from Code to Screen

Let's trace what happens when the JavaScript engine reads your React code:

1. JS Engine encounters component → Component instance created

2. Render Phase begins → Constructor called, render method executed

3. JSX converted → Virtual DOM objects created (still just JavaScript!)

4. Reconciliation → React compares old vs new Virtual DOM trees

5. Commit Phase begins → Real DOM elements created/updated

6. Browser rendering → Visual changes appear on screen

Important: No HTML/CSS is actually rendered during the Render Phase. Only JavaScript objects are created!

From Virtual to Real

During the Commit Phase, React transforms Virtual DOM into Real DOM:

// Virtual DOM object
{ type: 'div', props: { children: 'Hello' } }

// Becomes Real DOM
const div = document.createElement('div');
div.textContent = 'Hello';
document.body.appendChild(div);

Initial Mount vs Updates

This is where React's efficiency truly shines. The lifecycle behaves differently for initial mounting versus subsequent updates.

Initial Mount: The Complete Journey

When a component is first rendered:

class DataComponent extends React.Component {
  constructor() {
    super();
    this.state = { data: null, loading: true };
    console.log('1. 🔧 Constructor - Initial setup');
  }

  render() {
    console.log('2. 🎨 Render - Creating Virtual DOM');
    return (
      <div>
        {this.state.loading ? (
          <div>Loading...</div>
        ) : (
          <div>Data: {JSON.stringify(this.state.data)}</div>
        )}
      </div>
    );
  }

  componentDidMount() {
    console.log('3. 🚀 componentDidMount - DOM is ready!');

    // API call triggers an update
    fetch('/api/users')
      .then(response => response.json())
      .then(data => {
        console.log('📡 API response received, triggering update...');
        this.setState({ data, loading: false });
      });
  }
}

Updates: The Optimized Path

After setState is called, React enters an optimized update cycle:

componentDidUpdate(prevProps, prevState) {
  console.log('4. 🔄 componentDidUpdate - Update complete!');
  console.log('Previous state:', prevState);
  console.log('Current state:', this.state);

  // Perfect place for side effects based on state changes
  if (prevState.loading && !this.state.loading) {
    console.log('✅ Data loading completed!');
  }
}

Key Differences: Mount vs Update

The Update Reconciliation Process

When setState triggers an update:

1. New Virtual DOM created with updated state

2. Reconciliation algorithm compares old vs new trees

3. Minimal changes calculated (diffing algorithm)

4. Only changed elements updated in Real DOM

// Before update (loading state)
<div>Loading...</div>

// After setState (data loaded)
<div>Data: {"name": "John", "age": 30}</div>

// React only updates the text content!
// The div element is reused for efficiency

Practical Examples

Let's see these concepts in action with real-world scenarios:

Example 1: Data Fetching Component

class UserProfile extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      user: null,
      loading: true,
      error: null
    };
  }

  async componentDidMount() {
    try {
      const response = await fetch(`/api/users/${this.props.userId}`);
      const user = await response.json();

      // This setState triggers a re-render
      this.setState({ user, loading: false });
    } catch (error) {
      this.setState({ error: error.message, loading: false });
    }
  }

  componentDidUpdate(prevProps) {
    // Handle prop changes (different user ID)
    if (prevProps.userId !== this.props.userId) {
      this.setState({ loading: true });
      this.fetchUserData();
    }
  }

  render() {
    const { user, loading, error } = this.state;

    if (loading) return <div>Loading user profile...</div>;
    if (error) return <div>Error: {error}</div>;

    return (
      <div className="user-profile">
        <img src={user.avatar} alt={user.name} />
        <h1>{user.name}</h1>
        <p>{user.email}</p>
      </div>
    );
  }
}

Example 2: Parent-Child Communication

class TodoApp extends React.Component {
  constructor() {
    super();
    this.state = { todos: [] };
  }

  componentDidMount() {
    console.log('TodoApp mounted - children are ready');
    // All child components (TodoList, AddTodo) are now mounted
    this.loadTodos();
  }

  render() {
    return (
      <div>
        <AddTodo onAdd={this.handleAddTodo} />
        <TodoList 
          todos={this.state.todos} 
          onToggle={this.handleToggleTodo}
        />
      </div>
    );
  }
}

class TodoList extends React.Component {
  componentDidMount() {
    console.log('TodoList mounted first');
    // This runs before parent's componentDidMount
  }

  render() {
    return (
      <ul>
        {this.props.todos.map(todo => (
          <TodoItem key={todo.id} todo={todo} />
        ))}
      </ul>
    );
  }
}

Performance Implications

Understanding React's lifecycle phases helps you write more performant applications:

Optimization Strategies

1. Minimize Render Phase Work

// ❌ Expensive computation in render
render() {
  const expensiveValue = this.calculateExpensiveValue(); // Bad!
  return <div>{expensiveValue}</div>;
}

// ✅ Memoize expensive computations
constructor() {
  super();
  this.expensiveValue = this.calculateExpensiveValue();
}

2. Batch State Updates

// ❌ Multiple setState calls
handleMultipleUpdates = () => {
  this.setState({ count: this.state.count + 1 });
  this.setState({ name: 'Updated' });
  this.setState({ active: true });
  // Triggers 3 re-renders
}

// ✅ Single setState call
handleMultipleUpdates = () => {
  this.setState({
    count: this.state.count + 1,
    name: 'Updated',
    active: true
  });
  // Triggers 1 re-render
}

3. Optimize componentDidUpdate

componentDidUpdate(prevProps, prevState) {
  // ❌ Unconditional side effects
  this.fetchData(); // Infinite loop risk!

  // ✅ Conditional side effects
  if (prevProps.userId !== this.props.userId) {
    this.fetchData();
  }
}

React DevTools Profiler

Use React DevTools Profiler to visualize the render and commit phases:

• Render phase duration - Time spent in component logic

• Commit phase duration - Time spent updating DOM

• Component update reasons - Why components re-rendered

Conclusion

Understanding React's lifecycle phases—Render and Commit—is fundamental to building efficient React applications. The Render Phase creates the Virtual DOM blueprint, while the Commit Phase brings it to life in the real DOM. React's batching optimization ensures components mount efficiently, and the distinction between initial mounting and updates allows for optimal performance.

Key takeaways:

• Render Phase is pure and interruptible

• Commit Phase handles DOM updates and side effects

• Batching optimizes component tree updates

• Virtual DOM enables efficient reconciliation

• Updates skip constructor and only re-render what changed