DEV Community: Purneswar Prasad

A story on Frontend Architectures - SPA meets the enterprise! (Part-2)

Purneswar Prasad — Fri, 19 Dec 2025 15:49:42 +0000

(... In Part-1, we established the foundation with definition of MFE and the basic of Module Federation.)

Let's understand how the remoteEntry.js file exposes a remote app from the shell with some real code.

We'll do this in 3 layers:

1) Remote app config
2) What remoteEntry.js exposes
3) Shell app runtime code

1) Remote app Module Federation config

//mfe/webpack.config.js

const {ModuleFederationPlugin} = require("webpack").container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: "cartApp"            //global container name
      filename: "remoteEntry.js" //this will be loaded by the shell
      exposes: {
        "./CartWidget" : "./src/CartWidget.js"  //exposed metadata
      shared: {
        react: {singleton: true },
        "react-dom": {singleton: true }
      }
    })
  ]
};

Let's understand the plugin keys exposes and shared.

exposes:
- Purpose: declares what modules this remote makes available to others
- Use small composable public names like ./Header, ./routes
- Keep internal implementation hidden and only expose contracts.
shared:
- Purpose: negotiate shared dependencies and avoid duplicate of shared libraries like React.
- Implemented as a per-module shared scope where providers(remote) register available versions and consumers(shell) request versions
- singleton: true ensures a single instance across containers (use for React, React DOM etc.)
- requiredVersion allows consumer to express the semantic version it expects
- strictVersion fails the negotiation if the version cannot be satisfied (dangerous for progressive migration).
- eager: true loads the shared module immediately (useful for small libs), but increases initial payload.

So, with this config, the remote deploys remoteEntry.js and exposes the module, but can still build independently.

2) What remoteEntry.js exposes

After remoteEntry.js loads in browser, Webpack registers a container(a JS object) under a global name which looks like this:

window.cartApp = {
  // metadata about exposed modules
  get: async (moduleName) => {
    // returns a FACTORY, not the module itself
  },

  init: async (shareScope) => {
    // registers shared dependencies into global scope
  }
};

3) Shell app runtime code

The remoteEntry file can be loaded on the host in 2 different ways: static and dynamic.

Dynamic loading

Shell webpack config

// shell/webpack.config.js
const { ModuleFederationPlugin } = require("webpack").container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: "hostApp",
      remotes: {}, // 👈 NOTHING here
      shared: {
        react: { singleton: true },
        "react-dom": { singleton: true }
      }
    })
  ]
};

Here the host bundle has no knowledge of the remotes.

Let's look at the the core of the dynamic federation, runtime loader

loadRemote.js

// shell/src/loadRemote.js

//idempotent script injection 

export function loadRemoteEntry(remoteUrl, scope) {
  return new Promise((resolve, reject) => {
    if (window[scope]) return resolve(); // already loaded

    const script = document.createElement("script");
    script.src = remoteUrl;
    script.type = "text/javascript";
    script.async = true;

    script.onload = () => {
      console.log(`${scope} remote loaded`);
      resolve();
    };

    script.onerror = () => {
      reject(new Error(`Failed to load remoteEntry: ${remoteUrl}`));
    };

    document.head.appendChild(script);
  });
}

// turns the loaded remote app into an actual usable module

export async function loadRemoteModule(remoteUrl, scope, module) {
  // 1. Load remoteEntry.js
  await loadRemoteEntry(remoteUrl, scope);

  // 2. Initialize shared scope
  await __webpack_init_sharing__("default");

  // 3. Initialize the remote container
  const container = window[scope];
  await container.init(__webpack_share_scopes__.default);

  // 4. Get module factory
  const factory = await container.get(module);

  // 5. Execute factory
  return factory();
}

The first function loads a dynamic remoteEntry.js file by doing a script injection(ensures that a remote’s remoteEntry.js is loaded exactly once, even if multiple parts of the application attempt to load it, preventing duplicate execution and runtime conflicts) & the second function makes the remote usable by exposing the module.

Let's understand the details of the second function.

await loadRemoteEntry(..) loads the remoteEntry file using the remoteUrl produced during the build
__webpack_init_sharing__ and __webpack_share_scopes__ are provided by Webpack's runtime.
await __webpack_init_sharing__('default') ensures host shares are initialized
const container = window[scope] is the container registered by remoteEntry
container.init(...) registers the remote's shared modules
__webpack_init_sharing__('default') must be called before container.init(...) to ensure host registered share scope exists, preventing undefined scope issues

In simple words:

Host says: “Here is the shared dependency table”
Remote says: “Cool, I’ll register what I can share”
Webpack decides:
- which React version to use
- ensures singleton rules
container.get(module) returns a factory, which on invoked returns the actual module(component/object)
Static loading

Shell application declares the remote at build time

// shell/webpack.config.js
const { ModuleFederationPlugin } = require("webpack").container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: "hostApp",
      remotes: {
        // 👇 STATIC binding (known at build time)
        cartApp: "cartApp@http://localhost:3001/remoteEntry.js"
      },
      shared: {
        react: { singleton: true },
        "react-dom": { singleton: true }
      }
    })
  ]
};

Here the **remotes** property helps the host reference an external container.

The host already knows the remote name and URL and Webpack bakes the remote mapping into the host bundle.

Then, it can be imported like a local module

// shell/src/App.js
import CartWidget from "cartApp/CartWidget";

export default function App() {
  return (
    <div>
      <h1>Host Application</h1>
      <CartWidget />
    </div>
  );
}

Important things to note:

This import is not resolved at build time
It is transformed by Webpack into a runtime fetch from remoteEntry
Webpack automatically performs shared scope initialisation, container.init(), container.get() and factory execution that we saw earlier in dynamic loading behind the scenes

So basically, in the background the import is rewritten by Webpack to this:

await __webpack_init_sharing__("default");
const container = await loadRemoteContainer("cartApp");
await container.init(__webpack_share_scopes__.default);
const factory = await container.get("./CartWidget);
const CartWidget = factory();

Practical MFE wiring architecture patterns

1) Simple host + static remotes

Use when remote URLs are stable and managed tightly

Shell webpack remotes points to fixed URLs

Low runtime complexity but also, low deployment flexibility

2) Host + dynamic remotes via manifest

Shell at runtime fetches a manifest JSON mapping remote name to URL

Host uses the loader to inject remoteEntry.js

Gives per-environment control and allows independent deployments and releases.

3) Single-spa for lifecycle + Module Federation for sharing

4) SSR with Module Federation

Practical checklist for converting a monolith

Pick a simple host that will control routing and layout

Identify vertical slices(a single page or a low traffic route) as the first remote

Make the shell load remoteEntry dynamically from a staging manifest

Declare shared dependencies as singletons

Smoke test integration of shell and remotes

Ensure remotes publish a small contract file(exposed modules and versions) & shell CI validates compatibility

Feature-flag route to new remote rollout

Iterate the process by extracting more MFEs and investing in platform automation

To wrap it up, micro-frontends are not a silver bullet, but an organisational scaling tool disguised as a frontend architecture.
When teams, domains, and deployment velocity outgrow a single SPA, MFEs combined with Webpack Module Federation provide a pragmatic way to regain autonomy without sacrificing runtime cohesion. Used thoughtfully, they shift frontend engineering from “shipping bundles” to composing systems at runtime.
Used prematurely, they simply move complexity around and make your life harder.

As with most architectural decisions, the real win comes not from the tooling, but from aligning it with organisational structure, ownership, and long-term business scale.

A story on Frontend Architectures - SPA meets the enterprise (Part-1)

Purneswar Prasad — Fri, 19 Dec 2025 15:46:24 +0000

This post might not be useful for everyone. Yes, for starters this is definitely something you can try if you want to know how things work for any small application just to make your hands dirty and gain knowledge.
If you're on a hobby project or a small company, deciding to do this might just be setting yourself up for failure.
But if you're an enterprise with hundreds/thousands of employees working on an application, this might be your best bet at scalability and maintainability.

Welcome to Micro-frontends or MFEs! You're right, it's micro services for the frontend.

And in this post, we'll be discussing 2 things broadly

the what and why of MFEs

the how with Webpack Module Federation.

Let's start with knowing what a MFE is.

Microfrontend is a self contained micro-app, much like a singular service in micro services architecture of the backend. Each micro-app can be handling a specific type of feature as needed by the organisation, a single business domain or a single feature.
And it will have its own UI, logic, build and deploy pipeline too.

And these micro-FEs need a host which is called shell application. This composes the micro-apps into the final application page.

You may ask, what was the need for MFEs?

As orgs scaled, their backend architecture with micro services was fairly easier to scale than their frontends.
SPA frontends became large monoliths, with a lot of developers contributing to the same enlarged codebase. And this sometimes, blocked parallel workstream teams.

