Forem: Ayush Bansal

ReverseProxy, API Gateway and Load Balancer

Ayush Bansal — Tue, 10 Mar 2026 15:26:25 +0000

TL;DR

1. Forward Proxy

Acts on behalf of the client to access the internet.

Anonymity: Hides the client’s IP address from the destination server.
Security & Filtering: Blocks harmful sites and filters outgoing traffic.
Caching: Stores responses locally to save bandwidth for the internal network.
Logging: Monitors and records user activity within a private network.

2. Reverse Proxy

Acts on behalf of servers to manage incoming requests.

Server Anonymity: Hides backend server details from the public.
SSL Termination: Handles CPU-intensive decryption/encryption.
Compression: Compresses responses (e.g., GZIP) to speed up delivery.
Traffic Inspection: Scans for malicious code before it reaches the backend.

3. Load Balancer

A specialized reverse proxy focused on traffic distribution.

Traffic Control: Distributes requests across multiple servers to prevent overload.
Reliability: Ensures high availability by routing traffic away from failed servers.
Optimization: Maximizes performance across the entire server fleet.

4. API Gateway

An API-aware proxy for managing microservices and web APIs.

Auth: Centralizes authentication and authorization at the network edge.
Rate Limiting: Prevents abuse by capping request volume per client.
Transformation: Converts protocols (e.g., JSON to XML) or modifies headers.
Versioning: Routes traffic to different service versions (v1 vs. v2).
Monitoring: Tracks latency (P95) and usage analytics.

References:

All of these sit between Client and the servers . Each of these have a different purpose and solve different problems.

Before starting with Reverse Proxies let's understand what's a normal proxy (forward proxy)

Forward Proxy

A forward proxy is a proxy server that sits in front of clients (users) and acts as a middleman between a private network and the public internet

Its primary role is to help clients reach servers while providing a layer of control, security, or anonymity

Key functions and characteristics of forward proxies include:
Security and Filtering: A forward proxy acts as a "guard" for a private network

It can filter outgoing traffic to block harmful websites or scripts before they reach a user's machine
Administrators can also blacklist specific websites to prevent employees or users from visiting them

Anonymity: It can be used as a privacy service to mask a client’s IP address

In this scenario, the destination server only interacts with the proxy, not the actual client

Caching for Performance: Forward proxies can cache (store) responses locally

For example, if one person in an office watches a specific tutorial video, the proxy saves a copy; when other people in the same office want to watch it, the proxy serves the cached version instead of downloading it again from the internet, which saves bandwidth and reduces traffic

Activity Logging: They can be used to log user activity, allowing organizations to monitor which websites are being visited by people within the network

Virus Scanning: Beyond just blocking sites, a forward proxy can scan incoming responses for viruses and block malicious content before it enters the internal network

Reverse Proxy

A reverse proxy is a proxy server that sits in front of one or more web servers, acting as an intermediary for incoming requests from clients.
Unlike a forward proxy, which protects the user, a reverse proxy protects and manages the servers.
When you visit a major website, you are typically communicating with a reverse proxy rather than the application server directly.
Key functions and benefits of a reverse proxy include:
Security and Anonymity: It acts as a shield, hiding the existence and characteristics of the origin servers
Because the proxy is the only entry point, attackers only see the proxy's IP address, keeping the actual backend servers hidden from the public internet

SSL Termination: Handling HTTPS encryption is CPU-intensive

A reverse proxy can manage SSL/TLS decryption for all incoming traffic, freeing up the backend servers to focus on their primary tasks

Caching: To speed up performance, a reverse proxy can store (cache) frequently requested content, such as images or videos

If a thousand users request the same file, the proxy can serve it from its cache instead of reaching out to the backend every time

Compression: It can compress outbound responses (using methods like GZIP) before sending them over the network to the client, which saves bandwidth

Traffic Inspection: Because it handles the requests first, it can scan for security threats, hacking attempts, or malicious code before the traffic ever reaches the internal network

Load Balancer

A load balancer is a specialized type of reverse proxy whose primary mission is to distribute incoming network traffic across multiple backend servers.

It acts as a traffic controller to ensure that no single server is overwhelmed, which optimizes the performance and reliability of an application

