Insightful stories that revolve around technology, culture, and design

JavaScript provides several ways of iterating over a collection, from simple for loops to map() and filter(). Iterators and generators bring the concept of iteration directly into the core language and provide a mechanism for customizing the behaviour of ‘for...of loops’. Iterators and generators usually come as a secondary thought when writing code, but if you can take a few minutes to think about how to use them to simplify your code, they'll save you from a lot of debugging and complexities.

Iterators

When we have an array, we typically use the ‘for loop’ to iterate over its element.

• The ‘for loop’ uses the variable 'i' to track the index of the ranks array
• The value of 'i' increments each time the loop executes as long as the value of 'i' is less than the number of elements in the ranks array. But its complexity grows when you nest a loop inside another loop. 

ES6 introduced a new loop construct called ‘for...of’ to eliminate the standard loop’s complexity

The ‘for...of the loop’ can create a loop over any iterable object, not just an array.

Iterable values in JavaScript

The following values are iterable –

• Arrays
• Strings
• Maps
• Sets

Plain objects are not iterable and hence the 'for...of' uses the Symbol.iterator.

Symbol.iterator

The Symbol.iterator is a special-purpose symbol made especially for accessing an object's internal iterator. So, you could use it to retrieve a function that iterates over an array object, like so –

• An iterator is an object that can access one item at a time from a collection while keeping track of its current position
• It just requires that you have a method called next() to move to the next item to be a valid iterator
• The result of next() is always an object with two properties –

1. Value: The value in the iteration sequence
2. Done:  true | false

Generators 

Generator functions once called, returns the Generator object, which holds the entire Generator iterable and can be iterated using next() method. Every next() call on the generator executes every line of code until it encounters the next yield and suspends its execution temporarily.

Generators are a special type of function in JavaScript that can pause and resume state. A Generator function returns an iterator, which can be used to stop the function in the middle, do something, and then resume it whenever. 

• This generator object needs to be assigned to a variable to keep track of the subsequent next() methods called on itself.
• If the generator is not assigned to a variable then it will always yield only till the first yield expression on every next().
• A generator function is a function marked with the * and has at least one yield-statement in it.
• Syntactically they are identified with a *, either function* X or function *X, — both mean the same thing

Fun Fact – async/await can be based on generators

Generator functions/yield and Async functions/await can both be used to write asynchronous code that 'waits', which means code that looks as if it was synchronous, even though it is asynchronous. ... An async function can be decomposed into a generator and promise implementation which is good to know stuff.

Generator functions are written using the function* syntax –

• ‘function*’ is a new 'keyword' for generator functions
• yield is an operator with which a generator can pause itself

Additionally, generators can also receive input and send output via yield. In short, a generator appears to be a function but it behaves like an iterator.

A generator is a function that returns an object on which you can call next(). Every invocation of next() will return an object of shape —

‍

{ 
    value: value,
    done: true  if the function code has finished, otherwise  false
}

• The value property will contain the value
• The done property is either true or false
• When the done becomes true, the generator stops and won’t generate any more values

Here are some other common definitions of generators 

• Generators are a special class of functions that simplify the task of writing iterators
• A generator is a function that produces a sequence of results instead of a single value, i.e you generate ​a series of values
• The value property will contain the value. The done property is either true or false. When the done becomes true, the generator stops and won’t generate any more values. The yield is a magical keyword that can do more things other than simply return a value and next() can do more things aside from retrieving the value.

• A passing argument to next() - The argument passed to next() will be received by yield –

Output

Passing a function to yield

Apart from returning values, the yield can also call a function –

Output

Delegating to another generator or iterable using yield* expression

Output

Let’s see an example of fetching a single value from an API

As a Title –

Output

• In this example; to fetch data from API, we have to install node-fetch using the command –
  'npm install node-fetch'

• We then pass a generator to a function as a parameter. Let's call the function getTitle()

• Now, in the function, we have to go through some steps to execute the generator

• Initially, we will call the generator method. It returns an iterator(object)  which is caught in a variable 'iterator'

• Now execute the iterator using 'next()' method

• When the next method is called, the generator starts executing from this point. At line 4 the 'URL' is fetched

• Fetch returns an object which is captured into variable 'iteration'

• The object has 2 fields, viz. 'value' and 'done'

• Here value is a promise and done is a boolean set to false

• Iteration has a promise. Here we used our first yield

• In our case, the getTitle() function has to resolve the promise. Since the yield doesn’t know how to resolve the promise.  So for resolving that promise we caught iteration.value into a variable 'promise'

• Now we resolve the promise say into variable 'x'

• We send the resolved 'x' to the iterator's next method. This x is a response which we collect into a variable 'response'. (line 5)

• Now we have to extract the post from the response 

• The response object now again has a promise which is to be resolved by our function. So we extract the object into variable 'anotherIterator' and the value of that object viz. promise into 'anotherPromise'

• Now we resolve that promise in 'y' and pass it to the generator through the next() method

• Here we used the second yield. So now we have resolved the response.json() and caught it into variable 'post'. (line 6)

• Finally, we get our title through the object 'post'.Now we are going to extract our title from 'post.title'. Check the console for the title

Advantages of Generators

Lazy Evaluation 

This is an evaluation model that delays the evaluation of an expression until its value is needed. That is, if the value is not needed, it will not exist. It is calculated on demand.

Memory Efficient

A direct outcome of Lazy Evaluation is that generators are memory efficient.

The only values generated are those that are needed. With normal functions, all the values must be pre-generated and kept around case they need to be used later.

Conclusion

We have learned the following things about iterators and generators –