MFEs didn't just make teams leaner and modular, but also brought domain-drive team boundaries into the UI layer.

From a business and technical POV, MFEs can be considered when there is a need for

1) Team autonomy - Separate ownership and pipelines reduces coordination friction
2) Heterogeneous technology with no framework constraint
3) No single-point-of-failure as error in one MFE is less likely to catastrophically affect others. Thus, deliverables can be scaled

A business should NOT use a MFE architecture, if it is a - (i) small app, (ii) small team or (iii) cannot invest in platform engineering/QA/observability.

Now that we've set the premise for MFEs, it's time to discuss the internal working and flow in these micro apps. And for that, we'll be learning a concept from the Webpack bundler called Module Federation.

Before jumping into Module Federation, let's set the ground with a few concepts.

1. Bundlers & the traditional build-time model
Modern frontend apps use bundlers like Webpack and Vite that resolve all imports at build time, producing a single or a few static bundles shipped to the browser.

2. Problem with build-time coupling
In traditional SPAs, every dependency must be known during build time. Which means, a small change requires an entire rebuild and redeploy of the entire FE.

3. Runtime vs Build-time composition
Traditional FEs rely on build-time composition, but MFEs load, connect and execute different applications while the app is running. Thus the need of build-time composition.

4. Need for shared dependencies
In MFE architecture, given the number of different applications, loading multiple copies of large libraries like React is inefficient and dangerous. Thus, these must exist as singletons to avoid runtime bugs.

5. Independent deployment as a primary need
MFEs are not just about code splitting - they're also about enabling teams to work faster, deploy independently and scale at their own pace.
This requires a system that can consume code it didn't know about at build time.

Webpack Module Federation is Webpack’s answer to these problems.

Webpack Module Federation is a runtime feature introduced in Webpack 5, that allows independently built bundles load and
share modules from other apps at runtime. It is one of the most practical technical ways to implement MFEs because it lets those microamps to share code and import each other's modules without rebuilding the whole shell.

Now let's see how the "how" works!

Roles

Host(Shell): This is the orchestrator. It consists of global layout, global routing, authentication orchestration and top-level error handling.
It may also supply global CSS variables and the manifest that maps remote names to URLs.
It decides when and how to load remotes and provide shared infrastructure like auth token refresh.
Remote(MFE): This is an independently built app that owns a business domain/feature. It exposes one or more modules like components via Module Federation's exposes key.
It has its own CI/CD and publishes a remoteEntry.js file and other static assets.

What is `remoteEntry.js`

This is the bootstrap/manifest file that Webpack emits for a federated(runtime-composed) build. It registers a container(a JS object) which exposes an API to:
- initialise shared scopes - a place where Webpack coordinates shared dependencies like React, lodash and loads code form each other at runtime.
- get() factories for exposed modules - A factory function that can create the module that is asked for. A factory is needed because the module might not be loaded yet and the shared dependencies must be resolved first. Thus, for Webpack to control the flow of execution.

(to be continued .....)

Tune in to Part-2 for more internals and deep-dive!

A story on Frontend Architectures - Back to the Future

Purneswar Prasad — Fri, 19 Dec 2025 00:04:49 +0000

Till now we have talked a lot about how architectures have evolved from magazine-looking webpages to animation and transition heavy websites, with different architectural ideas to ship faster, better and more reliably.

A lot of these ideas focused more on how to efficiently use the backend to serve the frontend better. And as it happened, we developers gradually started shipping a truck load of JavaScript into the websites with SPAs.
For sure, it made them more interactive, but on the other hand, users were left to see a site loading very slowly with all the JS shot into it.

Think of a webpage as a canvas. HTML forms the borders, CSS addeds some colors and shapes and JS is the artist that brings in the details.

In a SPA heavy world, we started handing over too much of this painting work to JS. Refer to the image below:

The browser may have already received the first byte, even painted something on the screen(First Contentful Paint), but there's no actual use of it.
The main content arrives late(Largest Contentful Paint (LCP)), but clicks still feel unresponsive since the JS thread is busy(First Input Delay) and layouts keep jumping as scripts keep laoding(Cumulative Layout Shift).

So while the page looks like it’s loading, the user experience is stuck in limbo...Is it happening? Is it useful? Is it usable?
This gap between “something is visible” and “I can actually interact” became the biggest pain of SPAs, and it’s precisely this problem that pushed the ecosystem to rethink rendering strategies beyond shipping a truckload of JavaScript to the client.

In this story, we discuss how the future asked us to go back to the server era, different strategies that makes the web faster and brought the "next" innovative architectural pattern, their advantages and disadvantages and suitable use case scenarios

1) CSR - Client Side Rendering

This is the generic rendering idea where the client does almost all of the heavy lifting, fetches data from the server and renders UI at the runtime. Rendering work is minimal at build time, but bundling and optimization may still be complex, with an entire app bundle is produced in the build stage.
Here the user experience is powerful gives rich interactivity after load. But initial experience is often poor:

blank screen
loading spinners
JS parse + execution delays

This is the classic slow FCP / LCP problem.

This type of rendering is suitable for highly interactive apps where SEO/page-first render matters less. E.g - internal dashboards, SPAs.

2) SSG - Static Site Generation

When speed is in question, frontend teams needed something else. That's where pre-rendering came to the rescue.
Pre-rendering is building HTML ahead of time and serve it from a data store like CDN. Instead of fetching data per request on the server, data is fetched at build time. So, there can be some static content that can be served instantly and thus an ultra low TTFB(Time Taken to First Byte).
The build process is very long here since the pages are fully rendered at build time and the server just serves this pre-built HTML. The client has small to moderate JS for interactivity and some hydration may be needed for interactive widgets.

This type of rendering strategy works best for sites which need better SEO, for e.g. docs, marketing, blogs etc

And similarly, if content on the site changes frequently, SSG can be a problem since the content it serves might be stale until the next build.

3) SSR - Server Side Rendering

This is kind of an improvement on the SSG strategy for speed, scale and content freshness.
Here, instead of building entire pages in the build stage, app bundles are built.
On every request from the client to the server, pages are rendered in the server and served fresh. So there is always fresh data and better personalisation/SEO for dynamic content. The client runs the interactive parts and hydrates the server HTML.

Highly dynamic/personalised pages and real-time dashboards that must be up-to-the-second on every request (Don't Confuse: SSR only helps with initial HTML, not real-time updates) use this kind of rendering.

Since the server renders and sends this as a response on client request, there is a higher per-request compute and latency than cached static HTML.
Also, it is harder to scale without caching strategies, given the heavy load on the server.

4) ISR - Incremental Site Regeneration

This is a rendering strategy pioneered by the framework, Next.JS. It was invented to get the best of SSG and SSR i.e. serve static cached pages from CDN for speed, but also allow selected pages to be re-generated (on-demand or after a revalidate period) without a full rebuild.

Let's understand why ISR came into the picture. Before:

1) SSG was fast but couldn't update without a fresh rebuild of the entire site.
2) SSR was fresh, but slower and more expensive.

ISR brought in both:

Static performance, serving cached pages instantly
Dynamic freshness, regenerating only pages that need updating
Incremental updates, so build time stays low even for large sites

To understand ISR in action, which is very important for further discussion, please follow this video, where there has been a very clear implementation of the concept.

For implementation of ISR, there needs to be a specific key called revalidate. This holds a value which tells the server when to regenerate the page.

But there is a small twist here, which might make you question how is this a good mechanism to keep the freshness of the site.

For example: revalidate: 60
Let's go through the timelines

Page generated at t = 0

Cached globally

t = 1 → 60

All requests get cached HTML

No regeneration allowed

t = 61 (first request after expiry)

Old HTML is served instantly

Background regeneration starts

User never waits

t = 62+

Regeneration finishes

Cache is replaced

All future users get fresh content

Now you might think at t=61, when a request is sent, why is the old HTML is served instantly rather than the fresh one?

This is a deliberate design decision. Some reasons:

1) Speed > Freshness - Users prefer instant pages over perfectly fresh but slow ones.

Users care far more about:
“Did the page load instantly?”
than
“Is this data 10–60 seconds old?”

2) Only ONE request ever sees stale-after-expiry

The first request after expiry triggers regeneration
Everyone after that gets fresh content
There is no cascade of stale responses

This is called request collapsing

3) No blocking - Regeneration never delays a response

4) Most users never refresh immediately and by the time they do, cache is already updated

And there is also the option to have on-demand validation using web hooks from the database when content is updated. This can result in no user seeing any stale content and still remain static-fast.

This type of rendering strategy will only be helpful where there is mostly static but periodically updating content, need for a good SEO and has a lot of pages. E.g.- blogs, documentation, product detail pages, category pages etc.