API Gateway

An API gateway is a specialized, API-aware reverse proxy that sits between clients and backend services to manage, secure, and monitor APIs. While it shares some capabilities with load balancers and standard reverse proxies—such as forwarding and distributing traffic—its primary purpose is to handle the "cross-cutting concerns" required when exposing APIs to the outside world.

Key functions of an API gateway include:
Authentication and Authorization: The gateway acts as a security checkpoint at the "edge" of the network.It validates tokens and checks permissions once, so that backend services do not have to duplicate this logic
. Invalid or unauthorized requests are rejected before they ever reach the internal services.

Rate Limiting: To prevent backend systems from being overwhelmed by intentional abuse or programming bugs, the gateway enforces limits on how many requests a client can make (e.g., 100 requests per minute).

Request and Response Transformation: The gateway can translate between different protocols or formats. For example, it might convert a client's JSON request into the XML format required by a legacy backend service, or strip sensitive internal fields from a response before it is sent back to the user

API Versioning: It allows for smooth migrations by routing traffic to different versions of a service based on the URL (e.g., routing /v1/users to an old service and /v2/users to a new one).

Analytics and Monitoring: Because it sees all incoming traffic, the gateway can track which endpoints are most used, monitor latency (P95), and identify which clients are generating the most errors.

Visualizing CompositionLocal in the Composition Tree

Ayush Bansal — Thu, 05 Feb 2026 05:11:57 +0000

Let me break this down with visual diagrams showing how data flows through the tree.

1. The Composition Tree Structure

When Compose runs your composables, it builds an internal tree structure:

Your Code:                          Composition Tree:
─────────────                       ─────────────────
@Composable                         
fun App() {                              [App]
    Screen()          ───────►            │
}                                      [Screen]
                                          │
@Composable                            [Card]
fun Screen() {                            │
    Card()                             [Text]
}

2. How CompositionLocal Attaches Data

Think of each node having an optional "locals map" attached:

Without CompositionLocalProvider:
─────────────────────────────────

     [App]                    ← locals: { }
       │
    [Screen]                  ← locals: { }
       │
     [Card]                   ← locals: { }
       │
     [Text]                   ← locals: { }


With CompositionLocalProvider:
──────────────────────────────

     [App]                    ← locals: { }
       │
  ┌────────────────────────────────────────────┐
  │ CompositionLocalProvider(LocalTheme → Dark)│
  └────────────────────────────────────────────┘
       │
    [Screen]                  ← locals: { LocalTheme → Dark }  ✓ ATTACHED HERE
       │
     [Card]                   ← locals: { }  (inherits from parent)
       │
     [Text]                   ← locals: { }  (inherits from parent)

3. The Lookup Mechanism (Walking Up the Tree)

When you call LocalTheme.current, Compose walks UP the tree until it finds a provider:

@Composable
fun Text() {
    val theme = LocalTheme.current  // How does this work?
}

LOOKUP: LocalTheme.current from [Card]
──────────────────────────────────────

     [App]          ← 4. Still not found? Use default or throw
       │
    [Screen]        ← 3. FOUND! LocalTheme → Dark ✓ RETURN THIS
       │                  (Provider attached here)
     [Card]         ← 2. Not here, look at parent...
       │
     [Text]         ← 1. Start here: "I need LocalTheme"

4. Shadowing with Nested Providers

@Composable
fun App() {
    CompositionLocalProvider(LocalTheme provides Dark) {
        Screen()
        CompositionLocalProvider(LocalTheme provides Light) {
            AnotherScreen()
        }
    }
}

TREE WITH SHADOWING:
────────────────────

                    [App]
                      │
    ┌─────────────────────────────────────┐
    │  Provider(LocalTheme → Dark)        │
    └─────────────────────────────────────┘
                      │
         ┌────────────┴────────────┐
         │                         │
     [Screen]                 ┌─────────────────────────────┐
         │                    │ Provider(LocalTheme → Light)│ ← SHADOWS parent
     [Card]                   └─────────────────────────────┘
         │                              │
     [Text]                      [AnotherScreen]
                                        │
    LocalTheme.current               [Card]
         = Dark                         │
                                    [Text]

                                 LocalTheme.current
                                      = Light ← SHADOWED VALUE

