DEV Community: P S S Hrithik

🧩 Micro Frontends – The Complete (But Brief) Guide

P S S Hrithik — Tue, 30 Sep 2025 04:17:54 +0000

“Why is our frontend deployment breaking again?”

“Because 5 teams committed to the same monolith... again.” 😩

Sound familiar?

💡 What Are Micro Frontends?

Micro Frontends is an architectural approach where a single frontend app is divided into smaller, semi-independent "micro apps", each owned by different teams and developed, tested, and deployed separately.

Think of it as microservices for the frontend.

🧠 Why Use Micro Frontends?

Imagine if:

Teams could deploy independently
Each feature used the best suited tech stack
Bugs in one area didn’t crash the whole UI

🧭 Types of Micro Frontend Architecture

Micro Frontends can be implemented in different integration strategies:

1. Client-side Composition

Everything comes together in the browser.

Tools: Webpack Module Federation, SystemJS, single-spa

Pros: More flexibility, dynamic loading

Cons: Initial complexity, managing shared dependencies

2. Server-side Composition

Each micro frontend renders on the server, and the final page is assembled there.

Tools: Edge-side includes (ESI), NGINX, SSR frameworks

Pros: Fast time-to-first-byte, SEO-friendly

Cons: Harder to manage dynamic interactivity across parts

3. Build-time Integration

All pieces are built together and deployed as a single app (still independently maintained).

Tools: Module Federation with shared build configs

Pros: Easier setup

Cons: Tight coupling, less runtime flexibility

4. iFrame Integration

Each micro frontend lives inside its own iframe.

Tools: None special, just HTML
Pros: Strong isolation

Cons: Performance, communication overhead

Architectural Constraints & Considerations

Implementing Micro Frontends isn't a free lunch. Here's what you need to keep in mind:

Constraint	Consideration
Isolation	Avoid global CSS, shared DOM access, or clashing dependencies
Communication	Use pub-sub models, events, or shared state managers carefully
Routing	Who owns the router? Use route-based composition or a central router manager
Deployment Strategy	Independent deployments require versioning and compatibility planning
Design Consistency	Shared design system / tokens needed for a unified look
Shared Dependencies	Use singleton modules in Module Federation to avoid bundle duplication

⚠️ But What About The Trade-Offs?

Challenge	What It Means for You
Complex setup	Initial scaffolding can be tricky
Performance overhead	Improper setup leads to larger bundles
Shared state is harder	Need robust communication patterns
Design consistency	Centralized design tokens/components
Onboarding new devs	Requires understanding the architecture

🧰 Common Tools in the Wild

Purpose	Tools / Frameworks
Composition Layer	`single-spa`, `Module Federation`, `SystemJS`
Shared UI Components	`Bit`, `Storybook`, design tokens
Routing	`single-spa`, custom orchestrators
Deployment	CI/CD pipelines per micro app
Monitoring	`Sentry`, `LogRocket`, `Datadog`

🎯 When Should You Use Micro Frontends?

✅ You have multiple teams working on different parts of the UI

✅ You want independent deployments
✅ You’re modernizing a legacy frontend monolith

✅ You want to gradually migrate from one tech stack to another

✅ You’re building a modular platform or dashboard

❌ When Not to Use It?

Your app is small or managed by a single team
You don't need frequent independent releases
You can’t justify the complexity overhead

✨ Final Thoughts

Micro Frontends bring a scalable, team-friendly solution to frontend complexity.

They’re not always the answer — but when used well, they’re a powerful architectural pattern for large apps and fast-moving teams.

Break the monolith. Embrace autonomy. Stay consistent.

Co-authored with: @kenzo_tenma

Level Up Your Projects: Lesser-Known Web APIs Every Developer Should Use

P S S Hrithik — Fri, 27 Sep 2024 11:59:43 +0000

In the ever-evolving world of web development, many APIs have become familiar that we use without much thought. Yet, there are several lesser-known APIs that can greatly enhance your projects and streamline your coding process. In this blog, we’ll delve into some of these hidden gems, featuring code examples.

1. Intersection Observer API

The Intersection Observer API lets you watch when a target element comes into or goes out of view in the browser. This means you can easily know when elements are visible on the screen, allowing you to trigger actions based on whether they’re seen by the user.

Here’s a simple example

// Define the callback function
const callback = (entries, observer) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      console.log('Element is visible in viewport!');
      // Perform actions like loading content or triggering animations
    } else {
      console.log('Element is out of view.');
    }
  });
};

// Create an observer instance
const observer = new IntersectionObserver(callback);

// Target the element to observe
const target = document.querySelector('#targetElement');
observer.observe(target);

Code Explanation

Callback Function: This function is called whenever the intersection state of the target changes. It receives an array of entries, each representing a target element being observed.

Observer Instance: An instance of IntersectionObserver is created using the callback function.

Observing Elements: You call observe() on the observer instance, passing in the target element.

Why Use Intersection Observer?

Performance Optimization: Instead of constantly checking the position of elements during scroll events, the Intersection Observer provides a more efficient way to track visibility.

Enhanced User Experience: You can create smooth animations, lazy load images, and implement infinite scrolling, all based on when elements come into view.