Do NOT use ISR for:

Real-time data (stocks, live scores)
User-specific dashboards
Financially critical per-request accuracy

Basically places where the needs are of a real-time rendering, user-specific rendering, background crawling of all pages etc., ISR should not be used.

5) RSC - React Server Components

Let's run back the clock a bit to see how servers and clients interacted to show sites on the browser.

In CSR, in applications written in React, when a particular request goes from the client to the server, server sends a minimal HTML shell that references the JS bundle, and the browser sets itself to download this bundle on the client.
Then the rendering shell makes API calls to the backend, which may query the database and this is the point where the user starts to see something on the screen, even if they're non-interactable.
This often results in poor or unreliable SEO due to delayed content visibility.

To solve this issue of a very late "First Paint" as well as SEO, Next.js brought in the concept of SSR. In this, the rendering shell along with its queries to the DB goes to the server and returns a fully rendered HTML document (with CSS links), allowing content to appear immediately and thus, reducing the First paint time by a margin.
Then the JS bundle starts to download in the background on the client and a process of hydration occurs, where the event listeners and other interactive components get attached to the static page, making it interactable.

But even here, if you had noticed, there is a problem. There is always the download of a big JS bundle on the client, which slows down the time to show an interactive screen.

Comes the eureka moment - server components!

Think like this:
If you had an application with 20 components, and among them 15 of them just show some image, text or in general, non interactable components, why do you need to do it on the client and fetch info from the server?
You can just do it on the server itself and not put it in the JS bundle sent on the client! And in turn, reduce client-side JavaScript, memory usage, and hydration cost.

You might think, "but this is just SSR again right?". Well not exactly. This is where RSC is not SSR.

What SSR sends:

HTML
Then ships JS
Then hydrates

What RSC sends:

A serialized React component tree
Often called the “React Flight” payload

This payload is:

Not HTML
Not JS source code
A structured description of the UI

The client:

Reconstructs the React tree
Inserts it into the DOM
Without executing server component JS

So from your 20 components, you just do the same SSR process for your 5 interactive components are shipped, hydrated, and executed on the client, reducing your JS bundle size significantly!

RSC is designed to work with React Suspense, allowing streaming chunks of UI, progressive rendering from server and streaming support.

All of this needed a framework because it needs:
1) A bundler that understands server/client boundaries
2) A server runtime
3) Streaming support
4) Routing integration

And that's why Next.js 13 App Router became the first mainstream RSC implementation
& RSC is not usable in plain CRA/Vite alone.

The evolution from CSR to SSG, SSR, ISR and finally React Server Components shows that frontend architecture has never been about choosing one “best” rendering strategy, but about placing work where it makes the most sense.

As we pushed more logic to the client, performance suffered; as we brought it back to the server, the web became faster and more usable again.
Modern frameworks now let us mix these strategies thoughtfully—balancing speed, freshness, interactivity and scale—rather than overloading the browser with work it was never meant to do. The future of the web isn’t client-first or server-first, but responsibility-first.

A story on Frontend Architectures - Everyone deserves a BFF!

Purneswar Prasad — Sun, 14 Dec 2025 17:58:21 +0000

SPAs were revolutionary and ground-breaking in the way they changed frontend architectures and shifting the entire view of the data-model(pun intended).

A lot of UI and data-shaping work came into the browser which created client-specific needs. Let's discuss a few of them.

1. Different shapes of the payload - There can be case of over and under fetching when a generic API is used. It sends too much data for one client and too less for another, thus forcing clients to request multiple endpoints and waste bandwidth.

2. Juggling between microservices - SPAs often need to call multiple microservices, join results and shape them for the view. This increases complexity and hurts performance.
auth/token handling

3. Mobile device handling - Mobile apps, TV apps or web SPAs have different payload, caching and security requirements. One API fits all is bound to fail.

4. Organisational bottlenecks - With a single backend, the dependency of the frontend team for minor API changes results in slower delivery timelines.

Let's understand through an example.

Suppose you've an web-based e-commerce application which has an API /v1/products/102938 showing the details of a certain product as follows -

{
  "productId": "PROD-102938",
  "name": "ZenBeat Pro Wireless Noise Cancelling Headphones",
  "description": "Wireless headphones with active noise cancellation, deep bass, and long-lasting battery life.",
  "seller": {
    "sellerId": "SELL-908",
    "name": "ZenBeat Official Store",
    "rating": 4.6
  },
  "variants": [
    {
      "variantId": "VAR-1",
      "label": "Black",
      "price": 9999,
      "inStock": true
    },
    {
      "variantId": "VAR-2",
      "label": "Silver",
      "price": 10499,
      "inStock": false
    },
  ],
  "reviews": {
    "averageRating": 4.4,
    "totalReviews": 612,
    "topReviews": [
      {
        "reviewId": "REV-1",
        "rating": 5,
        "comment": "Excellent sound quality and very comfortable for long use."
      },
      {
        "reviewId": "REV-2",
        "rating": 4,
        "comment": "Great noise cancellation, battery life could be slightly better."
      },
    ]
  },
  "faqs": [
    {
      "question": "Does this support fast charging?",
      "answer": "Yes, it supports fast charging and provides up to 5 hours of playback with a 10-minute charge."
    },
    {
      "question": "Is there a warranty?",
      "answer": "Yes, it comes with a 1-year manufacturer warranty."
    }
  ]
}

Now to render data for a response like this on a mobile app would be very different to that of a mobile app given the limited real estate on the device. Probably in a mobile app, we would show the "faqs" on click of a button which would be another API call.

With lesser and different set of response, we get

a better UX
faster rendering times
save on network bandwidth

And this doesn't just apply to mobile, but for any other client which might work better with a different API response than a single monolith API.

To deal with this mismatch and give each client(TV, mobile, web) their own backend, emerged the pattern of Backend for Frontend(BFF).

The idea here is to have an intermediate layer between the client and the backend. And mind that, this layer is completely to assist the client i.e presentation logic and there is NO business logic involved here. Imagine this, instead of a single API gateway, we have multiple API gateways for every type of client.

Let's understand 2 different use cases of a BFF for different types of backends.

1. BFF and Monolith

With a monolith API architecture, the BFF does the work of filtering responses and provides a specific entry point as per the client needs.

Each BFF decides
1) what it needs to fetch
2) how it needs to fetch
3) what needs to be sent in

A mobile BFF can remove the responses which might be unnecessary to be displayed on the mobile screen, like reviews or FAQs, while a desktop BFF can keep those additional details.

Here, you might think, why would we fetch all kinds of data from the backend if we're eventually going to drop it?
Yes, you're not wrong. We can use a flag, like device=mobile and filter the responses sent from the backend accordingly.
But this also complicates the backend logic and we try to keep the backend as generic as possible.
And on top, having a BFF layer with all the responses coming in, gives the advantage of caching responses to be used later.

2. BFF and Microservices

With a micro-service backend architecture, the BFF only picks those services which it requires in the catalogue of services.
In the picture above, a mobile client would benefit from a AR service to imagine any product in a real-life 3D visual, which would be absolutely unnecessary in the web client.

Now let's discuss some pros and cons of this middle-man!

Advantages:

There is now a support for different types of interfaces in their own isolated manner

Any particular client specific tweaks can be executed much faster

Since backend is not directly exposed, there can be filtering of any sensitive data at the BFF layer

BFFs can also act as a mediator between the stack/protocols that is being used by the client and the server, thus making it seamless. For e.g., if a legacy client uses XML but gets JSON from the backend, BFFs can act as a transformation layer.

Given different client interfaces are treated separately, the security concerns can be addressed separately and in a much better way. There need not to have all kinds of security checks for every client.

BFFs help make a generic backend, putting the heavy load of customisation upon itself. And thus, acts as a request aggregator, making the client lightweight.

Disadvantages:

On the same lines of the last advantage point, fanning out or sending requests out from a single source(BFF) to multiple micro-services concurrently, can be network heavy. The choice of language and runtime is therefore crucial. Languages with efficient, non-blocking concurrency models (such as Node.js, Go or reactive Java) are better suited for handling high levels of parallel I/O without incurring excessive thread or memory overhead.

Code for multiple BFFs would mostly be the same(as seen previously, both web and mobile would need Product details and Seller details services) with minor tweaks here and there, which results in code duplication, which increases developer efforts.

With the addition of a new moving layer, comes in the pain of managing, maintaining and monitoring it.

Having a new layer adds an extra network hop and in turn increases the latency of the application. Some applications like e-commerce apps or fintech dashboards benefit from it given their presence on multiple devices. But this would really harm the performance of real-time systems like High frequency trading.