5. Internal Data Structure (Simplified)

Compose uses a Slot Table - think of it as a flat array that mirrors the tree:

SLOT TABLE (simplified view):
─────────────────────────────

Index │ Node        │ Locals Map              │ Parent Index
──────┼─────────────┼─────────────────────────┼─────────────
  0   │ App         │ { }                     │ null
  1   │ Provider    │ { LocalTheme → Dark }   │ 0
  2   │ Screen      │ { }                     │ 1
  3   │ Card        │ { }                     │ 2
  4   │ Text        │ { }                     │ 3
  5   │ Provider    │ { LocalTheme → Light }  │ 1
  6   │ AnotherScr  │ { }                     │ 5
  7   │ Card        │ { }                     │ 6
  8   │ Text        │ { }                     │ 7

*slot table is a topic in itself, don't be too hard on yourself to understand this

Lookup algorithm:

function lookup(key, nodeIndex):
    current = nodeIndex
    while current != null:
        if current.locals.contains(key):
            return current.locals[key]
        current = current.parentIndex
    return key.defaultValue  // or throw if no default

6. Visual: Multiple CompositionLocals

CompositionLocalProvider(
    LocalTheme provides Dark,
    LocalUser provides currentUser,
    LocalAnalytics provides analyticsService
) {
    Content()
}

                    [App]
                      │
    ┌─────────────────────────────────────────────────────┐
    │  Provider                                           │
    │  locals: {                                          │
    │      LocalTheme     → Dark                          │
    │      LocalUser      → User(name="John")             │
    │      LocalAnalytics → AnalyticsServiceImpl          │
    │  }                                                  │
    └─────────────────────────────────────────────────────┘
                      │
                  [Content]
                      │
              ┌───────┴───────┐
              │               │
          [Header]        [Body]
              │               │
          [Avatar]        [Posts]

   LocalUser.current     LocalTheme.current
   = User("John")        = Dark

7. The "Recomposition Scope" Aspect

WHEN VALUE CHANGES (compositionLocalOf):
────────────────────────────────────────