• Iterator functions are a great and efficient way to do a lot of things in JavaScript. There are many other possible ways of using a generator function
• Keeping iteration logic with the object it belongs to, is a good practice and which is the focus of ES6 features
• The ability of a function to exchange data with the calling code during the execution is unique. And, surely, they are great for making iterable objects
• As can be evidenced by the examples, generators are a really powerful tool that lets you have cleaner code - especially when it comes to any kind of asynchronous behaviour

As computers are getting more powerful it is getting easier to achieve complex animations without compromising the fluidity and user experience. There are various JavaScript animation libraries available and most of them are pretty good. We at QED42 tried some of them and for the most part, we used GSAP which we think is kind of becoming an industry standard. GSAP is highly configurable and is just the right tool if you want to have scroll-based animations.

Smooth background change on scroll –

One thing that is eye-catching and easy to achieve, is smoothly changing background colour while scrolling. To implement this, we will change the wrapper component’s background colour as its child components move in and out of the viewport.

Source:qed42-js.netlify.app

Step 1: Create a context that will wrap our components and provide the necessary functionality

Step 2:We will then import child components (named First, Second and Third), GSAP, and AnimationContext in our main app component. We are monitoring “currentBg” in the “useEffect” hook and whenever its value changes, the GSAP function gets executed. GSAP will change the background in 1 second which gives the fade-in effect.

Step 3: To implement scroll-based triggers for the second and third components we will use GSAP.

The second component returns the following JSX, having a reference to wrapper element and text.

Next, we will create a GSAP timeline and use a scroll trigger to target an element, and set the start and endpoint for animation.

ScrollTrigger has onEnter and onLeaveBack function which gets triggered when the trigger element passes through the scroll markers. That is where we change our background using context.

Note: The same effect can be achieved using gsap.to(), gsap.from() and other methods instead of gsap.timeline().

The code for the above demo can be found at the following Github link.

What we learned from our hands-on experience is that animations should enforce, enhance the user behaviour and experience. The animations should not hinder action items in a way that it takes more time for users to interact with them. Therefore the background animation we saw above is very subtle and doesn’t cause any such hindrance.

It's 2 AM on a Saturday, and your phone buzzes. The app is down. After three hours of debugging, you finally discover the issue: someone changed `userId` to `authorId` in the backend last week. Your frontend was still looking for `userId`. Everything compiled without errors, and TypeScript showed green checkmarks all around. Does this sound familiar? 

This blog aims to ensure that this kind of problem never happens again by establishing true end-to-end type safety.

What you'll learn

By the end of this guide, you'll be able to:

• Understand why manual types can lead to significant issues
• Set up a GraphQL API that automatically generates types
• Link your React frontend seamlessly with your backend, avoiding type mismatches
• Identify breaking changes before they affect your users
• Ship code with confidence (and enjoy a good night's sleep)

The problem: your types live on two islands

Imagine your backend and frontend as two separate islands, each with its own TypeScript ecosystem. Both define a type, and both feel secure in their type-safety. However, they're divided by an ocean, with no shared source of truth. A small change on one island can silently break the other.

Both the backend and frontend define their own version of the User type.

They look identical, and everything compiles perfectly.

TypeScript shows all green,  life is good.

The backend team updates the User to store dob instead of age. Everything compiles fine because TypeScript checks each island separately, and the change goes unnoticed. Both sides are “type safe,” yet your data silently drifted apart.

Monday morning, the support inbox lights up: "Why doesn't the app show user ages anymore?" This is the fundamental problem that end-to-end type safety solves. No more islands. No more silent mismatches.

The solution: one Schema to rule them all

So, how do we stop our backend and frontend from becoming disconnected?
Simple, we need to ensure they communicate effectively,  and make them speak the same language. That language is your GraphQL schema,  the single source of truth for your entire app.

The Flow: End-to-End Type Safety

Every type, field, and structure in your application is defined a single time in the schema, which then automatically generates the corresponding types for both the backend and frontend. This eliminates duplicate definitions and the uncertainty of whether they align.

Now the mismatch is caught instantly during compile time, not at 2 AM on Saturday. Your schema drives your code, your code drives your app,  and your types stay in sync effortlessly.

From Schema to Codegen

Now that we understand how the GraphQL schema acts as the single source of truth, the next question is — how do we actually achieve end-to-end type safety?

The answer is GraphQL Code Generator (or Codegen for short).

Codegen is a tool that reads your schema and queries, then automatically generates TypeScript types and React hooks for you.
No more writing types by hand or worrying if your frontend and backend have drifted apart — Codegen ensures every part of your stack speaks the same language.

Let’s add this to your project

Now that we know what Codegen does, let’s bring it into your workflow.

What you’ll do

1. Configure Codegen to point to your GraphQL schema
2. Write your queries in .graphql files (or inline with gql)
3. Run npm run codegen → get typed hooks instantly
4. Get instant results:
   
   1. Queries match the schema → fully typed hooks generated
   2. Queries don't match → compile-time error before production

Once configured, Codegen runs in two places:

• Backend: Generates resolver types from your schema
• Frontend: Validates queries and generates typed React hooks. Use those hooks in your React components with full autocomplete and type safety

Let's see it step by step in action.

Step 0: Quick Backend Setup (If needed)

Already have a GraphQL server? Skip to Step 1.

Need one fast? Here's a minimal Apollo Server with a `schema.graphql` file:
‍

npm install @apollo/server graphql
npm install --save-dev @graphql-codegen/cli @graphql-codegen/typescript @graphql-codegen/typescript-resolvers

‍

Note: startStandaloneServer is designed for prototyping and simple use cases — for production, integrate Apollo Server with Express

Create a `schema.graphql` file with:
‍

type Todo {
  id: ID!
  text: String!
  done: Boolean!
}

type Query {
  todos: [Todo!]!
}

‍

Create `server.ts`:
‍

import { ApolloServer } from '@apollo/server';
import { startStandaloneServer } from '@apollo/server/standalone';
import fs from 'fs';
import path from 'path';

const typeDefs = fs.readFileSync(path.join(__dirname, 'schema.graphql'), 'utf-8');

const todos = [
  { id: '1', text: 'Learn GraphQL', done: false },
  { id: '2', text: 'Build a Todo app', done: true },
];

const resolvers = {
  Query: {
    todos: () => todos,
  },
};

const server = new ApolloServer({ typeDefs, resolvers });
const { url } = await startStandaloneServer(server, { listen: { port: 4000 } });

console.log(`🚀 Server ready at ${url}`);

‍

Run the backend server:
‍

npx tsx server.ts

‍

Backend Types? Generate Them

Create `backend/codegen.ts`:
‍

import type { CodegenConfig } from '@graphql-codegen/cli';

const config: CodegenConfig = {
  schema: './schema.graphql',
  generates: {
    './src/generated/graphql.ts': {
      plugins: ['typescript', 'typescript-resolvers'],
    },
  },
};

export default config;

‍

Run backend codegen on schema changes:
‍

npm run codegen

Step 1: Frontend Setup with Codegen and Apollo Client

Now lets move forward, In frontend project run:
‍

npm install --save-dev @graphql-codegen/cli \
  @graphql-codegen/typescript \
  @graphql-codegen/typescript-operations \
  @graphql-codegen/typescript-react-apollo

npm install @apollo/client graphql

‍

Create `codegen.ts`:
‍

import type { CodegenConfig } from '@graphql-codegen/cli';

const config: CodegenConfig = {
  schema: 'http://localhost:4000/graphql',
  documents: ['src/**/*.{ts,tsx,graphql}'],
  generates: {
    './src/generated/graphql.ts': {
      plugins: [
        'typescript',
        'typescript-operations',
        'typescript-react-apollo',
      ],
      config: { withHooks: true },
    },
  },
};

export default config;

‍

Add these scripts in `package.json`:
‍

"scripts": {
  "codegen": "graphql-codegen",
  "codegen:watch": "graphql-codegen --watch"
}

‍

Note: Watch mode requires @parcel/watcher as an additional dev dependency — run npm install --save-dev @parcel/watcher once.‍

Step 2: Write your query

Create a query file, e.g. `src/queries/getTodos.graphql`:
‍

query GetTodos {
  todos {
    id
    text
    done
  }
}

Step 3: Generate types & hooks

Run:
‍

npm run codegen

‍

Generated hooks like `useGetTodosQuery` will be created in `./src/generated/graphql.ts`.

Step 4: Use hook in React
‍

import { useGetTodosQuery } from '../generated/graphql';

export function TodoList() {
  const { data, loading, error } = useGetTodosQuery();

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

  return (
    <ul>
      {data?.todos.map(todo => (
        <li key={todo.id}>
          <input type="checkbox" checked={todo.done} readOnly />
          {todo.text}
        </li>
      ))}
    </ul>
  );
}

‍

At This Point

- Backend and frontend share a single source of truth schema.

- Backend resolvers use type-safe typings.

- Frontend queries and hooks are fully typed.

- Any schema changes propagate type errors during development, preventing runtime bugs.

Wrapping it up: One Schema, One Language

You’ve just seen how a single GraphQL schema can power your entire app, backend to frontend, while maintaining type safety throughout the process.

Let’s recap what we built:

GraphQL Schema → Codegen → TypeScript Types + React Hooks → React Components

Each layer communicates in the same language, automatically—fewer duplicated types, mismatched field names, and runtime 'undefined' errors."

What you gained

• Single Source of Truth: Your GraphQL schema defines the contract once.
• Minimal Drift: Backend and frontend types stay aligned as long as you re-run Codegen after schema changes.
• Faster Dev Flow: Autocomplete, type hints, and compile-time safety everywhere.

Final thought

End-to-end type safety isn’t just about preventing bugs—it’s about building trust between every part of your stack. When your schema defines the truth, your entire stack aligns.

‍

‍

React Native is undergoing one of its most significant transformations since its launch with the adoption of the New Architecture. Built around Fabric, TurboModules, and the JavaScript Interface (JSI), this shift changes how JavaScript communicates with native platforms.

Earlier versions relied on a bridge that serialised data between threads, which often introduced latency in complex applications. The New Architecture removes that limitation by enabling direct communication between JavaScript and native code, resulting in faster rendering, better responsiveness, and lower memory usage.

For production-scale applications, this is more than a technical upgrade. It improves long-term scalability and stability. Fabric brings React Native closer to modern React concurrency, allowing smoother UI updates during heavy processing, while TurboModules improve startup performance by loading native modules only when required.

As businesses increasingly expect native-level performance from cross-platform frameworks, the New Architecture makes React Native more capable of supporting enterprise-grade mobile experiences.

‍

‍

Hermes engine maturity: why JavaScript performance in React Native has improved dramatically

Performance has historically been one of the most discussed concerns in cross-platform development, and React Native’s adoption of the Hermes JavaScript engine marks a decisive step toward solving it. Hermes is optimised specifically for mobile environments, focusing on faster startup times, lower memory usage, and predictable execution performance. Unlike general-purpose JavaScript engines, Hermes precompiles JavaScript into optimised bytecode during build time, reducing runtime processing when the app launches.

This improvement is especially noticeable on mid-range and low-end devices where resource constraints are more visible to users. Faster time-to-interactive metrics and smoother navigation flows directly translate into better user retention and engagement. Beyond performance gains, Hermes also improves debugging and profiling capabilities, giving development teams deeper insight into runtime behaviour. As mobile applications grow more complex, having a JavaScript engine tailored for mobile workloads helps organisations deliver consistent experiences across diverse hardware ecosystems.

React Native and React 18: the shift toward Concurrent Rendering

The alignment between React Native and React 18 introduces a new paradigm in how mobile interfaces handle rendering workloads. Concurrent rendering allows React to prepare UI updates without blocking user interactions, making applications feel significantly more responsive. Instead of freezing the interface during heavy updates, React can prioritise urgent interactions while processing background changes incrementally.

This shift is particularly impactful for applications with dynamic data, such as dashboards, social feeds, and collaborative tools. Users experience smoother scrolling and faster interaction feedback, even when complex state updates occur behind the scenes. For engineering teams, concurrency also encourages better architectural patterns by separating urgent UI updates from non-critical computations. As React Native continues to align closely with the broader React ecosystem, developers benefit from shared innovation across web and mobile platforms, reducing fragmentation and improving long-term maintainability.

Reanimated and the rise of native-level animations in React Native

Modern mobile applications increasingly rely on fluid animations and gesture-driven interactions to deliver premium user experiences. Recent advancements in libraries like React Native Reanimated have significantly changed how animations are executed. By leveraging worklets and running animation logic directly on the UI thread, React Native applications can achieve native-level smoothness without being limited by JavaScript thread performance.

This architectural improvement allows animations to remain responsive even during network requests or heavy computation. Complex transitions, gesture-based navigation, and interactive components now behave consistently across platforms. For product teams, this means design ambitions no longer need to be compromised due to performance constraints. The ability to deliver high-fidelity animations within a cross-platform framework strengthens React Native’s position in industries where user experience directly influences business outcomes.

The evolution of developer experience in React Native

Recent React Native releases have focused heavily on improving developer experience, recognising that productivity directly impacts product delivery timelines. Enhancements to the Metro bundler, faster refresh cycles, and improved error reporting have reduced iteration time during development. Developers now spend less time waiting for builds and more time refining features, which becomes increasingly valuable in large-scale projects.

Tooling modernisation has also improved compatibility with current Android and iOS ecosystems, reducing friction caused by outdated dependencies. Better TypeScript integration has encouraged safer codebases and easier refactoring, particularly in enterprise environments where multiple teams collaborate on shared applications. These improvements collectively signal a maturation phase for React Native, where stability and reliability are prioritised alongside innovation.

Expo’s transformation and its impact on React Native development

Expo has evolved from a beginner-friendly abstraction layer into a production-ready platform capable of supporting complex applications. With the introduction of modern build systems and deeper native integration capabilities, developers can now access advanced features without abandoning Expo’s streamlined workflow. This shift reduces setup complexity while preserving flexibility for custom native development when required.

For organisations seeking faster onboarding and reduced DevOps overhead, Expo’s ecosystem simplifies environment configuration and deployment pipelines. Continuous integration, over-the-air updates, and simplified asset management allow teams to iterate quickly while maintaining production quality. The growing compatibility between Expo and React Native’s New Architecture further strengthens its role as a viable solution for both startups and enterprises.

Why React Native remains strategically relevant in modern mobile development

As the mobile development landscape expands with alternatives like Flutter and Kotlin Multiplatform, React Native continues to maintain strategic relevance due to its ecosystem maturity and alignment with web technologies. Companies already invested in React benefit from shared knowledge, reusable architectural patterns, and easier cross-team collaboration between web and mobile developers.

The framework’s ongoing modernisation demonstrates a commitment to long-term evolution rather than short-term trends. Improvements in performance, architecture, and tooling show that React Native is adapting to industry demands while preserving developer productivity. For organisations balancing development speed with scalability, React Native remains a practical and forward-looking choice capable of supporting both rapid innovation and sustainable growth.

‍

Content-heavy sites built on Next.js and Strapi often hit the same wall: static pages perform well, but keeping them current without triggering a full rebuild is harder than it should be. 

Building a content-heavy site with Next.js and Strapi, we kept running into the same problem: static pages performed well, but every content update triggered a full rebuild and redeploy. Costly, slow, and frustrating, it didn't scale. 

The challenge wasn't performance. It was keeping static sites current without paying for it every time something changed.

Static site generation 

With Static site generation or SSG, pages are pre-rendered into HTML at build time and served from a Content Delivery Network or CDN. No server processing on each request. That's what makes them fast. It's also what makes updating them a problem.

For mostly static content like blogs, documentation, and marketing pages, this works well. But for sites where content changes frequently, the cracks show quickly. Even a minor edit forces a full site rebuild, which slows down publishing and burns unnecessary compute

Key benefits of SSG:

• Pages are served directly from edge locations, so load times are fast.
• Pre-rendered content is easier for search engines to index, which improves SEO.
• Static files are straightforward to cache and distribute via a CDN. 
• Works best for content that doesn't change often: blogs, documentation, and marketing pages.

Challenges with Traditional SSG:

• Every content change triggers a full site rebuild, even if only one page was touched. 
• For large sites, this means longer build times, slower publishing, and delayed content

This leads to a "problem" where managing frequently changing content with a purely static approach becomes cumbersome and inefficient.

Incremental Static Regeneration (ISR): The evolution of static sites

ISR addresses the core limitation of SSG. Instead of rebuilding the entire site on every change, it updates only the pages that need it, regenerating them in the background.  

How ISR solves the problem:

• Updates only the affected pages on demand rather than triggering a full site rebuild for every content change. 
• Pages regenerate in the background, so users always see the cached version while new content is being built. 
• Works well for sites with frequent content changes without sacrificing static performance.
•  ISR builds on SSG rather than replacing it. The site stays static, but individual pages can refresh when their content changes.

When ISR isn't a fit:

• Requires a server or edge runtime to work. 
• Not supported in purely static exports. 
• Won't run on CDN-only or standard JAMstack environments.

Building your own ISR Workflow

To make this work with Strapi as the content source, we built a five-component pipeline:

• Strapi webhook — Content source that fires on every change. 
• API gateway — Receives and validates webhook events securely. 
• SQS queue — Buffers and stores update events. 
• Cron job — Batches events and triggers builds intelligently. 
• Next.js build system — Performs partial or full regeneration based on what changed.

Step 1: Strapi webhook

The first component in the ISR workflow is the Strapi Webhook. When content changes in Strapi, it automatically sends an HTTP POST request to a predefined endpoint. This is what connects your CMS to the rest of the build pipeline.

How it works:

Strapi provides a straightforward way to configure webhooks directly within its admin interface. As a content editor, when you perform actions such as:

• Creating a new blog post.
• Updating an existing product description.
• Publishing a revised landing page. 
• Deleting an outdated piece of content. 

Strapi detects these events. For each configured event, it automatically sends an HTTP POST request to a predefined URL that you specify. This URL typically points to an external endpoint such as an API Gateway or a serverless function designed to receive and process these notifications.

What the webhook sends:

This POST request carries a payload, a block of structured data (usually JSON) that contains information about the content change that just occurred. This payload can include:

• The type of event (e.g., entry.create, entry.update, entry.delete).
• The model type of the changed content (e.g., blog-post, product).
• The ID of the specific entry that was modified.
• Potentially, a subset of the new or old content data itself.

‍

‍

Its role in the ISR workflow:

The Strapi webhook serves as the initial trigger for the entire regeneration process. Rather than constantly polling Strapi for changes, which is inefficient and resource-heavy, we let Strapi notify our system the moment something is updated. 

This notification carries enough information to identify exactly what changed, which content type was affected, and which entry was modified. 

That specificity is what makes targeted page regeneration possible. Instead of rebuilding the entire site, the system knows precisely which pages need to be refreshed, keeping the Next.js site current with the latest content from Strapi while maintaining the speed benefits of static hosting.

Step 2:API gateway – routing securely

Once the Strapi webhook sends its content change notification, the next component in the pipeline is the API Gateway. It sits between Strapi and the rest of the system, ensuring that only valid and properly formatted requests make it through to the backend for processing.

Key functions of the API gateway in this workflow:

• Security: Acts as a controlled entry point, verifying incoming requests. 
• Structure: Receives raw data from Strapi and transforms it into a consistent payload.
• Forwarding: After validation and transformation, the payload is pushed to the SQS queue. 
• Decoupling: Separates the CMS from backend processing, meaning Strapi doesn't need to know anything about the internal build logic.
• The API Gateway ensures that only valid signals enter the system and pass them to the queue, preventing any direct dependency or overload on the subsequent content processing steps.

Step 3: SQS queue – decoupling logic

After the API Gateway securely receives and validates the Strapi webhook payload, the next step in our ISR workflow involves sending that payload to an AWS Simple Queue Service (SQS) Queue. SQS handles asynchronous communication and is fundamental to building a reliable and scalable content update pipeline.

What is SQS and its Role?

SQS is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. In our context, it performs several vital functions:

1. A eeliable buffer: When a content update comes in from Strapi, SQS temporarily stores it as a message in the queue. This acts as a buffer, smoothing out spikes in demand and ensuring no update gets lost in the process.
2. Decoupling layer between webhook and build system: Instead of the API Gateway directly triggering the build system, it places a message in the SQS queue. This means the two systems operate independently of each other, and a slowdown in one doesn't affect the other.
3. Scalable event store for asynchronous processing: SQS can handle a large number of messages per second, ensuring that content update events are never dropped no matter how frequently your content team makes changes. The API Gateway doesn't have to wait for the build system to finish processing before it can move on. Each side works at its own pace, which keeps the overall pipeline responsive and stable.

The result is a system where every content change is eventually processed without risk of overload or data loss.

Step 4: Cron job – smarter build triggers

After content update events are queued in SQS, the Cron Job is what decides when and how to act on them. Rather than reacting to every single content save and potentially overwhelming the build infrastructure, the Cron Job batches updates and processes them at scheduled intervals.

How the Cron Job Operates:

The Cron Job is a scheduled task that runs at predefined intervals, every 15 minutes by default, though this can be configured based on how frequently content changes. Its primary responsibilities include:

1. Fetches events from SQS:
   
   • At its scheduled time, the Cron Job polls the SQS queue, pulling down any new content update messages that have accumulated since its last run. This allows it to process multiple changes in a single batch, rather than initiating a separate build for each individual edit.
2. Determines what changed:
   
   • Once it retrieves the events from SQS, the Cron Job's logic analyzes the payloads. It "Understands what changed (page, blog, product?)". By inspecting the event data (e.g., the content type, the ID of the changed item), it can ascertain the scope and nature of the content modification. Did an editor update a single blog post? Or was a site-wide navigation element modified? This intelligence is crucial for optimizing the build process.
3. Triggers either a partial or full build based on the scope of change:
   
   • This is where the "smarter" aspect of the Cron Job truly shines. Based on its determination of what changed, it makes an informed decision:
     
     • Partial build: If the change is localized, affecting only a specific page or a set of related pages, the Cron Job triggers a partial build. 
     • Full site rebuild: If the change is global, impacting elements that appear across multiple pages (like a shared header, footer, navigation menu, or site-wide configuration), the Cron Job triggers a full site rebuild.‍

Benefits of this batching approach:

• Avoids "Build spam": By waiting and batching multiple changes, the Cron Job prevents your build system from being constantly hammered by frequent, small edits made by content editors. This leads to a more stable and predictable build environment.
• Resource optimization: Fewer, more comprehensive builds consume fewer overall compute resources and can be more cost-effective than a barrage of tiny, individual builds.
• Controlled flow: It introduces a controlled and rhythmic flow to your content updates, allowing for a more manageable deployment process. It brings "calm and control to the update flow."

In summary, the Cron Job acts as the intelligent orchestrator, ensuring that content changes from Strapi are efficiently and precisely translated into the necessary Next.js site updates, choosing the most optimal build strategy (partial or full) for maximum speed and efficiency.

Step 5: Build system

The final stage in our custom ISR workflow is the Build System, where the actual regeneration of your Next.js site takes place. Guided by the decisions made by the Cron Job, the build system determines whether to perform a partial build or a full regeneration. This choice is fundamental to achieving both speed and consistency.

1. Partial build

A partial build is the preferred and most efficient method when content changes are localized.

What it Rebuilds: A partial build rebuilds only the affected route or page. It doesn't touch the parts of your site that haven't been modified.

When it's Used: This approach is ideal for page-level changes such as:

Updating a blog post: If you edit the content of a specific blog article, only that individual blog post's page needs to be regenerated. Modifying a product page: If a product description or image changes, only that specific product page is rebuilt.

Speed and Cost-Effectiveness: Partial builds are fast and cost-effective. They consume minimal resources because they only process a small portion of your site. For a site with 1500+ pages, a partial build could take approximately 9 seconds. This means your content goes live almost instantly with no downtime for the user.

2. Full build

While partial builds are ideal for localized changes, a full build becomes necessary when the modifications affect global elements or require a complete regeneration of the site.

What it Rebuilds: A full build rebuilds the entire site. Every page, route, and static asset is regenerated from scratch.

When it's Used: This is typically reserved for global updates such as:

Changing global navigation: If your website's main menu or footer content is updated, this impacts every page, requiring a full rebuild to ensure consistency across the entire site. Layout or theme changes: Any fundamental changes to the site's overall layout, CSS, or shared components may also trigger a full build.

Speed and Resource Usage: Full builds are slower and more resource-heavy compared to partial builds. For the same 1500+ page example, a full build could take around 40 seconds. While slower, it's sometimes a necessary step to ensure site-wide consistency.

Once the build logic determines what type of build is needed, it triggers the actual build process.

Here's what happens during the final deployment phase: The site is built using the updated content. The output is pushed into the serve directory or the target static host folder. This directory is what your CDN or server uses to serve the site. Once deployed, the updated content becomes live without affecting other parts of the site. In partial builds, only the specific page or route is updated, meaning no downtime or full-site redeploy. This ensures fast updates, high availability, and a smooth user experience. This setup works smoothly without much manual effort. It's reliable, efficient, and easy to maintain. Ultimately, we've enabled a workflow that makes content changes fast, safe, and scalable without relying on full redeployments every time.

Conclusion

The problem we started with was straightforward: static sites are fast but updating them shouldn't require rebuilding everything from scratch every time a content editor makes a change. The five-component pipeline we built with Next.js and Strapi webhooks solves exactly that. Changes are captured the moment they happen, queued reliably, and processed in batches. The build system handles the rest, whether that means regenerating one page in 9 seconds or the entire site in 40.

The result is a workflow that gives content teams the freedom to publish without waiting, and gives developers a system that doesn't buckle under the weight of frequent updates. Static performance stays intact. Content stays current. And the pipeline runs without much manual effort once it's in place.

‍

‍

Ever clicked a button in a web app, and the UI just froze? Maybe a timer stopped, animations stuttered, or clickable elements stopped responding. This happens because JavaScript is single-threaded, meaning it can only do one thing at a time. 

When a heavy computation runs on the main thread, it blocks the UI, creating a poor user experience.

In this blog, we’ll explore Web Workers, a simple and effective way to offload heavy computations to a background thread in a React app, keeping your UI smooth and responsive.

Understanding the problem: single-threaded JavaScript

JavaScript runs on a single thread that handles both:

• UI rendering
• JavaScript execution
  

This means if you run a heavy task, everything else stops until it finishes. Here’s a classic example:
‍

// Blocks UI for several seconds
    function fibonacci(n) {
      if (n <= 1) return n;
      return fibonacci(n - 1) + fibonacci(n - 2);
    }
    const result = fibonacci(44);
    console.log(result)

‍

If this runs on the main thread, timers, animations, and clicks stop responding.

Introducing web workers

Web Workers allow us to run JavaScript code in a separate background thread. This way:

• Heavy tasks don’t freeze the UI
• You can continue interacting with the page
• Communication is done via postMessage() and onmessage()
  

Note: Workers cannot access the DOM directly; they are only for computations.

Web worker syntax

Worker File (public/worker.js):
‍

self.onmessage = function (e) {

    function fibonacci(n) {
      if (n <= 1) return n;
      return fibonacci(n - 1) + fibonacci(n - 2);
    }

    const result = fibonacci(e.data);
    self.postMessage(result);
};

‍

Main Thread (React Component):
‍

  const workerRef = useRef(null);

  useEffect(() => {  
    workerRef.current = new Worker("/worker.js"); 

    workerRef.current.onmessage = (e) => { 
      alert('worker finished! Result : ',e.data);
    };

    return () => {
      workerRef.current.terminate(); 
    };
  }, []);

  const runWorkerTask = () => {
    workerRef.current.postMessage(44); 
  };

React demo: without vs with web worker

Setting up a Next.js Project with Web Workers

1. Create Next.js App

2. Project Folder Structure

Here’s a minimal structure we’ll use:

Without worker (UI freezes)

Create WithoutWorker Component File (app/WithoutWorker.js)
‍

'use client';
import { useEffect, useState } from 'react';

function fibonacci(n) {
  if (n <= 1) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

export default function WithoutWorker() {
  const [timer, setTimer] = useState(0);
  const [color, setColor] = useState('lightblue');
  const [size, setSize] = useState(100);

  useEffect(() => {
    const interval = setInterval(() => setTimer((t) => t + 1), 1000);
    return () => clearInterval(interval);
  }, []);

  const handleHeavyTask = async () => {
    console.log('handleHeavyTask started...');
    const result = fibonacci(44); // Heavy enough to lag most browsers
    console.log('handleHeavyTask ended... : ', result);
  };

  const animateBox = () => {
    // Try clicking this during a heavy task, no response
    setColor((prev) => (prev === 'lightblue' ? 'lightcoral': 'lightblue'));
    setSize((prev) => (prev === 100 ? 550 : 100));
  };

  return (
    <div>
      <h2>Without Web Worker</h2>
      <p>Timer: {timer}</p>
      <button
        onClick={handleHeavyTask}
        className="text-white bg-blue-700 hover:bg-blue-800 focus:ring-4 focus:ring-blue-300 font-medium rounded-lg text-sm px-5 py-2.5 me-2 mb-2 dark:bg-blue-600 dark:hover:bg-blue-700 focus:outline-none dark:focus:ring-blue-800"
      >
        Run Heavy Task
      </button>
      <div
        onClick={animateBox}
        style={{
          marginTop: '20px',
          width: `${size}px`,
          height: `${size}px`,
          backgroundColor: colour,
          cursor: 'pointer',
          transition: 'all 0.3s ease',
        }}
      >
        Click Me
      </div>
    </div>
  );
}

‍

Observation: Click the box while running the heavy task , nothing happens. The timer also freezes.

With worker (UI smooth)

Create Worker File (public/worker.js)
‍

self.onmessage = function (e) {

    function fibonacci(n) {
      if (n <= 1) return n;
      return fibonacci(n - 1) + fibonacci(n - 2);
    }

    const result = fibonacci(44);
    
    self.postMessage(result);
};

‍

Create WithWorker Component File (app/WithWorker.js)
‍

"use client"
import { useEffect, useRef, useState } from "react";

export default function WithWorker() {
  const [timer, setTimer] = useState(0);
  const [color, setColor] = useState("lightgreen");
  const [size, setSize] = useState(100);
  const workerRef = useRef(null);

  useEffect(() => {
    const interval = setInterval(() => setTimer(t => t + 1), 1000);
    return () => clearInterval(interval);
  }, []);

  useEffect(() => {  // Create the worker on mount
    workerRef.current = new Worker("/worker.js"); // Creates a new background thread by loading our worker script.
    workerRef.current.onmessage = (e) => { // Listens for the result from the worker.
      console.log('handleHeavyTask ended... : ',e.data)
    };
    return () => {
      workerRef.current.terminate(); // Cleans up the worker on component unmount.
    };
  }, []);

  const runWorkerTask = () => {
    console.log('handleHeavyTask started...')  
    workerRef.current.postMessage(44); // Sends a message to the worker to begin processing.
  };

  const animateBox = () => {  // This should stay responsive even during heavy task
    setColor((prev) => (prev === "lightgreen" ? "orange" : "lightgreen"));
    setSize((prev) => (prev === 100 ? 550 : 100));
  };

  return (
    <div>
      <h2>With Web Worker</h2>
      <p>Timer: {timer}</p>
      <button 
        onClick={runWorkerTask}
        className="text-white bg-blue-700 hover:bg-blue-800 focus:ring-4 focus:ring-blue-300 font-medium rounded-lg text-sm px-5 py-2.5 me-2 mb-2 dark:bg-blue-600 dark:hover:bg-blue-700 focus:outline-none dark:focus:ring-blue-800"
      >Run Heavy Task</button>
      <div
        onClick={animateBox}
        style={{
          marginTop: "20px",
          width: `${size}px`,
          height: `${size}px`,
          backgroundColor: colour,
          cursor: "pointer",
          transition: "all 0.3s ease"
        }}
      >
        Click Me
      </div>
    </div>
  );
}

‍

Observation: Click the box while the worker runs, the timer keeps going, and the box responds instantly! 

Error handling 

Handle Worker Errors in React

You can attach an onerror listener when creating the worker:
‍

  useEffect(() => {  // Create the worker on mount
    workerRef.current = new Worker("/worker.js"); // Creates a new background thread by loading our worker script.
    workerRef.current.onmessage = (e) => { // Listens for the result from the worker.
      console.log('handleHeavyTask ended... : ',e.data)
    };
    workerRef.current.onerror = (err) => { // Error handler
      console.error("Worker error:", err.message);
      alert("Something went wrong in the worker: " + err.message);
    };
    return () => {
      workerRef.current.terminate(); // Cleans up the worker on component unmount.
    };
  }, []);

‍

Catch Errors Inside Worker File

In your worker.js, wrap computation in a try/catch:
‍

self.onmessage = function (e) {
  try {
    const n = e.data;

    if (typeof n !== "number" || n < 0) {
      throw new Error("Invalid input for Fibonacci");
    }

    function fibonacci(x) {
      if (x <= 1) return x;
      return fibonacci(x - 1) + fibonacci(x - 2);
    }

    const result = fibonacci(n);
    self.postMessage(result);
  } catch (err) {
    // Send error back to main thread
    self.postMessage({ error: err.message });
  }
};

‍

Key takeaways

• Web Workers allow true multithreading in the browser.
  
• Use them for CPU-intensive tasks like data processing, parsing large files, or complex calculations.
  
• Async/await only helps with I/O operations, not CPU-heavy work.
  
• Always clean up workers using .terminate() to avoid memory leaks.

Conclusion

Web Workers keep React apps responsive by moving heavy computations off the main thread, ensuring smooth user experiences even under load. They are already valuable in finance, simulations, and real-time communication, and their role will expand as WebAssembly, progressive web apps, and edge computing mature. 

Countries like Singapore, South Korea, and Estonia are leading in digital infrastructure, while global research explores energy-efficient and privacy-focused applications. Future directions include integration with in-browser AI, distributed multi-worker systems, and secure collaboration protocols. 

In my view, Web Workers are still underused in React, but they are on track to become a standard tool for performance-driven development.

‍

‍

Many businesses still operate on JavaScript-heavy platforms built years ago. They work on the surface, but under the hood, they slow down under load, fail Core Web Vitals checks, and cost more to maintain than they should.

The rules have shifted. Google now uses Interaction to Next Paint (INP) as a ranking factor, flagging any interaction above 200 milliseconds as poor (Google Web.dev). That means slow responsiveness is no longer just a technical issue; it is a visibility and revenue issue. Users expect instant performance across devices and abandon products that cannot keep up.

At the same time, AI is transforming delivery pipelines. Teams that embed it are cutting release cycles by up to 30 per cent and reducing technical debt remediation by 40 to 50 per cent (McKinsey). Security and compliance expectations are stricter than ever (CISA). Budgets are under pressure, and product leaders are asked to deliver more with less.

The framework choice is secondary. The real question is whether JavaScript delivery produces visibility, lowers costs, and reduces risk.

Challenges

‍

Performance is now a business-critical metric

Applications that miss Core Web Vitals lose visibility and customers. Research shows that every 100ms delay in load time can reduce conversions by up to 7 per cent (Akamai). Many older single-page apps, designed for a different era, simply cannot pass INP thresholds. This is not just about faster websites; it is about protecting top-line revenue.

Technical debt has become a growth blocker

A Stripe study revealed that developers spend 42 per cent of their time dealing with technical debt. Every hour spent patching legacy code is an hour not spent on features that drive growth. The compounding effect is brutal: delays in new launches, growing maintenance overhead, and higher developer turnover. Businesses that fail to address this stall their ability to innovate.

Security is no longer optional

High-profile supply chain attacks such as SolarWinds and malicious npm packages show how easily vulnerabilities slip into production. With regulations tightening globally (GDPR, HIPAA, PCI DSS), compliance failures can result in heavy fines and reputational damage. Security must be embedded in pipelines and runtime, not bolted on later.

Infrastructure costs are climbing without control‍

Running multiple brand websites on separate stacks is expensive and inefficient. Each new launch duplicates effort, inflates hosting bills, and slows expansion. In one case, consolidating 12 fragmented sites into a modular JavaScript platform reduced infrastructure costs by 28 per cent and shortened launch timelines from months to weeks. Businesses that ignore infra optimisation risk ballooning OPEX.

Fragmented experiences weaken brand trust

Without standardised design systems, teams rebuild the same components repeatedly. This leads to inconsistencies across platforms, longer delivery times, and higher costs. Gartner has identified design systems as a key strategy for scaling product delivery effectively (Gartner). For global businesses, fragmented experiences are more than a design issue; they directly impact customer trust and brand equity.

Solutions

‍

Application development tuned for outcomes

React, Angular, Vue, and Svelte are used to build modular, performant apps. Component-driven architecture and asset budgets deliver 80+ Lighthouse scores on mobile as a baseline.
Example: A financial services platform adopted this approach, combined with AI-assisted testing, and reduced regressions significantly, making releases more predictable and performance stable.

Design systems and component libraries‍

Storybook, Tailwind, Radix UI, and Atomic Design principles accelerate delivery by 25–40 per cent while ensuring consistent branding across regions and devices.
Example: A hospitality company used this approach to launch three regional websites in half the time, without diluting experience or brand identity.

Back-end and API development‍

Node.js, NestJS, and Express power robust, secure APIs. Serverless computing reduces infrastructure overhead while ensuring scalability. GraphQL improves developer productivity and system interoperability.

Headless and decoupled delivery

JAMstack approaches with Strapi, Ghost, or Contentful, combined with Next.js, deliver faster content updates and lower infra costs. Example: A global non-profit delivering climate hazard data to governments used headless architecture to serve real-time interactive dashboards with faster performance and easier updates.

AI-enabled workflows

GenAI is integrated directly into delivery: scaffolding, testing, and remediation. Human oversight ensures quality while reducing delivery cycles by 20–30 per cent and cutting technical debt remediation time by 40–50 per cent (Harvard Business Review).
Example: A media company embedded AI into QA workflows, reducing regression issues by half and improving release velocity.

Mobile and cross-platform applications

React Native and Flutter enable mobile apps with one codebase. Feature parity across iOS and Android is faster, with lower maintenance overhead.

Example: A quick-commerce company integrated a headless CMS with React Native, enabling marketers to publish content directly to mobile apps without developer bottlenecks. This reduced turnaround time and increased release cadence.

Cloud and DevOps maturity

CI/CD with GitHub Actions or GitLab CI, observability with Datadog and Prometheus, and Infrastructure as Code ensure predictable, secure deployments. Autoscaling reduces costs by up to 30 per cent while maintaining reliability.

Impact Framework
‍