After this entire discussion, it is definitely a head-scratcher to decide when to have this BFF in your system. Here are some real use-cases where a BFF seems very much handy and useful.

1. When the client interfaces are significantly different from each other, BFF brings in a heap load of advantages. The backend stays generic and simple and multiple BFFs can serve the multiple clients as per their need.

2. Format of communication of the client is very different. Suppose a legacy client using XML to render information has a backend with JSON responses. Here the conversion can be handled by XML with the use of a XML BFF.

One should also note that, given the complexity of the application resulting after the integration of another layer(BFF), increases the team size and product value than a SPA.

A BFF is not a default architectural choice(contrary to the actual need of a Best Friend Forever lol), but a conscious trade-off. It shines when client experiences diverge, payloads and protocols vary, and frontend teams need speed and autonomy, while keeping the core backend clean and generic, empowering modern, multi-device applications.

A story on Frontend Architectures - Birth of the FE engineer

Purneswar Prasad — Fri, 12 Dec 2025 19:33:47 +0000

With the last 2 blogs, we understood a lot about application architecture patterns and how isolation of business logic and the code is an essential element at an organisational level. A small decision wrongly taken before building the application can lead to inconsistencies later in the application stage, where a change can be too costly(both in time and money) to incur.

But since we're talking about Frontend Architecture patterns, it's very essential to understand how the entire page gets delivered and updated to the user too, So going forward, we'll discuss more about application-level architectures for web products like:

SPAs (React, Vue, Angular — client-rendered)

BFF (Backend for Frontend)

SSG/ISR/SSR (Next.js, Nuxt, Astro)

Frontend Monoliths

Microfrontends

In this blog, we'll learn about how SPA(Single Page Applications) came into the picture and what did they bring to the table.

Before SPAs, there were MPAs or Multi Page Applications. These, as the name suggests, were Multi because of the way they rendered pages. Every interaction rendered a new HTML page, reloading the old screen. These were mostly server-controlled applications (thin client) with very minimal JS dependency, but very slow UX.

To resolve this issue of entire page reload, AJAX was born. AJAX stands for Asynchronous JavaScript and XML. It introduced the XMLHttpRequest (XHR) API, letting pages request data without reloading. This is called partial updates. The concept of Promises and callbacks was born, later which came to be known as fetch().

But as apps grew, thus grew the need of a faster JS execution speed. Doing DOM manipulations and complex UI logic on slower JS engines was painful. And also maintaining apps with so many XHR calls and DOM changes turned out be a challenge. Thus came, probably one of the most revolutionary moment in web development history, Google's V8 engine.

V8, at a high level:

introduced JIT(Just In Time) compilation, which compiled JS code to native machine code instead of line-by-line interpretation
implemented optimisations like hidden classes, inline caching, and a modern garbage collector

This also enabled the creation of Node.js (2009) and huge server/client ecosystem growth. Here's a video on JS Engine internals and the V8's architecture in detail.

These pieces along with some others like client-side routing(history API), concept of virtual DOM and componentization of modules, bundlers together produced single page capabilities: no reload on navigation, client-rendered UIs and modular code.

With all these benefits, SPAs can be considered as a landmark in frontend engineering and quite honestly gave rise to the role of a frontend engineer. There is an option for a lot more interactivity and complex engineering ideas to be implemented on the web and thus came the, quite infamous, rise of dashboards and SaaS. And this in turn, was adopted and some groundbreaking libraries were created by top product companies.

The evolution continues — SPAs didn’t end the story; they changed it...

A story on Frontend Architectures - MVVM, the Separation of Concerns

Purneswar Prasad — Wed, 10 Dec 2025 09:22:19 +0000

We read earlier on how MVC marked a shift in engineering thinking and architectural patterns, coming from no structure at all while writing code to having a clear triad in the form of MVC while creating an application.

Although MVC as a concept at its birth was more of a server-heavy architecture with most of the processing load on the Controller and the View layer just managing user input and for displaying data on the screen.

When we're along these lines, let's know of 2 more things:

Thin Client - As the name suggests, here the client is thin, or it is involved in a lot less workload than the server. These are the kind of architectures followed in traditional multi-page applications or static sites.
Thick Client - This is just the reverse of the above, where significant data processing happens on the client side. For e.g.- Single Page Applications, offline-first applications etc.

But this was not a very prominent concept back in the day when applications were a lot less interactive. Modern web-apps follow a thick client architecture.

Let's see how a modern MVC web-app looks like

Modern MVC apps don't need a backend server, they can work purely on the frontend itself with Redux state management working as Model, Hooks as the Controller and React components as the View layer.

And extending on the same logic, there was the inception of HMVC (Hierarchical MVCs), where instead of having a single MVC structure across the system, we break down the app into nested modular MVC components.
Much like the modern-day structure:

But MVC weren't the last-stop solution. In-fact the concept gave rise to a lot of discussions and possible improvements. For the pros, they are easy to understand, develop and maintain.

But on the cons, with increasing complexity and sophistication in applications the boundary between the different layers start looking blurry.
Let's take the case of a fat controller. A fat controller is what the controller started turning into as the handling of events got passed down from the View. It has to send requests to the server, handle API responses, sync data with the backend and also do client-side caching.

And so comes the next architectural pattern, a change focusing on differentiating the UI and business logic entirely: MVVM(Model-View-ViewModel)

Let's understand the difference between the UI and business logic.

UI/View Logic	Business logic
Closing a window	Changing the username
Disabling a button	Making a transaction
Updating the download status	Updating wishlist content

How does MVVM differs between the View and Business logic?

The Model - consists of the domain data(e.g. User, Order, Invoice, + services like userApi, authService, etc.) and business rules (cart must have at least one item to checkout)

The View - actual UI the user sees, which in React us implemented by the JSX.

And here, instead of the Controller, which earlier used to handle requests and decide what happens next, is now replaced by the View Model.

View Model is the brain sitting between the View and the Model. It exposes state and actions is a View-friendly form.

How MVVM separates them

Views:

Render JSX based on props and ViewModel state.
Call ViewModel methods on user actions (onClick, onChange etc.).
Contain only presentation logic (show/hide, format dates, mapping arrays to lists).

ViewModels:

Own the screen state i.e. isLoading, error, selectedUser, etc.
Wrap all business logic + async operations like loadUsers, saveUser, deleteUser.
Transform raw models into a shape that’s easy for the View. e.g. from [{ firstName, lastName }] ➜ [{ fullName, initials }].

MVVM brings along with it a concept called 2-way binding. As the name suggests, it helps the data bind both ways.

When the ViewModel changes → the View updates automatically.
When the user changes something in the View → the ViewModel updates automatically.

This is not something that we'd directly get out-of-the-box in a library like React, but it can be implemented in this fashion:

1) ViewModel exposes value + setter

import { useState } from "react";

export function useProfileViewModel() {
  const [name, setName] = useState("");

  function updateName(newName: string) {
    setName(newName); // updates ViewModel state (Model -> View)
  }

  return {
    name,
    updateName,
  };
}

In MVVM:
name is the ViewModel state watched by the View.
updateName is the command that changes the state.

2) The View binds the UI element to the ViewModel

export function ProfilePage() {
  const { name, updateName } = useProfileViewModel();

  return (
    <input
      value={name}                                  // ViewModel → View
      onChange={(e) => updateName(e.target.value)}  // View → ViewModel
    />
  );
}

Multiple Views can share a single View Model but the vice-versa doesn't apply.
A single View cannot bring its data from multiple View Models!

In the early frontend architectures like the MVC days

UI elements were manipulated directly
Data was not bindable
There was no place to store UI state (like loading, error, filters, selected item)
The View was responsible for everything — DOM operations, formatting, logic, even data fetching

This meant the front-end was:
❌ Not reactive
❌ Hard to test
❌ Hard to scale
❌ Very brittle

There was no unified idea of “the UI is a function of state.”

MVVM is one of the first architectural patterns that formally brought the concept of state into frontend development.

Let's discuss some pros and cons:

Pros	Cons
Clear layer separation between UI, Business and presentation logic	With higher modularisation of the application, the learning curve is a bit steeper
The higher decoupling makes it easier to scale and test	MVVM doesn't give you a place to organise all the other application concerns like API requests / data fetching logic, Caching, Authentication logic

A small enhancement on top of the MMVM architecture is the introduction of the Coordinator into the architecture: effectively making it MMVM-C. The job of the coordinator is to separate screen transitions and navigations out of the View layer, thus decoupling the View even further.
And similar to this, came another enhancement, VIPER, where the business logic is even more isolated from the rest of the components and solved the issue of "fat ViewModels". This is mostly developed to be used in mobile applications, but can also be used for web apps.