2. Resize Observer API

Maybe you’re working on a responsive design and need to adjust layouts dynamically. Enter Resize Observer API!, The Resize Observer API allows you to watch for changes in the dimensions of an element. This is super useful for creating responsive designs that adapt to various screen sizes or dynamic content changes.

How Does Resize Observer Work?

The Resize Observer lets you create a new observer that will call a callback function whenever an observed element changes size. Let’s take a look at how to use it!

Here’s a simple example

// Select the element you want to observe
const box = document.querySelector('.box');

// Create a new ResizeObserver instance
const observer = new ResizeObserver(entries => {
  for (let entry of entries) {
    console.log('Element:', entry.target);
    console.log('New width:', entry.contentRect.width);
    console.log('New height:', entry.contentRect.height);
  }
});
// Start observing the element
observer.observe(box);

If you ever need to stop monitoring the box, you can call unobserve() on the observer instance. This is useful for performance reasons or when the element is no longer relevant.

Practical Use Cases :

Responsive Layouts
Dynamic Content Management

For a comprehensive resource, you might want to check out these fantastic YouTube tutorials Intersection Observer , Resize Observer, which I found very useful for understanding the concepts.

Thank you! Happy Coding!!

Mastering End-to-End Testing: Which Tool Cypress or Playwright Should You Choose?

P S S Hrithik — Sun, 01 Sep 2024 13:57:47 +0000

In the fast-paced world of web development, making sure your apps run flawlessly and meet user expectations is essential, That's where end-
to-end (E2E) testing tools come in. Two big names in this arena are Cypress and Playwright. Both are powerful tools for testing modern web apps, but they each have their own unique features and differences. In this blog post, we’ll break down what makes Cypress and Playwright stand out, and help you figure out which one might be the best fit for your project. Ready to dive in? Let’s get started😎!

Key Features Comparison

1. Browser Support

Cypress: Traditionally, Cypress has been known for its robust support for Chromium-based browsers like Google Chrome and Microsoft Edge. If you're focusing on these environments, Cypress provides a reliable and optimized testing experience. However, it's worth noting that while recent versions have introduced experimental support for WebKit, this is not as mature or stable as its support for Chromium-based browsers.

Playwright: Here, Playwright shines with its broad support across different browsers. It offers first-class compatibility with Chromium, Firefox, and WebKit (which powers Safari). This extensive browser support is particularly advantageous if you need to ensure your application performs well across various platforms.

Which browsers are most crucial for your testing 🤔?
If cross-browser compatibility is a key requirement for your project, Playwright might be the more suitable choice.

2. Test Execution Speed

Cypress: Known for its impressive test execution speed, Cypress benefits from an architecture that runs directly inside the browser. This design minimizes the need for explicit waits, as Cypress incorporates automatic waiting and retries, thus accelerating your testing process.

Playwright: Similarly, Playwright offers rapid test execution and supports parallel testing right out of the box. By allowing multiple browsers or contexts to run simultaneously, Playwright can significantly enhance the speed of your test runs.

3. API and Syntax

Cypress: Cypress provides a user-friendly syntax that simplifies test writing. Its API is well-documented, and the interactive Test Runner offers a visual representation of your application's state at each step of the test. This can be particularly helpful for understanding test behaviors and outcomes.

Playwright: On the other hand, Playwright offers a more extensive API that grants greater flexibility. While its syntax might be more complex, it allows for detailed control over browser interactions. This can be advantageous for intricate testing scenarios that require fine-tuned automation.

How comfortable are you with complex APIs and syntaxes?
If you prefer simplicity and ease of use, Cypress might be your go-to. For those who need more control and customization, Playwright could be the better option.

4. Network Interception and Mocking

Cypress: Cypress offers robust network stubbing and mocking capabilities. This feature allows you to intercept and modify network requests and responses, which is essential for testing edge cases and interacting with third-party services.

Playwright: Playwright also supports network interception and mocking, with a flexible API that integrates well with its broader automation features. This means you can handle complex network scenarios effectively.

Do you need to handle complex network interactions in your tests? Both tools provide powerful network handling features, but the best choice might depend on your specific needs for mocking and intercepting requests.

5. Debugging and Error Handling

Cypress: Cypress excels in debugging with features like time-travel debugging, detailed error messages, and snapshots of your application's state during test execution. The interactive Test Runner provides an intuitive debugging experience that can simplify the troubleshooting process.

Playwright: Playwright offers detailed logs and snapshots for debugging. Although its debugging experience might not be as interactive as Cypress's, it remains powerful and effective, especially when combined with its extensive API.

How important is an interactive debugging experience for you?
If you value detailed, interactive debugging tools, Cypress might be the better choice. For a more traditional approach with strong logging, Playwright is worth considering.

Deciding between Cypress and Playwright depends on your specific needs and project requirements:

Choose Cypress: If you need a tool with straightforward setup and strong in-browser testing for Chromium-based browsers. It’s ideal for projects that prioritise simplicity and ease of use.

Choose Playwright: If you require extensive cross-browser testing, support for multiple browser engines, or advanced automation features. Its flexibility and comprehensive API make it well-suited for projects with diverse testing needs.