Provider(LocalCounter → 1)  ──changes to──►  Provider(LocalCounter → 2)
           │                                            │
       [Screen]  ← NOT recomposed                   [Screen]
           │       (doesn't read it)                    │
       [Counter] ← RECOMPOSED! ✓                   [Counter] ← reads LocalCounter
           │       (reads LocalCounter.current)        │
       [Label]   ← NOT recomposed                  [Label]
                   (doesn't read it)

Only nodes that actually READ the value get recomposed!

Summary Mental Model

┌──────────────────────────────────────────────────────────────┐
│                     COMPOSITION TREE                         │
│                                                              │
│   ┌─────┐                                                    │
│   │Node │ ◄─── Each node can have a "locals" attachment      │
│   └──┬──┘                                                    │
│      │      ┌──────────────────────┐                         │
│      │      │ locals: {            │                         │
│      │      │   Key1 → Value1      │ ◄── Provider attaches   │
│      │      │   Key2 → Value2      │     key-value pairs     │
│      │      │ }                    │                         │
│      │      └──────────────────────┘                         │
│   ┌──┴──┐                                                    │
│   │Child│ ◄─── Children inherit (lookup walks up the tree)   │
│   └─────┘                                                    │
│                                                              │
│   KEY INSIGHT: Data is NOT copied down.                      │
│   It's attached at one node, and lookups walk UP to find it. │
└──────────────────────────────────────────────────────────────┘

ViewModel & Co.

Ayush Bansal — Mon, 26 May 2025 08:04:29 +0000

Let's dive into the relationship between ViewModel, ViewModelProvider, ViewModelStoreOwner, and ViewModelStore by examining their roles and interactions within the AOSP codebase.

Think of these four components working together as a system for managing and persisting UI data across configuration changes like screen rotations.

The Core Components Explained

1. `ViewModel` 🧠

This is the class you'll interact with most directly. Its primary job is to hold and manage UI-related data. The key feature of a ViewModel is that it survives configuration changes that would normally destroy and recreate an Activity or Fragment.

When a ViewModel is no longer needed (because its associated UI component is permanently destroyed), its onCleared() method is called to free up any resources.

2. `ViewModelStore` 🗄️

This is a simple container class. As its name suggests, its only job is to store ViewModel instances. Under the hood, it uses a HashMap<String, ViewModel> to map a key (usually derived from the ViewModel's class name) to the ViewModel instance itself.

From the AOSP source, we can see its core implementation:

// A simplified view from the source
public class ViewModelStore {
    private final HashMap<String, ViewModel> mMap = new HashMap<>();

    final void put(String key, ViewModel viewModel) {
        ViewModel oldViewModel = mMap.put(key, viewModel);
        if (oldViewModel != null) {
            oldViewModel.onCleared();
        }
    }

    final ViewModel get(String key) {
        return mMap.get(key);
    }

    public final void clear() {
        for (ViewModel vm : mMap.values()) {
            vm.onCleared();
        }
        mMap.clear();
    }
}

3. `ViewModelStoreOwner` 🧑‍💼

This is an interface that provides a ViewModelStore to other objects. Any class that implements ViewModelStoreOwner is responsible for two things:

Providing a ViewModelStore via the getViewModelStore() method.
Retaining that ViewModelStore instance across configuration changes and calling its clear() method when the scope is permanently destroyed.

The most common implementers of this interface are ComponentActivity and Fragment. They handle the logic of saving and restoring the ViewModelStore for you.

// The simple interface definition
public interface ViewModelStoreOwner {
    @NonNull
    ViewModelStore getViewModelStore();
}

4. `ViewModelProvider` 🏭

This is the factory and retriever for ViewModels. You don't create ViewModels directly; you ask a ViewModelProvider for one. It's responsible for either creating a new ViewModel instance or, more importantly, retrieving an existing one from the ViewModelStore.

When you create a ViewModelProvider, you give it a ViewModelStoreOwner (like an Activity or Fragment). The provider then uses the owner to get access to the ViewModelStore.

// One of the main constructors
public ViewModelProvider(@NonNull ViewModelStoreOwner owner, @NonNull Factory factory) {
    this(owner.getViewModelStore(), factory);
}

// The core 'get' method logic
public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {
    ViewModel viewModel = mViewModelStore.get(key); // Check the store first

    if (modelClass.isInstance(viewModel)) {
        // ViewModel already exists, return it
        return (T) viewModel;
    }

    // ViewModel doesn't exist, create it using the factory
    viewModel = mFactory.create(modelClass);
    mViewModelStore.put(key, viewModel); // Put the new instance in the store
    return (T) viewModel;
}

The Relationship: How They Work Together

Here's the step-by-step flow that connects all four components:

Your Activity or Fragment starts. Since it implements ViewModelStoreOwner, it either creates a new ViewModelStore or retrieves a previously saved one (if a configuration change just happened).
To get your ViewModel, you instantiate a ViewModelProvider, passing your Activity/Fragment (this) as the ViewModelStoreOwner.
The ViewModelProvider's constructor calls getViewModelStore() on your Activity/Fragment to get a reference to the ViewModelStore.
You call viewModelProvider.get(MyViewModel.class).
The ViewModelProvider asks the ViewModelStore if it already has an instance for the key associated with MyViewModel.
If yes, the existing ViewModel instance is returned. This is what happens during a screen rotation.
If no, the ViewModelProvider uses its factory to create a new MyViewModel instance, adds it to the ViewModelStore, and then returns it.
When your Activity/Fragment is permanently destroyed (e.g., the user presses the back button and finishes it), its ViewModelStoreOwner implementation calls clear() on the ViewModelStore.
The ViewModelStore then calls onCleared() on every ViewModel it holds, allowing them to clean up their resources.

In essence, the ViewModelStoreOwner (the UI controller) owns the ViewModelStore (the storage). The ViewModelProvider (the factory) acts as the middleman to create or retrieve ViewModels from that storage, ensuring you always get the correct instance for the given owner's lifecycle.

Breaking the build 😝 : Demystifying Gradle

Ayush Bansal — Wed, 30 Oct 2024 08:56:12 +0000

As an Android developer, I've always been deep into coding and app design, but kind of skimmed over the whole Gradle thing—even though it's such a key part of our workflow. Recently, I decided to really get to know Gradle, and I want to share what I've learned.
Let's break down some of its complexities and actually understand Gradle.

Understanding Settings file

Let's get started by creating an empty project in Jetbrain's IntelliJ IDEA (Community Edition)

The settings file, either settings.gradle or settings.gradle.kts, is the entry point of any Gradle project. Create a new file setting.gradle.kts. Your project structure should appear as follows

Ignore other files for now

Key Components of the Settings File

The settings file serves several purposes, but here are the three primary aspects to keep in mind:

Naming Your Project: Give your project a stable identifier using the rootProject.name property.

rootProject.name = "demo-project"

Dependency and Plugins: Specify where Gradle should look for other components your build may depend upon. There are two fundamentally different things:
- The first thing are libraries your production code might need. e.g., an Apache Commons library.
- The second thing are plugins that extend Gradle itself.

These are usually located in the Gradle plugin portal, google and mavenCentral but may also be provided through other binary repositories. Or, you may also define plugins locally in other builds.

dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
}
pluginManagement{
    repositories {
        gradlePluginPortal()
        google()
    }
}

Structuring Your Project: Organize your project into subprojects using the include() function. This helps in managing separate components of your application. e.g., we are defining 3 sub-projects "business-logic", "data-model", and "app".

include(":business-logic")
include(":data-model")
include(":app")

Based on the three points discussed, your settings.gradle.kts file should be structured like this

rootProject.name = "demo-project"
dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
}
pluginManagement{
    repositories {
        gradlePluginPortal()
        google()
    }
}
include(":business-logic")
include(":data-model")
include(":app")

The project structure, once the components are configured in the settings file, should appear as follows

Understanding Build Files

We have created a project with three subprojects namely

business-login
data-model
app

So far, these subprojects are empty and thus have no real meaning to Gradle. We can add a build file to each of them to change this.

The build file, either build.gradle or build.gradle.kts, is the heart of Gradle projects.
These files are crucial as they dictate how your project is built, what plugins and dependencies are included, and how your source code is organized.

Key Components of the Build File

Let's take a closer look at the build file for our business-logic project. There are three things to configure in your build files.

Configuring Plugins: This is the first component in any build file. The plugins section provides structure by specifying the type of project you are building, enabling Gradle and your IDE to understand your project’s layout, compile options, and packaging details. Let’s clarify with an example. In this example, we’ll apply the Java Library Plugin.

plugins {
    id("java-library")
  }

Applying this plugin turns the subproject into a Java Library project, so Gradle and the IDE know where the source code is located, how the code is compiled, and how it’s packaged into a JAR file.

Setting Extension: Plugins often come with extensions that enable further customization. For the Java Library plugin, you can access the Java extension to configure compilation specifics, such as targeting a certain Java version.

   java {
       sourceCompatibility = JavaVersion.VERSION_11
       targetCompatibility = JavaVersion.VERSION_11
   }

Defining Dependencies: Dependencies are what your subproject relies on for building and running. They can include other subprojects or external components housed in repositories. Here’s how you can define them:

   dependencies {
       // Dependency on internal subproject
       implementation(project(":data-model"))
       // External library dependency
       implementation("org.apache.commons:commons-lang3:3.12.0")
   }

Here, implementation is used to denote compile-time dependencies. The project keyword assists in referring to subprojects, while the external component is specified through its group, name, and version.

Based on the three points discussed, your business-logic/build.gradle.kts file should be structured like this

plugins {
   id("java-library")
}

java {
   sourceCompatibility = org.gradle.api.JavaVersion.VERSION_11
   targetCompatibility = org.gradle.api.JavaVersion.VERSION_11
}

dependencies {
   implementation(project(":data-model"))
   implementation("org.apache.commons:commons-lang3:3.12.0")
}

And Project structure should appear as follows

Sharing my notes/project(which form the base of this and upcoming article/s) as github project .

In our future discussions, we'll delve deeper into advanced Gradle features and plugins, further expanding development toolkit. Till then Keep exploring and building :🚀🚀!