While MVVM wasn’t the final stop in architectural evolution, it paved the way for more expressive patterns and a deeper understanding of how applications should be structured as they scale.

The story continues...

A story on Frontend Architectures - MVC, the MVP

Purneswar Prasad — Mon, 01 Dec 2025 18:45:11 +0000

The evolution of frontend engineering goes back to the time when the World Wide Web(WWW) was a flashy thing and just like today's(most possibly!) AI bubble, there was the dot-com bubble.

Websites at that time weren’t filled with animations, 3D rendering, colourful dynamic fonts, or immersive interactions like we see today. They were as static as a magazine, consisting of plain HTML and CSS, with very less interactivity from just a little sprinkle of JavaScript.

HTML wasn’t designed for applications; it was built to serve documents, much like PDFs. Everything was rendered on the server, and nothing interesting happened on the client.

Mind it, they were super fast… but also super boring for human eyes!

With increasing internet popularity, the need of sophisticated websites also grew. People wanted to be shown greetings when they login, their shopping cart when they purchase, know the weather etc. and static HTML couldn't do this.

So the web needed server-side logic where pages were no longer stored but are generated on the go, birthing the real software development era.

But again, there was no predefined rule on how dynamic pages are to be created and how the code needs to be structured.

Dynamic pages were rendered like this

const http = require("http");

http.createServer((req, res) => {
  const name = "John";
  const products = ["Pen", "Notebook", "Bag"];

  let html = `
  <html>
    <body>
      Hello ${name}
      <ul>
        ${products.map(p => `<li>${p}</li>`).join("")}
      </ul>
    </body>
  </html>
  `;

  res.setHeader("Content-Type", "text/html");
  res.end(html);
}).listen(3000);

What we see above is called "spaghetti code", where the logic + HTML + SQL + loops + conditions is all mixed in one file.

And with the explosion of the WWW and the incoming of the several online applications and businesses requiring user sessions, validations, access control, complex business logic, a structure was desperately needed.

A good architecture in systems is essential for 3 important things:

Flexibility of changing parts of the application when no longer needed and to stay updated with new frameworks
Testability of the application, boiling down to its individual layers
Scalability of the application's individual parts as well as the whole of it

This was also the time when popular object oriented backend programming languages(Java, C#, Python) were coming up and what better time than then to enforce a standard that would leave a mark on the world of software engineering!

Enter MVC

To address the problems above, comes the standard of MVC - Model, View & Controller architecture.
MVC solves 3 main pain points:

Separates the mixing of HTML and backend logic
Database queries are grouped together rather than being scattered
The whole engineering team has now a well-defined structure:
- Database Engineers for the Model
- Designers for the View
- Backend Engineers for the Controller

Let's understand what the MVC architecture model a little bit in depth and how the data-flow works. Refer to the image below:

Suppose I have an application in a MVC structure to which the user sends a request:

The request goes to the router which sees the kind of request made by the user
Router forwards the request to the controller for the particular route
Controller sees the need to call the Model which has the power to manipulate the database according to the particular request
The Model then talks to(queries) the database
The database results are sent back to the Model
Model sends the data back to the controller
Controller sends the data to the View to be parsed in a HTML template
The server sends the rendered HTML back to the user.

And this is how the data-flow works inside the MVC architecture.

Let's break down the above "spaghetti code" into a clean MVC model!

 models/
    products.js
  controllers/
    homepage.js
  views/
    home.ejs
  app.js

Model (models/products.js)

exports.getProducts = () => {
  return ["Pen", "Notebook", "Bag"];
};

Controller (controllers/homepage.js)

const ProductModel = require("../models/products");

exports.homePage = (req, res) => {
  const name = "John";
  const products = ProductModel.getProducts();

  res.render("home", { name, products });
};

View (views/home.ejs)

<html>
  <body>
    Hello <%= name %>
    <ul>
      <% products.forEach(p => { %>
        <li><%= p %></li>
      <% }) %>
    </ul>
  </body>
</html>

Entry point (app.js)

const express = require("express");
const app = express();
const homeController = require("./controllers/homepage");

app.set("view engine", "ejs");

app.get("/", homeController.homePage);

app.listen(3000);

Above, we broke the code into modular parts separating concerns into different folders, with proper semantic conventions of MVC architecture, thus making it easy to debug, maintain and scale.

MVC marked the web’s shift from scattered, unstructured scripts to clean, maintainable, production-ready applications.
It laid the foundation for all modern frameworks, including the frontends we build today.

Polyfills - a filler or a gaping hole? (Part-2)

Purneswar Prasad — Thu, 29 Aug 2024 20:29:39 +0000

We'd discussed some very interesting topics like transpilers and polyfills in the last blog and came across a popular transpiler, Babel and how its polyfill package was deprecated and the use of required alternatives.

Moving on from here, our main focus will be on polyfills and a very special and popular (or now, unpopular) service, Polyfill.io
This name has been around quite a lot now, and if you've not been living under a rock, you'd be knowing of the kind of security issues that it brought with itself, almost affecting 300k+ sites (4% of the web) across the internet.

Let me walk you again through some history, which might give some perspective on how things transpired:
There are a lot of open-source libraries out there providing polyfill supports, among which polyfill.js is a popular one. It used the service Polyfill.io, developed by the Financial Times, to serve polyfills based on the user's browser.

Things started to get fishy way back in June 2023 - when Google gave a security warning to its advertisers regarding a possibility of users getting redirected to malicious websites if they click on their ads, which might be using these libraries
Cut to February 2024, we hear from the creator of the polyfill service project, who raised concerns about the project and its new ownership. Now later that time, we come to know that Funnull, a CDN service provider in China has acquired the Polyfill.io domain and its GitHub account. Cloudflare, a CDN and cybersecurity service provider, also came up with its own alternative solution to what might be a future problem, due to concerns in the community relating to Polyfill.io.
Come June 2024, we hear everywhere across the internet to check if your website uses cdn.polyfill.io and to get it removed ASAP!

What happened suddenly? Is it time to say goodbye to old browsers and forget about polyfills? Are we really witnessing another worldwide cybercrime?

Let's dive into some sweet details.

You read earlier that Funnull, a CDN service provider acquired the polyfill domain. What does a CDN do?
CDN stands for Content Delivery Network. Now imagine, if you'd a server very far somewhere and you need to provide service to users all around the world. Different users may get different experience while loading your site, the fastest being the happiest and the slowest might not even wait for it to load. CDN comes in handy here, where it keeps a copy of the main server's content, spread across the globe, so it can be retrieved anytime.

Funnull would've taken over the polyfill.io domain with the promise of a better experience to its users with its widespread network of CDNs. But something happened during the handover of the GitHub account.
Polyfill.io, being one of the top domains for polyfill usage, used Cloudflare's services, like CDN, scalability, security, DNS management etc. You must be knowing, to use any service on your platform you need an API key. This key, unique to every app, tells the service that it needs to use its data for its purpose.
And logically, this key needs to be protected from the public to prevent any kind of unauthorized access or abuse of the service.

But what if your website is taken over, like in the case of Polyfill.io? Do the new owners get control of the keys?

Well, there are certain practices like :
1) Rotating API keys - generate new API keys in regular intervals
2) Limit Key access - ensuring you restrict access on what services can be granted access
3) Using secure channels - any kind of transfer should happen over a secure, encrypted channel

Here, the owners did a blunder during the transition, by accidentally uploading an .env file(used to store secrets) to the public repository

Now, this leak gave access to the Cloudflare account and in turn, they managed to change its DNS(Domain Name System) records. Think of DNS records as an internet's address book of different websites/domains, which contain important information about the websites.

One such record is called CNAME. For cdn.polyfill.io, the CNAME record was changed to a malicious domain by the attackers to cdn.polyfill.io.bsclink.cn, a China-based CDN domain hosted by Baishan Cloud. Thus, going on to inject malicious JS code through it, details of which are very clearly pointed out here by Sansec Research, one of the very first ones to write publicly about the incident.

Along with polyfill.io, several other domains associated with the same Cloudflare account were also flagged under malicious ownership like :
bootcdn.net, bootcss.com, staticfile.net, staticfile.org, unionadjs.com, xhsbpza.com, union.macoms.la, newcrbpc.com. And the same action is recommended: stop using them!

Later, the domain was taken down and easy alternative to mirror the polyfill functionality was provided by Cloudflare.

Phew, that was some information!

Who is responsible for all this? The owner who sold it? The projects who used it? The warnings that were ignored?

Well, when matters are of cybersecurity, there's never a single entity involved.