What factors are most important for your testing strategy?
Share your thoughts and experiences! Whether you lean towards Cypress or Playwright.

React and WebAssembly

P S S Hrithik — Sun, 11 Aug 2024 13:21:55 +0000

React has totally changed the game for building websites. It's like magic for crafting those slick, interactive pages we all love. Now, imagine combining that with WebAssembly – this super-fast, low-level language that's like rocket fuel for your browser. Together, they're an unstoppable duo, cranking out web apps that are super-quick and packed with features.

Understanding WebAssembly

WebAssembly isn't actually a language you code in. Think of it more like a super-fast translator. It takes code written in languages like C, C++, Rust, or Go and turns it into a format that computers understand really quickly. This means those speedy languages can now run directly in your browser, almost as fast as if they were native apps.

Integrating WebAssembly with React

To integrate WebAssembly with React, follow these steps:

Compile code to WebAssembly - Use a compiler to convert your code (written in C, C++, Rust, or Go) into a WebAssembly module (.wasm file).
Load the WebAssembly module - Use JavaScript to load the .wasm file into the browser.
Create a JavaScript interface - Expose functions from the WebAssembly module to JavaScript using the WebAssembly API.
Integrate with React - Use the exposed functions within your React components to interact with the WebAssembly module.

Code Example

Let's create a basic example where we use WebAssembly to generate prime numbers within a specified range and display them in a React component.

C code (prime_numbers.c):

#include <emscripten.h>
#include <stdbool.h>

bool is_prime(int num) {
  if (num <= 1) return false;
  for (int i = 2; i * i <= num; i++) {
    if (num % i == 0) return false;
  }
  return true; &nbsp; 

}

int* generate_primes(int lower, int upper) {
  int count = 0;
  // Pre-allocate an array to store primes (might need adjustment based on range)
  int primes[upper - lower + 1];
  for (int i = lower; i <= upper; i++) {
    if (is_prime(i)) {
      primes[count] = i;
      count++;
    }
  }
  // Reallocate the array to the actual number of primes (optional for memory efficiency)
  int* result = (int*)malloc(count * sizeof(int));
  memcpy(result, primes, count * sizeof(int));
  return result;
}

EMSCRIPTEN_BINDINGS(my_module) {
  emscripten_function("is_prime", "is_prime", allow_raw_pointers());
  emscripten_function("generate_primes", "generate_primes", allow_raw_pointers());
}

Compile the C code to WebAssembly:

Bash

emcc prime_numbers.c -o prime_numbers.js

React component:

mport React, { useState, useEffect } from 'react';

function PrimeNumberGenerator() {
  const [lowerBound, setLowerBound] = useState(2);
  const [upperBound, setUpperBound] = useState(10);
  const [primes, setPrimes] = useState([]);

  useEffect(() => {
    const script = document.createElement('script');
    script.src = 'prime_numbers.js';
    document.body.appendChild(script);
  }, []);

  const generatePrimes = () => {
    const wasmPrimes = Module._generate_primes(lowerBound, upperBound);
    const primeList = new Int32Array(wasmPrimes);
    setPrimes(Array.from(primeList)); // Convert to regular array for easier use
    Module._free(wasmPrimes); // Free the allocated memory in Wasm
  };

  return (
    <div>
      <input
        type="number"
        value={lowerBound}
        onChange={(e) => setLowerBound(parseInt(e.target.value))}
      />
      <input
        type="number"
        value={upperBound}
        onChange={(e) => setUpperBound(parseInt(e.target.value))}
      />
      <button onClick={generatePrimes}>Generate Primes</button>
      <ul>
        {primes.map((prime) => (
          <li key={prime}>{prime}</li>
        ))}
      </ul>
    </div>
  );
}

export default PrimeNumberGenerator;

In this example:

We define a C function to calculate prime numbers within a given range.
We compile this C code into a WebAssembly module using Emscripten.
In our React component, we load the generated WebAssembly module.
We create a JavaScript function to call the WebAssembly function for prime number generation.
We update the component's state with the calculated prime numbers and display them in a list.

Key benefits of WebAssembly:

Performance: WebAssembly (Wasm) excels in executing code at significantly higher speeds compared to JavaScript. This makes it an optimal choice for applications demanding substantial computational resources.
Portability: Wasm modules can run on different platforms and browsers without modification.
Leverage existing codebases: Reuse existing C, C++, or Rust libraries in web applications.
Enhanced user experience: Provide smoother animations, faster load times, and better responsiveness.
Access to hardware features: WebAssembly can potentially access hardware features like GPU acceleration, opening up new possibilities.
Security: Wasm has a sandboxed environment, ensuring that code runs safely within the browser.

Additional Considerations:

Performance profiling: Identify performance bottlenecks and determine if WebAssembly is the right solution.
Development complexity: WebAssembly can introduce additional complexity to the development process.
Browser compatibility: Ensure compatibility across different browsers.

Conclusion:
React and WebAssembly form a powerful combination for building high-performance web applications. By understanding their strengths and how to integrate them effectively, developers can create exceptional user experiences.