1) Consider this tweet, which shows proofs of the sale. If you'd seen the tweet of the founder earlier on top, he denies any influence over the sale.
Well, who do we blame here? Maintaining an open source project requires a lot of efforts from the community and the maintainers. There are several layers to the governance. And projects which are so widely used, like polyfill.io, need to be updated at all times. This requires time out of your daily schedule and contributing for a better developer experience around the world. And only a few do really know the ins and outs of a project.
Funding is a big part of an open-source project, without which it's very difficult to carry on day-to-day tasks for maintainers.
Here's a heart-wrenching example of the core-js library we'd talked about in the 1st part. I recommend everyone to go through this once and understand the efforts and create maintainer relationships.

2) As mentioned, projects that got affected used the cdn.polyfill.io in the src of a script tag. Using an integrity attribute in a script tag ensures that the content of the external script hasn't been tampered with.

3) Importance of educating users and application owners about the risks and best practices of security, authentication, access control and regular auditing.

Conclusion
Open-source software is built on collaboration and trust. By respecting the sanctity of its ecosystem, we ensure that it remains a vibrant and secure environment for developers and users alike.

Links to some insightful articles:

Polyfills - a filler or a gaping hole? (Part-1)

Purneswar Prasad — Mon, 26 Aug 2024 17:36:47 +0000

A few days back, we received a priority message in our organization's Teams chat, which read: Security Vulnerability found - Polyfill JavaScript detected - HIGH.
To give a context, I work for a major banking firm and as you must know, banking and security vulnerabilities are like major foes. So, we started to dig deep into the matter and got it resolved in a few hours, which I'll discuss in the following. But the good (or worst?) part is when I googled about the issue initially, the search results that popped up kept me hooked for the rest of the day!

Let's highlight a discrepancy between a modern and a legacy browser. Here’s a comparison of the latest Chrome release versus Internet Explorer (IE) 9. Modern browsers support a whole lot of ES6 features and at the same time, IE9 and also IE11, which are still used by a lot of companies barely support any ES6 features.
Here comes to help the concept of transpiling, which in the context of JavaScript, refers to converting source code written in modern JavaScript (ES6/ES2015 and beyond) into an older version like ES5, which is widely supported by older browsers. A very popular transpiler is Babel, which offers a range of features like syntax transformation, code bundling (along with Webpack) and support for JSX (for our sweet friend, React!).

Now, use of transpilers is very common at places where there is a lot of modern syntax, and one has to ensure the compatibility across different environments. Do note that converting an entire codebase into a different version requires a heck lot of time and also setting up a build process and additional configuration for things like Babel. It goes untold that, along with converting syntactical features, API functionality to extend the same feature replication in old browser is also covered.

Coming to the reference of Babel, it constitutes a lot of packages, providing plugins for different kinds of functionalities like transforming ES6 classes, arrow functions, etc. into equivalent JS code. Among this, it also offers its own "polyfill" package.

Polyfills are pieces of code which enable old browsers to provide the same/almost same JS functionality, which they don't natively provide, that is shown in newer browser versions. Here's a quick video example and very simple implementation.

Now one might think, then what's the difference between transpilers and polyfills? Well, polyfills focus on emulating specific APIs which are missing rather than changing the entire codebase into an old-browser-friendly version done by transpilers. This allows for a more granular approach and of course, making it more efficient and performant.

This should give us enough background to get to the point to why I got hooked for a day till the very moment I'm writing this, about polyfills.

Now, Babel has a package called babel/polyfill which constitutes of 2 libraries: core-js and regenerator-runtime. Initially, importing this package would bring in all the polyfills into action.

import '@babel/polyfill';

But bringing in everything whether your project would use them or not, increased the bundle size and injecting polyfills globally might lead to conflicts in objects.
This led to deprecating the package and Babel recommends using the core-js library directly by
Step 1: Modifying the babel configuration

{
  "presets": [
    ["@babel/preset-env", {
      "useBuiltIns": "usage",
      "corejs": 3
    }]
  ]
}

Step 2: Manually import the polyfills that you'd use in your project

import "core-js/es/array/includes";
import "core-js/es/promise";

thus, saving memory and reducing unnecessary code.

Now, this is the end of one part, not so concerning per se, but definitely important in regard of a project, staying up to date with the changes in dependencies, serving their customers a better experience.

BUT. This is not all.

We're about to discuss a major attack which took place recently and shook up the entire internet and got them scouring their codebase.
And, it includes the thing which we've discussed over here. So stay tuned for the second part!

A First Timer's Journey at KubeCon

Purneswar Prasad — Sun, 24 Oct 2021 21:24:26 +0000

Let's have some context: KubeCon+CloudNativeCon is one of the biggest conferences in the world where users, developers and companies who have/want to adopt the Cloud Native standard of running applications and use Kubernetes in their organizations, gather and discuss new ideas, learn deeper insights about it, make connections and have fun. Lots of amazing talks, events, meetups, parties, competitions happen in a span of 5 days, which can make a newbie fall in love with this awesome community.

This year KubeCon was held both virtually and in-person at North America and it was fun to browse through the spaces from my laptop and get live updates from in-person attendees through Twitter. So, I thought to pen down my takeaways of the keynotes and learnings of some events I attended which I felt can be interesting and helpful for someone new to the community. Since this is gonna be a bit elaborate, I'll group them day-wise and event wise for better navigation.

Prologue

I came to know about this event since July while going through the Kubernetes website and was very excited for the upcoming one. This time there was a scholarship for students, which gave access to a lot of paid events for free, so many students were joining for the first time. As days went by, both the noise of the event and my excitement(being virtual was still a bummer) grew exponentially!

DAY-1

The CNCF has a great initiative of connecting people over a video chat called Mix-and-Mingle. Folks were talking about a lot of different topics; on Kubernetes, some exciting talks, career paths; the whole day. Fun-fact: at one point of time we were talking about genetics and evolution, so if you're ever attending this event, don't forget to drop-by and say a Hi!
Also, this happened:
// Detect dark theme var iframe = document.getElementById('tweet-1448712007318839297-608'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1448712007318839297&theme=dark" }
The first two days were reserved for co-located events(Events on a specific domain of work such as ServiceMesh Con, Security Con, Data on Kubernetes day etc.), which are more of industry oriented and not something I was interested in.

DAY-2

# College to Cloud Native: A Student's Introduction to KubeCon + CloudNativeCon

It started with a great introduction to the cloud native space and CNCF for college students by Bill Mulligan(@breakawaybilly) and Savitha Raghunathan(@coffeeartgirl). They discussed how someone completely new to the ecosystem and learn on the go and contribute parallelly. Since there was a platform of different things for the virtual event access, they went through the website to clarify doubts regarding accessibility and discussed job opportunities at big companies and startups, exciting upcoming sessions, mentoring sessions and also how can one get started with Kubernetes. Starting out can be a real problem for newbies and Savitha described her own experience on how she got to meet amazing folks, know about the community and gain a lot of knowledge by contributing to small things and gradually moving up. Bonus point: if you want to have a healthy and fast growth in the community and writing excites you, look out for SIG-Docs. It's one of the easiest things to do and also a preferred starting place for many, as it's plane English and if technology interests you, you can just write about it and improve the official documentation. This helps a great deal to new contributors and also existing ones to understand the subject matter.

# Data on Kubernetes Day

Next was a co-located event, "DoK Day" by the Data on Kubernetes Community, of which I'm a proud member😁. It started with a brief introduction by the community interns, featured some of the best practices by experts of running data on Kubernetes, technical challenges faced, use cases, learnings and finally ending with some good quiz, which can get you some cool swags. Shoutout to the very cool Bart Farrell(@birthmarkbart) to organize this flawlessly! Anyone wanting to join us, here's the slack, you're most welcome! - dokcommunity.slack.com

DAY-3

Finally it's time for the main event. Keynotes, sessions, one-on-one mentoring events and much more!

# Building your Brand with CNCF

Bill Mulligan(@breakawaybilly) and Charley Mann(@Charley_Mann) discussed how students and end users can leverage CNCF opportunities to build their own brand. There are various tiers of membership you can opt for, which gets you social and marketing benefits and also as a student, you can submit your blogs, create your own community to be a CNCF ambassador. Adding to that, there are many certifications by the CNCF and The Linux Foundation, which are recognized industry-wide and can help propel your career in Cloud Native and Kubernetes.

KEYNOTE 1

The GM of CNCF, Priyanka Sharma(@pritianka) kicked it off with some great announcements like new sponsors, big increase in community members in less than 6 months & announcement of a new certificate "Kubernetes and Cloud Native associate" for beginners to the space. Security was the hottest topic of discussion this year and OpenSSF(@theopenssf) was introduced for the safeguarding and long term benefit of open source software. Diversity and Inclusion holds a major spot in the open source community and the indigenous culture was presented with a song to set the mood.
The concept of multicluster, its architecture and the need to do so were discussed by Kaslin Fields(@kaslinfields) with her very own artwork. Join SIG-Multicluster and SIG-Networking for more info.
Lots of cloud native projects moved from sandbox to incubation stage and some to graduation(levels of acceptance of a project). Here's the CNCF landscape for reference.
Finally, Cornelia Davis(@cdavisafc) explained how projects move through the levels of maturity and made a big announcement. For first timers, there is a concept of SIG which are now called TAG(Technical Advisory Groups). These TAGs cover different areas of the landscape.

# Why is Anyone using Kubernetes Anyway?

This session sounded a lot relatable as this is an obvious question from someone new into this community "Why do I need to learn it anyway?". The folks from SIG-Usability(Tasha Drew(@TashaDrew), Josephene Pynadath, Gaby Moreno Cesar(@morengab) & Carl J Pearson(@carljpearson) perform extensive market research, 1-on-1 interviews with developers, end-users and make sure their perspectives and workflows are addressed. They make recommendations on how and where to store documentations, practice videos, tutorials for anyone to get started and also for experienced folks to get access to important info.
To address the elephant in the room, people are pulled into this "Kubernetes" mostly because of the hype and everyone wants to try it. But they stay due to the awesome community it provides and high-end infrastructure design that makes life easier for developers. This can be a roadblock as not everyone likes to know how the backend is designed. And also the upgrades and frequent updates can be challenging to adopt with by an organization. They also share tips on how to contribute and be a part of the team.

# Putting into Practice the Skills you've learned while contributing to Kubernetes

Towards the end of the day, there was a good session on applying the skills learnt while contributing to Kubernetes by Kiran Oliver(@kiran_oliver).
He discussed on how to involve yourself in meetings, attending and organizing meetups and putting yourself out there and create content in your own voice. He focused on sharing your expertise, unify, teach and inspire others. There are a lot of problems which one might have faced while trying to contribute to the project. And there's always a chance this can happen to others. So, helping them goes a long way to strengthen the community and learn things at a good pace. Progress, as much as we want it to be, isn't linear, quoting him "this isn't a traditional Zelda dungeon, it's a breath in the wild". These are important points to take note of while going through your path of being a contributor.

Here, I'd also like to give a shoutout to the session, which happened in parallel, on "Kubernetes SIG-Docs: A Deep Dive". SIG-Docs have been the starting place for many experienced and new contributors and is a must-watch to know how things revolve and operate around there.

DAY-4

KEYNOTE 2

The very cool, Stephen Augustus(@stephenaugustus), kicked the day off by giving project updates. The Code of Conduct committee released a transparency report which makes community members feel psychologically safe. SIG Security, one of the newer SIGs, is doing some great work, providing hardening guides and cross-platform work, as Security was the main topic of discussion. The release of newer versions(done by SIG-Release) now has a proper roadmap. Persistent storage is now a priority and SIG-Storage needs new folks to work on that(shoutout to Data on Kubernetes Community). Inclusivity being a big factor in Open Source, led to a Inclusive Naming Initiative group. Focus was given on hiring technical writers for SIG Docs.
Next up, Vaibhav Kamra(CTO of @kastenhq) discussed the surge of attendees of KubeCon over the years and also unveiled a new open source project, kubestr.io and also provides free training for it.
Katelin Ramer(@wussowk) and Kim McMahon(@kamcmahon) talked about CNCF and RISC-V(@risc_v), leading the open-hardware environment. They talked about how better solutions can be come up by building together and good alliances.
The CNCF community has grown to a very big community and Constance Caramanolis(@ccaramanolis) discussed about the future, the underlying projects, user burden, challenges faced by companies and means to sustain them. Not something surprising, more than 90% of folks know about Kubernetes first instead of any other project.
Jasmine James(@gojasmineee) talked about creating holistic Developer Experience creating 4 human centered pillars- Discoverability, Usability, Capability and Stability, to address developer challenges.
On an ending note, Lachlan Evenson(@LachlanEvenson) told us about networking(pretty hard stuff xD) and Robert Duffy discussed how the Expedia Group is leveraging the Cloud Native landscape.

# A Vulnerable Tale about Burnout

Mental health has always been a priority in this fast moving world and the issue of burnout is quite frequent among professionals, but often neglected. We always talk about max productivity at workplace and everywhere and working hard to reach "the dream place". Yet, a big part of our lives stays unnoticed and the consequences are severe. Julia Simon(@JuliaSimon14) shared her very own story "A Vulnerable Tale about Burnout" of being in depression and suffering a complete burnout, the factors leading to those, some mistakes she made on the way and how she recovered from that to take control of her own life and curated a list of everyday events to be happy on her own. She also shared some small steps that one can take to be productive and stay happy in life.

# Panel Discussion: Cloud Native Computing Foundation Mentees

Great panel discussion on Open Source mentorship(LFX Mentorship) and getting started in Open Source in general by Kunal Kushwaha (@kunalstwt), Divya Mohan(@Divya_Mohan02), Uchechukwu Obasi (@Thisisobate) & Developer Advocate of CNCF, Ihor Dvoretskyi (@idvoretskyi).
Here's a thread I compiled about the learnings, which can be very helpful to get a bird's eye view of the entire session: // Detect dark theme var iframe = document.getElementById('tweet-1448735994736373767-172'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1448735994736373767&theme=dark" }

# Getting Involved in the K8s Release Shadow Program

Divya Mohan(@Divya_Mohan02) discussed about the Kubernetes release shadow program and how one can apply to be a shadow.
The release committee is designed as:
Emeritus adviser -> Different release teams(enhancements, docs, comms etc.) -> Their shadows.
It is NOT an internship and surely not the only way to knowing about Kubernetes. It is basically an apprenticeship model, helping with coordinating and facilitating of tasks. Through this process, one can gain knowledge on release process of a new version in an open source project and its importance to the stakeholders. Apart from that, you can also learn in depth about what various SIGs are working on. The time commitment is of 3-4 months. As Divya says, "the time you put into something is what you get out of it".
Anyone can apply for this and no prior knowledge or experience of release process or coding expertise is needed. Though some prior involvement can be very beneficial. It's an extremely competitive process with 100+ applications(increasing every release cycle) for about 20 odd seats, but can be a big boost to your resume.

# Beyond Block Diagrams: Different Ways of Understanding K8s Architecture

Learning about the vast infrastructure behind the design of Kubernetes can be challenging in a world where things are automated development is prioritized nowadays and that's what Kim Schlesinger(@kimschles) terms as Cloud native generation: writes software and deploys it into cloud and discussed along. It's difficult for them to know how architectural design happens in the backend. She shared 3 methods:

Mental model/Mental representation Create diagrams that show the sequential process of things with passage of time. Although this is vastly used, there are chances that people just try to mug up rather than getting a real feel of what's happening.
Distributed tracing technology as a learning tool Method used to profile and monitor applications built using microservice architecture. She explained the process with a demo example application executing the sequential processes.
Build 3D models of clusters. Here's something cool that she built on her own to "feel" the Kubernetes design:- This kind of interactive learning can be very effective to learn and memorize.

DAY-5

The day started off with a candid chat "AMA Coffee Klatch" of lot of folks with Priyanka Sharma(@pritianka) over a Zoom call. It was a fun session where you could ask about anything that happens in and around CNCF and how you can be involved with answers straight out of the mouth of the General Manager herself. A must-attend in every KubeCon!

Time for the final KubeCon keynote and the day, a bit sad that it's ending but the past few days had been nothing but awesome.

KEYNOTE 3

The keynote kicked off with Machine Learning on Kubernetes by Jimmy Guerrero(@_jimmyguerrero) and Masoud Mirmomeni. They talked about skills shortage for getting projects into production, challenges faced by ML especially and how Kubeflow helps in solving them.
The theme of Security was continued by Luke Hinds(@decodebytes) speaking about sigstore(@projectsigstore). He emphasized on how critical services are built on open source software.
Paris Pittman(@ParisInBmore) and Christoph Blecker(@tophee) talked about sustaining the community, key to open source success with focus on SIG-Contributor Experience. The community has grown from 8k to 66k contributors and still a lot is left to do and learn. Documented roles help the community sustain and grow past ourselves. Companies are called out to sponsor their employees contributing to Open Source and Kubernetes to have a production ready project. There is always a need for new contributors and the community welcomes them.
Stephen Augustus(@stephenaugustus) shared some useful messages on prioritizing health, burnouts, taking a step back and scaling yourself on the contributor ladder. In his words "If you're the only person in the world that can do the thing, you're wrong. Go record the demo or write the blog".
SBOM(Software Bill of Materials) is a new concept around here and was discussed by Allan Friedman(@allanfriedman). It's basically a list of ingredients that constitutes your code and you can also get started by creating them.
Then came the best part of the keynote, Award ceremony! The best contributors and maintainers are recognized on the grand stage. Here is the list of winners. With this the KubeCon NA 2021 keynote came to a end, but....with the announcement of the next KubeCon in Valencia, Spain!!

# SIG Contributor Experience Deep Dive- Alison Dowdney(@alisondowdney), Bob Killen(@MrBobbyTables) & Christoph Blecker(@tophee)

One of the few SIGs where folks can start out and also people in leadership position to know about new tools, policies and procedures in which things work around in the Kubernetes community. The teams are divided into multiple domains like Events, Marketing, managing GitHub, YouTube, Zoom and Community activities.
Some subprojects under them are:

Contributor site (k8s.dev): publishes contributor guide, community Calendar which has list of all meetings happening and scheduled over the week and in the future and Release information.
Community Repo(kubernetes/community): contains governance documentation, election procedures etc.
Contributor Comms: Contributor twitter (@K8sContributors) handles latest developments, new features and contributing opportunities, which are also managed by a automated twitter bot.
Manage the membership roles for folks to go up the contributor ladder.
Mentoring for new contributors through Group mentoring cohorts, Shadow programs, Google Summer of Code, Contributor workshop etc.

How can you contribute:
-> Subscribe to Contrib-Ex Mailing list
-> Attend SIG meetings regularly to stay in context of what's
happening
-> Find a buddy
-> Volunteer to take notes during the meeting
-> Small contribution > Volunteering for the world
-> Look out for Good First Issues as they boost your confidence
-> Not only code, but also marketing

# Peer Group Mentoring & Career Networking

This was a fun & intuitive session of interacting with fellow learners and some expert contributors. We were paired up randomly and sent into different breakout rooms, where there was a specific mentor and you could ask questions, interact and network. One of my most best conversations happened here when the technical sales lead of a Kubernetes provider company was our mentor for some 15 minutes. I came to know about the approximate cost of creating your own Kubernetes service and why companies prefer using services of other providers and not create their own. He also asked about me and how I was doing in my career.
Since this is a 1-on-1 conversation, this is a great opportunity for students to increase their networking and knowledge.

# Homebrewing a Kubernetes Bootcamp: From College to K8s Support Engineer

Being a fresh college student or a recent graduate, learning something vast as Kubernetes can be a very overwhelming. Alice Wasko(@AliceWasko) took us through her experience as a fresh hire from college needing to learn it for the company and how she set up her own bootcamp and tips for anyone to set up one for themselves.
1) Some previous basic knowledge can help, but it's never too late to learn.
2) List out what you want to learn first(some basic container mechanism with Docker and basic Kubernetes terms like Pods, Deployments & Service can be a good starting point)
3) Structure your learning plan/Figure out the why of stuff like:

Deployments create Pods
Pods run containers
Services help in distributing traffic
How traffic get to where it needs to
What kind of service to service communication

4) Try some hands-on with a small piece of code or build a small app and test it out by changing stuff. This can help you set the base to learn more advanced topics

Try building a Hello world app

5) Go in depth of the basic things you learned earlier such as architectural designs and networking in detail.
6) Learning resources like Documentations, Blogs and Videos are great to refer. But always have flexibility as not everyone learn in the same way.
7) Organize learning materials in the order of beginner to expert understanding.
8) Get feedback from people and try to work on it together to improve the content. In her words "It's a never ending project".
Finally, always know that planning out such a roadmap has the potential to make you a pro in the subject as well as smoothen the learning journey.

With this, my first KubeCon came to an end. I got to know a lot about what happens in the community and met some new people online who were both fun to talk and share ideas. Since there were about 5 to 6 meetings in every time slot, it wasn't possible to attend each one. There were also other fun games happening throughout these 5 days like BugBash, BattleSnake KubeCon Cup, whose winners were awarded at the end. The SIG deep-dives are really helpful for anyone needing to find a domain in which they feel a bit comfortable to work on. And also, a big thanks to the team of cloudnative.tv whose daily wrap-up gave a brief, insightful overview of all the events that happened everyday.

I definitely carry a lot of knowledge and to-do activities with me to move forward and hope any new contributor reading this would go and watch the recording of the above-mentioned sessions(if haven't) to have a nice headstart to begin their own journey!

Data Resiliency

Purneswar Prasad — Wed, 06 Oct 2021 13:33:00 +0000

Before knowing what the keyword(Resiliency) means, let's understand what led to this concept.

Consider the example of a fiber optic connection between 2 buildings. Just to have a backup, there is always a second/replica connection in case of a failure. This is called Redundancy.

But there's a problem with this arrangement. If there are any external factors like construction, pests etc., both the wires can be exposed at the very same time, thus resulting in complete failure of connection if they're destroyed.
Thus, the inception of the term Resiliency.

Resiliency is the capacity to recover quickly from difficulties, self-heal the system and converge back to the original state.

The exact same connection can be laid out in a way where the backup wire can be laid, connecting different locations of the 2 buildings. So, if one of them is exposed, the other stays completely safe!

Let's learn its significance in the cloud & cloud-native space:

While talking about systems and resiliency in cloud, there are certain terminologies which come into action. Some of these are availability, reliability, durability and of course, resiliency. They are used to measure how a certain request by the user is handled by the server and determine the metrics. This is a nice blogpost explaining these terms in detail.

The cloud native space have opened a new domain of engineers assigned for this role called as Site Reliability Engineers(SREs). Every company, big or small, prioritizes their customers and should be available for every small request. So, SREs follow certain contracts with the clients to maintain a certain percentage of uptime(the time their server stays active and running). They achieve this by having a high availability percentage(in the ranges of 99.9%). Even they are measured using metrices like SLA, SLO and SLI. Here is a blog explaining the basics of cloud native and SREs in detail.

Resiliency in cloud look something like this:

Here, when a request is started by the user, there is a load balancer which distributes the request to several back-end servers, which try to fulfill the request. If one of the system goes down, others can help complete the request, thus making it a resilient system.

But construction and rats aren't the problem in cloud computing, then why do we need Resiliency??

Because downtimes(opposite of uptime) are the biggest evil in production. There have been multiple instances in the past when big MNCs have lost millions in revenue due to poorly managed systems. With the advent of cloud-native technologies and microservice architecture, although automation and ease of production has been reaching its peak, the danger of failure keeps on increasing. Recently, on the October 4, 2021, Facebook had a server outage of almost 12 hours which costed them $6 bn!! Here is an article by the engineering team explaining that.

Due to this, in 2010 Netflix developed a practice called Chaos Engineering, when it ran into a similar problem, to make systems more fault-tolerant.
Chaos Engineering is a disciplined approach to identifying failures before they become outages. By proactively testing how a system responds under stress, you can identify and fix failures before they end up in the news.
This was adopted by the Cloud Native Computing Foundation(CNCF) later to develop different projects like LitmusChaos, ChaosMesh etc. Simply speaking, this is the practice of "breaking things on purpose" just to make systems more resilient to failures.

How Kubernetes achieves it?

Just to give a small intro to Kubernetes(k8s), it is a tool which helps you deploy your applications, scale and manage them as per your wish. To learn in detail, how k8s is resilient in itself, we need to dive deep into the various components constituting it.

Here is how Kubernetes looks from the inside:

I know this is a lot to digest to be thrown at the face suddenly, so, let's just try to understand it in a layman's perspective.

Imagine a lizard. We know that when a lizard's tail gets cut off, it doesn't die but the tail grows back. But if you take its heart out, it dies instantly(so does every being on this planet).
K8s has a similar structure. There is a control plane and multiple worker nodes. Control plane is the most important component as it contains the heart, the API server(along with a few other things). Any kind of applications, if deployed, are run on the worker nodes. This command is relayed to the different components by the API server only. So, all the different components watch commands of the API server. If due to some error, one of the worker node goes down, the nodes watching the API server sees that the application which needs to run isn't running and thus, with some internal mechanism, deploys the application to a different worker node. And by that time, it creates another worker node to replace the destroyed one(lizard analogy!). Thus, the downtimes are at an all time low!

These features make Kubernetes one of the biggest technical innovations in the recent times and an industry revolutionizer with more and more companies adopting the various cloud native technologies and scaling up their production with such container orchestration tools.
As a wise man previously said, "Learning Kubernetes isn't a technical challenge, it's a people's challenge".

I hope if you've reached here till the end of this blog, I've kept you interested enough to learn more about cloud native, containers and Kubernetes.

Here are a few resources to go through and start your journey in this space:
1) A short intro to Cloud vs Cloud Native
2) Learn Docker
3) Start with Kubernetes
4) Most important, join the Kubernetes slack and be a part of an amazing community of people.