DEV Community: Amrendra kumar

Next.js showing old data after a save? Here are 10 checks, in order, that find the cause fast.

Amrendra kumar — Tue, 03 Nov 2026 10:11:26 +0000

Amrendra kumar

Nov 3

Next.js Cache Not Working? A 10-Step Checklist for Next.js 15 and 16

#nextjs #performance #react #webdev

8 min read

Next.js Cache Not Working? A 10-Step Checklist for Next.js 15 and 16

Amrendra kumar — Tue, 03 Nov 2026 10:08:41 +0000

Quick Summary

You save some data. The database says yes. The page still shows the old data. If your Next.js cache is not working, Next.js is usually doing what you told it to do, just on an old copy of the page that you forgot about. A Next.js page can live in four places at once: the build, the server, the browser, and a CDN. Below are five quick questions and 10 steps in order. They help you find the old copy and fix it, for Next.js 15 and for the new use cache style in Next.js 16.

Key Highlight

Do not ask "is the cache broken?" Ask "which copy am I looking at?"
Since Next.js 15, fetch is not cached by default. But a page built ahead of time can still keep old data from build day.
revalidate does not mean "refresh every N seconds". The first visitor after the time is over still sees the old page.
In Next.js 16, revalidateTag('x') with one argument is the old way. Use updateTag or revalidateTag('x', 'max').
Reloading the page fixes an old browser copy. It does nothing for the other three.

Your page lives in 4 places

People say "cache" like it is one thing. It is not. Each place keeps its own copy and gets a new one at a different time.

Where	What it is	Gets a new copy when
Build	Pages made during `next build`	The page is revalidated or rebuilt
Server	Data Cache or `use cache` entries	Time runs out, or you clear it
Browser	The client router cache	You reload, call `router.refresh()`, or its time ends
CDN	A CDN or proxy in front of your app	Its `Cache-Control` rules say so

If you fix the wrong place, nothing seems to change. That is why people deploy five times and learn nothing.

5 quick questions to ask first

Does a full page reload fix it? If yes, the browser has an old copy. Go to step 8.
Does it break only after a production build? Go to steps 1, 3 and 4.
Does the new data show up one visit late? That is step 5.
Did your save work, but the page did not change? Go to steps 6, 7 and 9.
Is it different on your server and on your public URL? Something sits in front of Next.js. Go to step 10.

The 10-step checklist

1. Try it on a real build

next dev and production do not act the same. For example, link prefetching only runs in production. Always check the problem on a real build first.

rm -rf .next
npm run build && npm run start

If the problem is gone here, it was only a dev-mode thing. You can stop.

2. Check which caching style you use

Next.js 16 has two styles, and the docs give different answers for each.

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  cacheComponents: true, // if you see this, you use the new style
}

export default nextConfig

No flag? You use the older style, so steps 3 to 5 matter most. With the flag, steps 7 and 9 matter most.

3. Is your page built at build time?

A fetch with no cache option runs only once, during next build, if your code reaches it before any request-based function like cookies() or headers(). The page is built ahead of time up to that point, so the data stays the same.

// app/posts/page.tsx
export default async function Page() {
  // Runs once at build time. Later it looks like "cache not working".
  const res = await fetch('https://api.example.com/posts')
  return <PostList posts={await res.json()} />
}

If the build-time versus server-time idea is new to you, this short read on how Next.js renders pages at build time and on the server explains the hybrid model.

Choose what you want on purpose:

// Always fresh
await fetch(url, { cache: 'no-store' })

// Fresh at most every 60 seconds
await fetch(url, { next: { revalidate: 60 } })

4. Look for settings that force caching

One forgotten line can freeze a whole route. Search for it.

grep -rn "force-static\|fetchCache\|export const revalidate\|export const dynamic" app/

export const dynamic = 'force-static'   // always build ahead of time
export const fetchCache = 'force-cache' // cache every fetch
export const revalidate = false         // cache, never refresh by time

The settings in the layouts and pages of one route must work together. If two settings fight, a force-* option wins.

5. `revalidate` does not mean "every N seconds"

revalidate = 60 does not rebuild the page every minute. It means: after 60 seconds, the next visitor starts a rebuild.

export const revalidate = 60

// 0s    page is built and saved
// 70s   visitor A -> sees the OLD page, and a rebuild starts in the background
// 71s+  visitor B -> sees the new page

This is called stale-while-revalidate: the old page is shown first, and the fresh one is made in the background. If you need fresh data on the very next request, use cache: 'no-store' or clear the cache yourself (steps 6 and 7).

6. Make sure `revalidatePath` points to the right page

revalidatePath needs the exact path. A wrong path does nothing, and it does not show any error.

'use server'

import { revalidatePath } from 'next/cache'

export async function updatePost(slug: string, formData: FormData) {
  await savePost(slug, formData) // your database call

  revalidatePath(`/blog/${slug}`) // one exact page

  // For every page that matches a dynamic route, use the pattern and a type:
  // revalidatePath('/blog/[slug]', 'page')

  // For shared layout data, like a counter in the header:
  // revalidatePath('/blog/[slug]', 'layout')
}

The docs also say that tags are usually a better choice than paths. They are more exact, and they do not clear more than you need.

7. `updateTag` or `revalidateTag`? Pick the right one

Many people get stuck here after moving to Next.js 16. The two functions do different jobs.

'use server'

import { revalidateTag, updateTag } from 'next/cache'

export async function savePostAction(id: string, formData: FormData) {
  await savePost(id, formData)
  updateTag('posts') // the user sees their own change right away
}

// Route Handler or webhook
export function onWebhook() {
  revalidateTag('posts', 'max') // marks it old; the next visit may still see the old data
  // revalidateTag('posts', { expire: 0 }) // expire it right now instead
}

	`updateTag`	`revalidateTag(tag, 'max')`
Works in	Server Actions only	Server Actions and Route Handlers
What it does	Ends the old data right now	Marks it old, then refreshes on the next visit
Use it when	The user must see their own change	A small delay is fine

8. Check the browser's own copy

You fixed the server, but the screen still shows old data? The browser keeps its own copy of pages you visited. Since Next.js 15, pages that are not built ahead of time are kept for 0 seconds by default. Pages built ahead of time, or fully prefetched, can be reused for about 5 minutes.

Prefetching is what fills this browser copy. If one page has dozens of links, this Next.js performance checklist also explains why too much prefetching can hurt slow connections.

If the user stays on the same page after a save, ask the router for a fresh copy.

'use client'

import { useRouter } from 'next/navigation'

export function SaveButton() {
  const router = useRouter()

  async function onSave() {
    await saveItem() // your Server Action
    router.refresh() // get this page again from the server
  }

  return <button onClick={onSave}>Save</button>
}

Server Actions can also call refresh() to get the current page again. The Server Actions guide explains how.

9. Check your `'use cache'` code

import { cacheLife, cacheTag } from 'next/cache'

async function getPosts() {
  'use cache'
  cacheLife('hours') // 1. choose how long to keep it
  cacheTag('posts')  // 2. add a name so you can clear it later
  return db.post.findMany()
}

Time. Add cacheLife to every cache directive. Without it, a default time is used.
Tag. No tag means you have nothing to give to updateTag or revalidateTag.
Request data. Do not use cookies() or headers() inside cached code. Read them outside and pass the values in.

10. Check what sits in front of your app

A CDN or proxy can keep showing the old page even after Next.js made a new one. Compare a response from your server with one from your public URL, and look at the Cache-Control header on both. The CDN Caching guide in the official docs has more details.

How fresh should your data be?

Many stale-data bugs start because nobody decided this. Decide it once for each type of data.

Data	A good place to start
Blog or CMS content	Keep it for a long time, add a tag, and clear it from a CMS webhook
Product list	One tag per product, and `revalidateTag(tag, 'max')` when it changes
A user's own settings	`updateTag` inside the Server Action that saves them
Live dashboards	`cache: 'no-store'`, or a very short `cacheLife`
Anything for one user	Keep it out of shared caches, and read `cookies()` outside cached code

The docs support the first row: keep CMS data for a long time with tags, and refresh it when the content really changes.

Mistakes that waste the most time

Deploying again to "clear the cache". It may or may not work, depending on your host. Find the old copy first.
Reading old answers. Next.js 14 cached fetch by default. Versions 15 and 16 do not. Many forum answers mix these.
Using revalidatePath('/', 'layout') for everything. It works, but it clears much more than you need.
Keeping revalidateTag('x') with one argument. It is the old way in Next.js 16.
Never testing a production build. Many "cache bugs" only happen in next start.

FAQ

Why is my Next.js revalidate not working?

Most often it is working as designed. The first visitor after the time is over sees the old page, and that visit starts the rebuild (step 5).

Why does Next.js show old data after I save something?

Either you cleared the wrong path or tag (steps 6 and 7), or the browser still has the old page (step 8).

Why does my page show old data after I deploy?

A page built at build time keeps its build-day data until it is revalidated. Add a time-based or on-demand refresh, or turn caching off for that data (step 3).

How do I clear the Next.js cache?

On your computer, delete the .next folder and build again. In production, do not delete files. Use revalidatePath, revalidateTag or updateTag.

Why does the App Router show old data when I click a link?

That is the browser's router cache. Call router.refresh() after the save (step 8).

Is fetch cached by default in Next.js 15 and 16?

No. But a page can still be built ahead of time at build time, and that keeps the data the same in a similar way (step 3).

What is the difference between revalidateTag and updateTag?

updateTag ends the old data right now, and it works only in Server Actions. revalidateTag(tag, 'max') marks the data as old and refreshes it on the next visit.

Conclusion

A stale page just means one of the four places is holding an old copy. Try it on a real build, find the place (build, server, browser or CDN), and use the one fix that belongs to it. Most cases end at step 3, 5 or 8. Keep the five questions handy and ask them before you deploy again.

Disclosure

This article was researched and drafted with AI help, then checked and edited by the author before publishing. Code examples follow the official Next.js docs (versions 15 and 16.2 to 16.3 as of November 2026). Please test them in your own project before you use them.

AI Crawlers in robots.txt: Should You Block or Allow Them?

Amrendra kumar — Tue, 13 Oct 2026 10:59:20 +0000

Disclosure

I'm a developer who works with React, Next.js and AI agents, and I offer related SEO and AI services, so I have a business interest in this topic. I used AI tools to help with research and drafting, and I reviewed the content before publishing. Bot names and rules come from official docs and can change, so check them before you deploy.

Quick Summary

Block training crawlers, allow search crawlers. For most sites, the best setup is to disallow bots that collect data for model training (like GPTBot and ClaudeBot) and allow bots that power AI search (like OAI-SearchBot and Claude-SearchBot). This keeps your content out of training sets but still lets AI tools cite you.

Key Highlights

AI crawlers fall into three jobs: training, search, and user-triggered fetch.
Each bot has its own User-agent name, so you can block one and allow another.
robots.txt controls crawling. It does not hide pages or protect private data.
Blocking OAI-SearchBot removes you from ChatGPT search answers.
Who should read this: site owners, bloggers and developers. Who can skip: sites that already have a bot policy.

How AI Crawlers Work (and Why robots.txt Matters)

AI bots and web crawlers are automated programs that fetch your pages. Some collect text for LLM training data. Others fetch pages so that an AI search tool can display your link in a result.

This is the crawling that you already know from Googlebot, with a difference: the purpose varies depending on which bot. Hence, AI crawler management requires more than one rule.

Your robots.txt file is at the root of your site and uses robots.txt instructions such as User-agent, Allow and Disallow to indicate to each bot which resources it may fetch.

Should You Block AI Crawlers?

Block them only if you have a clear reason. There are three common ones:

You don't want your writing used for model training.
Bots cause server load or bot traffic you can't afford.
Your content is paid or licensed.

Blocking everything has a cost. If you want AI search visibility, such as getting cited in ChatGPT, you need to let the search crawlers in. Decide per bot, not per category of "AI."

GPTBot vs OAI-SearchBot: Can You Separate Training from Search?

Yes. OpenAI says each setting is independent. According to OpenAI's docs, OAI-SearchBot surfaces sites in ChatGPT search, and sites that opt out will not appear in ChatGPT search answers.


Bot	Company	Job	Block it if...
`GPTBot`	OpenAI	Training	You don't want training use
`OAI-SearchBot`	OpenAI	Search results	You don't want ChatGPT search visibility
`ChatGPT-User`	OpenAI	User-triggered fetch	OpenAI notes robots.txt may not apply here
`ClaudeBot`	Anthropic	Training	You don't want training use
`Claude-SearchBot`	Anthropic	Search	You don't want Claude search visibility
`Claude-User`	Anthropic	User-triggered fetch	You don't want user-requested fetches
`Google-Extended`	Google	Gemini AI use	You want to opt out of Gemini use

So yes, you can block GPTBot and still allow ChatGPT search.

Google-Extended robots.txt: What It Does

Google-Extended is a robots.txt token, not a separate crawler. Google documented it as a control over whether your content contributes to training of Gemini models and grounding.

It has no effect on your Google Search ranking or indexing. Blocking it will not make you invisible to Google Search.

Google also says that robots.txt controls crawling, not indexing. To keep a page out of search results, use noindex (the page must be crawlable for Google to see the tag), or put it behind a login.

ClaudeBot robots.txt: The Anthropic Example

Anthropic uses three user agents. ClaudeBot collects content that may be used for training. Claude-SearchBot improves search result quality. Claude-User fetches pages when a person asks Claude about them.

This split lets you opt out of training and stay visible in search, the same pattern as OpenAI.

Which AI Crawlers Should You Allow?

Allow AI search crawlers if you want traffic and citations. Most blogs and business sites gain from this.

Allow: OAI-SearchBot, Claude-SearchBot, PerplexityBot
Usually block: GPTBot, ClaudeBot, CCBot, Google-Extended (if you oppose training use)
Leave to the platform: ChatGPT-User, Claude-User (user-triggered)

If you want to optimize content for AI search, also keep pages fast, server-rendered, and easy to read. Bots that can't see your text can't cite it.

How to Block AI Bots Using robots.txt

Add this to https://yourdomain.com/robots.txt. It blocks training bots and allows search bots:


\# Block AI training crawlers


User-agent: GPTBot

Disallow: /

User-agent: ClaudeBot

Disallow: /

User-agent: CCBot

Disallow: /

User-agent: Google-Extended

Disallow: /

\# Allow AI search crawlers

User-agent: OAI-SearchBot

Allow: /

User-agent: Claude-SearchBot

Allow: /

User-agent: PerplexityBot

Allow: /

# Everyone else (including Googlebot)

User-agent: \*

Allow: /

Sitemap: https\://yourdomain.com/sitemap.xml

To block every AI bot, switch the search bots to Disallow: /. OpenAI says search changes can take about 24 hours to apply.

Check That It Works

Open /robots.txt in your browser and confirm the rules.
Check server logs for bot names like GPTBot and OAI-SearchBot.
Verify real bots using the IP lists the vendors publish (for example, OpenAI's gptbot.json).

If you use Cloudflare or another CDN, check that your firewall isn't blocking bots you allowed. CDN and firewall bot blocking often overrides robots.txt.

Common Mistakes to Avoid

Treating robots.txt as security. It is a polite request. Bad bots can ignore it.
A blanket Disallow: / under User-agent: *. This can block Googlebot too.
Blocking search bots by accident and then wondering why AI tools never cite you.
Using robots.txt instead of noindex. A blocked page can still appear in results if other sites link to it.
Never checking logs. You can't manage what you don't measure.

For related reading on how Google treats AI-made content, see my post on Google's September 2026 spam update.

FAQ

Does robots.txt affect ChatGPT search?

Yes. Allowing or blocking OAI-SearchBot decides whether your site can appear in ChatGPT search answers.

Can I block GPTBot but allow ChatGPT search?

Yes. Disallow GPTBot and allow OAI-SearchBot. They are independent settings.

Will blocking Google-Extended hurt my Google rankings?

No. Google says it doesn't affect Search inclusion or ranking.

How do I control AI crawlers on my website?

Use one User-agent block per bot in robots.txt, then confirm with server logs.

Does robots.txt hide my page from Google?

No. It controls crawling only. Use noindex or authentication to keep pages out of results.

How do I get cited by ChatGPT?

Allow OAI-SearchBot, publish clear and accurate content, and make sure pages load without heavy JavaScript.

Conclusion

You don't have to make the same decision for every AI crawler. If you don't want your website content used for AI model training, consider blocking the relevant training crawlers. If you want your content to be discoverable in AI-powered search results, allow the search crawlers you want to support.

Start by reviewing your website's robots.txt file and checking whether its rules match your SEO goals. Test your configuration before publishing, and remember that robots.txt is a crawler directive, not a security mechanism.

Need help improving your website's technical SEO or AI search visibility? Contact me or explore my SEO and Content Strategy services.

GPT-6 Sol vs Claude Opus 5.5: Which Is Actually Cheaper for Agentic Workflows?

Amrendra kumar — Wed, 23 Sep 2026 07:27:34 +0000

Everyone quotes the same two numbers: GPT-6 Sol is $2/$10 per million tokens, Claude Opus 5.5 is $4/$20. Sol looks half the price. Case closed, right?

Not quite. An AI coding agent reads a file, calls a tool, edits code, and calls another tool sometimes 20 or 50 times for one task. The sticker price barely matters once you factor in cache hits, retries, and how many tokens each model burns to finish. That's the number this post works out.

Quick Answer

GPT-6 Sol is cheaper per token, but usually not per finished task. At list price, Sol is about $2/$10 per million input/output tokens versus Opus 5.5's $4/$20, making it roughly half the price.

However, in a simulated 20-turn coding agent loop, Sol's cost savings drop from 1.87x to about 1.4-1.5x when accounting for the extra retries a cheaper model needs on hard tasks.

For short, high-volume agent loops, Sol wins easily. But for longer, more difficult tasks where a single attempt matters, the actual price difference is much smaller than headline rates suggest.

Price on paper: GPT-6 Sol vs Claude Opus 5.5

Here's the sticker price for both, side by side:

Cost per 1 million tokens	GPT-6 Sol	Claude Opus 5.5
Input	$2.00	$4.00
Cached input (repeat context)	$0.20	$0.20
Output	$10.00	$20.00
Context window	~1.05M tokens	1M tokens
Max output	128K tokens	128K tokens

Two key points explain this difference. First, cached input costs the exact same rate ($0.20 per million tokens) across both models. Cached input refers to the part of your prompt the model has already processed, such as your codebase or chat history, which is billed at a discount. In long agent sessions, most tokens are cached repeats, making the initial input price gap far less significant.

Second, past roughly 272K input tokens, Sol's rates increase for both input and output. When coding agents work on real software projects, they quickly cross this limit, steadily shrinking Sol's cost advantage over time.

The real question: cost per finished task

Token prices show what one request costs, but they do not tell you how many tokens a model needs to finish a job, how many retries it takes, or how much context gets cached.

A cheaper model per token can end up costing more per finished task if it needs multiple attempts or writes longer responses. This cost per completed task is what actually determines your final bill.

Worked example: a 20-turn coding agent loop

Let's say a coding agent needs 20 turns to complete a task, similar to the kind of multi-step automation covered in our piece on AI agents replacing SaaS seats.

During those turns, it might:

Read files
Write or update code
Run tests
Check errors
Fix problems
Repeat until the task is complete

On average, each turn uses:

20,000 cached input tokens: existing conversation and project context
3,000 fresh input tokens: new tool results, errors, or instructions
2,000 output tokens: the model's response and generated code

Cost per Turn

Token Type	GPT-6 Sol	Claude Opus 5.5
Cached input (20K)	$0.004	$0.004
Fresh input (3K)	$0.006	$0.012
Output (2K)	$0.020	$0.040
Total per turn	$0.030	$0.056

If the agent needs 20 turns to finish the task:

Model	Cost for 20 Turns
GPT-6 Sol	$0.60
Claude Opus 5.5	$1.12

So, in this example, Sol costs about 1.87x less than Opus 5.5.

But There Is Another Cost: Retries

A cheaper model is not always cheaper if it needs more attempts to complete the task successfully.

For example, suppose:

Sol needs 1.4 attempts on average
Opus 5.5 needs 1.1 attempts on average

Then the estimated cost per successfully completed task becomes:

Sol: $0.60 x 1.4 = $0.84
Opus 5.5: $1.12 x 1.1 = $1.23

That changes the difference:

Before retries: 1.87x cheaper
After retries: about 1.47x cheaper

The Main Lesson

The cheapest model on paper may not always be the cheapest model in real-world use.

When comparing coding agents, track these three numbers:

Tokens used per turn
Number of turns per task
How often the agent needs to retry

Then use those numbers to calculate your real cost per completed task.

Note: The retry rates above are only examples, not published benchmark results. Your actual results may be different depending on the type and difficulty of your coding tasks.

Hidden costs and mistakes to avoid

Hidden Costs That Can Increase Your AI Bill

The price shown in a model's pricing table is only part of the story. A few other factors can increase your actual costs:

1. Runaway Reasoning Costs

Some models can spend a large amount of tokens on reasoning before producing an answer.

For example, testing has shown that Opus 5.5 at its highest "max" reasoning setting can use its full 128K output limit without producing a usable answer. You can still be charged for that failed request.

This becomes more expensive when an agent automatically retries the task. Setting a reasonable limit on reasoning effort can help control this cost.

2. Long-Context Costs on Sol

Sol becomes more expensive when the input context gets very large.

Once the input goes beyond roughly 272K tokens, both input and output pricing increases.

This matters for coding agents working with large codebases because they can reach this limit faster than expected.

3. Fast and Batch Modes Have Trade-Offs

Faster processing usually costs more.

Sol Fast: roughly 2x the normal rate
Opus 5.5 Fast: $8/$40, with speeds of up to around 2.5x
Sol Batch: roughly 50% cheaper, but it is designed for background processing rather than real-time tasks

Fast mode makes sense when speed is essential, whereas Batch mode is better suited for background jobs that do not need immediate answers, an architecture decision that often overlaps with how teams handle their cloud and DevOps setup.

4. Don't Compare Models by Token Price Alone

One of the biggest mistakes is looking only at the price per token and using that to estimate your monthly bill.

Your real cost also depends on:

How many turns an agent needs
How much output it generates
How often it retries
How much context it sends
Whether you use Fast or Batch processing

The Bottom Line

If you're building AI agents or automation for a product, calculate the expected cost using your actual workloads before choosing a model at scale.

Looking at token prices alone can give you a very different number from your real monthly bill.

This is also an area where our AI automation work can help teams model and control their AI costs.

Which Model Should You Pick?

There isn't one model that is best for every coding task. The right choice depends on the type of work, how often you run it, and how expensive retries are.

Your situation	What to consider first	Why
High-volume, repetitive coding tasks	GPT-6 Sol	Lower token costs can make it more economical for frequent tasks
Difficult tasks where retries are expensive	Claude Opus 5.5	A higher success rate can sometimes justify the higher cost
Long agent sessions with lots of context	Calculate the cost per session	Sol's higher pricing after 272K input tokens can change the cost comparison
Simple classification or routing	Use a smaller model	Sol and Opus 5.5 may be more capable than the task requires

A Practical Approach

Instead of using the same model for every task, you can use a tiered approach:

Start with GPT-6 Sol for regular coding tasks.
Monitor failures, retries, and token usage.
Send difficult or high-risk tasks to Claude Opus 5.5 when the extra reliability is worth the additional cost.
Use smaller, cheaper models for simple tasks such as classification, routing, or basic extraction.

This approach lets you balance cost, speed, and reliability instead of optimizing for token price alone.

If you're designing an AI agent pipeline, our AI agents content and case studies go deeper into the architecture and implementation side.

Conclusion

GPT-6 Sol appears much cheaper than Claude Opus 5.5 when comparing only headline token prices. However, real-world agent costs depend on much more than list rates. Retries, context size, cache usage, reasoning effort, and the number of turns all impact the final bill.

Sol is a practical choice for high-volume, repetitive coding tasks, while Opus 5.5 works well for complex tasks where failed attempts are expensive. The key is to compare total cost per completed task rather than price per token. Test both models on your specific workload, track retries and token usage, and use those real metrics to guide your choice.

AWS vs Google Cloud for Startups: Which Cloud Platform Should You Choose in 2026?

Amrendra kumar — Thu, 03 Sep 2026 11:15:14 +0000

Picking a cloud provider on day one of a startup feels bigger than it is. Both AWS and Google Cloud can run almost any workload you throw at them. The real decision comes down to your team's skills, your budget, and how much hand-holding you want from the platform.

Whatever you decide, it's one piece of a bigger technical picture, and it helps to see the full range of services a startup typically needs before locking in any single choice.

This guide breaks down the cloud computing patterns worth knowing, compares real 2026 pricing, clears up what Docker actually is (yes, people really search "Docker urban dictionary"), and walks through the Well-Architected Framework so you don't over-engineer your first product.

Quick Answer

Pick AWS if you want the widest service catalog, more third-party tutorials, and up to $100,000 in AWS Activate credits. Pick Google Cloud if your product leans on AI/ML workloads, since Google for Startups offers up to $200,000 in credits for AI-focused companies, and its per-pod GKE pricing keeps container costs predictable.

Most early-stage teams outgrow free credits in 6-12 months either way, so architecture discipline matters more than the logo on your invoice.

Cloud Computing Patterns You Need Before Choosing

Before comparing vendors, get the patterns straight, since they matter more than the provider logo:

Microservices vs. modular monolith: split your app into small services only once a real team-scaling problem shows up. Before that, a modular monolith ships faster with fewer moving parts. If you're weighing this trade-off in detail, we broke it down fully in microservices vs. modular monolith in 2026.
Event-driven architecture: services talk through queues or event buses (SQS/EventBridge on AWS, Pub/Sub on Google Cloud) instead of calling each other directly. This keeps one slow service from taking down the rest.
Auto-scaling / elastic compute: pay for capacity only when traffic needs it. Both clouds do this well; the difference is how much configuration it takes to get there.
Managed database over self-hosted: startups rarely have the headcount to patch and back up their own database servers. RDS/Aurora and Cloud SQL/Spanner exist so you don't have to.
Infrastructure as Code (IaC): Terraform or each provider's native tool (CloudFormation, Deployment Manager) so your infrastructure is versioned, not clicked together in a console.

These patterns are cloud-agnostic. Get comfortable with them first, and switching providers later becomes a config change, not a rewrite.

AWS vs Google Cloud: Pricing for Startups in 2026

AWS Activate gives startups up to $100,000 in credits, while Google for Startups offers up to $200,000 for AI-focused companies, but credits run out, and what you pay after matters more.

Factor	AWS	Google Cloud
Startup credits	Up to $100K (AWS Activate)	Up to $200K for AI startups
Compute free tier	750 hrs/month for 12 months	1 f1-micro instance, free indefinitely
Container pricing	EKS bills per node you manage	GKE Autopilot charges per pod and manages the control plane and nodes for you
Egress pricing	~$0.09/GB after free tier	~$0.08-0.12/GB, tiered by volume
Best for	Broadest service catalog, hiring pool	AI/ML workloads, simpler container ops

For a small team running containers, GKE Autopilot cuts operational overhead noticeably compared to manually managing EKS node groups. On the other hand, AWS's sheer size means almost every problem already has a Stack Overflow answer and a hire who's used it before, which counts for something when you're a five-person team without a dedicated DevOps hire.

One real trap: cross-region data transfer. Put your app server in one region and your database in another, and every request pays an inter-region egress fee on both clouds. Teams have cut cloud bills by more than half just by colocating resources in the same region, so check this before you optimize anything else.

If your team doesn't have in-house DevOps expertise yet, that's usually the actual bottleneck, not the provider. Our cloud & DevOps team sets up cost-safe infrastructure from the start so you're not relearning this the hard way at $12K/month.

What Docker Actually Means

If you searched "Docker urban dictionary," you're probably half-joking and half-confused why developers say "just Dockerize it" like it's obvious. Here's the real, boring-but-useful definition:

Docker is a tool that packages your app plus everything it needs to run, code, runtime, libraries, settings, into a single unit called a container. That container runs the same way on your laptop, your teammate's laptop, and in production. No more "it works on my machine."

It's not a cloud provider, not a programming language, and not related to actual shipping docks, though the container metaphor is intentional.

If the underlying JavaScript and runtime concepts inside that container still feel fuzzy, this walkthrough of core JavaScript concepts fills in a lot of the gaps.

Docker Use Cases for Early-Stage Startups

Consistent local development: every new hire runs docker compose up and gets the exact same environment, no manual setup docs.
CI/CD pipelines: build once, test in a container, deploy that same container to staging and production.
Microservices packaging: each service ships in its own container with its own dependencies, so upgrading one doesn't break another. This is exactly the pattern behind something like a RAG chatbot for your business website, where the retrieval service usually runs as its own container.
Running on either cloud without lock-in: a containerized app moves between AWS ECS/EKS and Google Cloud Run/GKE with minimal rework, which keeps your options open if pricing shifts later.
Local testing of managed services: tools like LocalStack let you mimic AWS services in a container before touching real infrastructure and racking up charges.

The same container-first thinking is why more of the manual ops work founders used to do by hand is increasingly handled by autonomous workflows; we cover that shift in why AI agents are replacing SaaS seats in 2026.

Application Architecture Diagram: A Startup Stack on Each Cloud

A typical early-stage SaaS architecture looks almost identical on both clouds, only the service names change:

User → CDN → Load Balancer → App Servers (containers) → Cache → Database
                                     ↓
                              Object Storage (uploads, assets)
                                     ↓
                              Queue → Background Workers

AWS version: CloudFront → ALB → ECS/EKS → ElastiCache → RDS/Aurora, with S3 for storage and SQS for queues.
Google Cloud version: Cloud CDN → Cloud Load Balancing → Cloud Run/GKE → Memorystore → Cloud SQL/Spanner, with Cloud Storage and Pub/Sub.

Notice the shape doesn't change; this is the point of learning patterns before providers. If your team is still deciding how to structure this for a real product, our web development team has built this exact stack for founders who'd rather ship features than debug VPC configs.

The backend shape barely shifts between providers, but the frontend layer sitting on top of it keeps evolving fast; this look at the future of web development in 2026 covers where that's headed.

Even small UI details, like the one walked through in building a light and dark theme switch with JavaScript, stay completely unaffected by which cloud sits underneath.

Well-Architected Framework: AWS vs Google Cloud

AWS's Well-Architected Framework provides best practices across six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability (added later to account for the environmental cost of running workloads).

Google Cloud has its own equivalent, the Architecture Framework, built around nearly identical pillars: operational excellence, security/privacy/compliance, reliability, cost optimization, and performance optimization.

For a startup, you don't need to formally review against all six pillars on day one. Focus on three early:

Security: lock down IAM roles and never hardcode credentials, from commit one.
Cost optimization: set billing alerts before you set up your first database.
Reliability: know what happens when your one server goes down, even if the answer today is "we get paged and restart it manually."

Revisit the full framework once you have paying customers and something real to lose.

Hidden Costs, Mistakes, and Red Flags

Idle resources: a forgotten staging database or an orphaned load balancer bills you every month until someone notices.
Cross-region traffic: as noted above, this quietly inflates bills more than compute usually does.
Over-provisioned databases: teams default to enterprise-tier databases during free-credit periods, then can't justify downgrading later.
No budget alerts: the single easiest fix, and the one most skipped-over setting in both consoles.
Choosing based on credits alone: credits expire in months; your architecture and monthly burn rate outlive them by years.

Cloud infrastructure is only one line item in a startup budget. If you're also scoping the cost of the product itself, this breakdown of what a Next.js website costs in 2026 is a useful companion to the numbers above.

FAQ

Is Google Cloud cheaper than AWS for startups?

It depends on your workload. GCP tends to be cheaper for container-heavy and AI workloads due to per-pod billing and sustained-use discounts; AWS is often cheaper for simple compute and storage due to its wider range of instance sizes.

Which cloud is easier to learn for a first-time founder?

Google Cloud's console and pricing model are generally considered simpler. AWS has a steeper learning curve but far more tutorials, courses, and hires who already know it.

Can I switch clouds later if I start with the wrong one?

Yes, especially if you containerize with Docker from the start and use Infrastructure as Code. It's real work, but not a rewrite.

Do I need Kubernetes as a small startup?

Usually not on day one. A single container on Cloud Run, ECS Fargate, or even a plain VM is enough until you have multiple services that need independent scaling.

What is the AWS Well-Architected Framework used for?

It's a structured way to review your cloud architecture against best practices in security, cost, reliability, performance, operations, and sustainability, useful once you have a real product, overkill for a prototype.

How much do startup cloud credits actually cover?

Enough for 6-12 months of moderate usage in most cases. Google Cloud offers the highest maximum credits at $200,000 over two years for qualifying startups, but plan your post-credit budget at least six months before they run out.

Should I pick a cloud based on AI/ML needs?

If AI is core to your product, yes: Google's TPU access provides notably better performance per dollar for specific machine learning workloads. If AI is a feature, not the product, either cloud's GPU instances work fine. If you need help scoping AI infrastructure, our AI & automation team can review what your product actually needs before you commit spend.

Conclusion

There's no universally "better" cloud in 2026. AWS and Google Cloud both handle real production workloads without breaking a sweat. AWS wins on breadth, hiring pool, and startup credit size. Google Cloud wins on simpler container pricing, an indefinite free tier, and better economics if AI/ML is core to your product.

What actually decides the outcome for most startups isn't the provider, it's whether the architecture follows sound patterns from day one: containerize with Docker, keep resources in one region, set budget alerts before you set up a database, and use Infrastructure as Code so switching later stays possible.

Getting infrastructure spend under control early also frees up budget for the parts of the business that actually bring in users.

That's usually digital marketing once you have a working product, paired with an SEO and content strategy to make sure people can find it.

If you're still unsure which way to go, start smaller than you think you need to, watch your bill weekly for the first three months, and revisit the Well-Architected (or Google's Architecture Framework) pillars once you have real users and something worth protecting.

For more guides like this one, our blog covers the rest of the stack too.

Written by Amrendra: Frontend Developer & Technical Content Writer, working hands-on with React and Next.js projects, and helping startups make cloud and architecture decisions that don't blow up their runway.

If you're newer to the ecosystem, how to learn React is a good place to start.

Need help picking and setting up the right cloud stack, or the UI/UX and product design layer that sits on top of it? Get in touch.

Get System Theme in JavaScript: Detect Dark/Light Mode Automatically

Amrendra kumar — Wed, 19 Aug 2026 07:23:14 +0000

Last month I was fixing a theme bug on a client project under our web development services, and the issue was frustrating. The site looked perfectly fine on my laptop, but a user on macOS with dark mode enabled complained about a blinding white flash every time the page loaded.

That single ticket taught me more about system theme detection than any tutorial ever did, and it is the reason I am writing this guide the way I wish someone had explained it to me back then.

If you are building a website or web app in 2026, respecting a visitor's operating system preference is no longer optional. Browsers, phones, and desktops all let users choose between light and dark mode at the system level, and modern users expect websites to follow that choice automatically instead of forcing them to hunt for a toggle button.

What Does "System Theme" Actually Mean

When someone switches their OS to dark mode, whether on Windows, macOS, Android, or iOS, that preference gets exposed to the browser through a CSS media feature called prefers-color-scheme. JavaScript can read this same signal using the window.matchMedia() API, which is built into every modern browser and needs no external library.

In short, you are not guessing the user's preference. You are reading a value the operating system already reports.

The Core Code Snippet

Here is the simplest way to check the current system preference:

const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;

if (prefersDark) {
  document.documentElement.setAttribute('data-theme', 'dark');
} else {
  document.documentElement.setAttribute('data-theme', 'light');
}

This single line does the heavy lifting. matchMedia returns a MediaQueryList object, and its matches property tells you whether the query currently applies. When I first used this in production, I was surprised how little code was actually required compared to the workarounds I had seen in older projects that relied on cookies or manual detection scripts.

Reacting to Live Theme Changes

A static check only tells you the preference at page load. Many users switch their system theme during the day, especially on laptops that auto-switch at sunset, so your site should react without needing a refresh. Add an event listener to the same media query object:

const mediaQuery = window.matchMedia('(prefers-color-scheme: dark)');

mediaQuery.addEventListener('change', (event) => {
  const theme = event.matches ? 'dark' : 'light';
  document.documentElement.setAttribute('data-theme', theme);
});

I added this listener to a SaaS dashboard we shipped earlier this year, and support tickets about "the site looks wrong" dropped noticeably because the interface now matched whatever the user's OS was doing in real time, without a manual reload.

Avoiding the Flash of Wrong Theme

One mistake I made early on was placing this detection script at the bottom of the page, right before the closing body tag. That caused a visible flash of the wrong theme for a split second before JavaScript ran. The fix is simple: put a small inline script in the document head, before any stylesheet loads, so the theme attribute is set before the browser paints anything.

<script>
  document.documentElement.setAttribute(
    'data-theme',
    window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'
  );
</script>

This tiny change removed the flicker completely on every project where I applied it since.

Combining System Detection With a Manual Toggle

Detecting the system theme is only half the picture. Most users still expect a toggle button so they can override the OS setting for that specific site. If you want the full implementation, including how to store the user's manual choice with localStorage so it persists across visits, we covered that in detail in our guide on building a light and dark theme switch using JavaScript. Read that alongside this article if you need both automatic detection and a manual override in the same project.

Where This Fits Into Product Design

System theme detection is not just a coding exercise. It directly affects how polished a product feels to real users, which is why our UI/UX and product design work always includes theme handling as a baseline requirement, not an afterthought. A product that respects a user's system preference from the first paint feels considerably more trustworthy than one that ignores it.

Common Mistakes to Avoid

Based on the projects I have reviewed for clients, these are the errors that show up most often:

Checking the preference only once and never listening for changes, so the theme goes stale if the user switches mid-session.
Running the detection script after the CSS has already loaded, which causes the flash mentioned earlier.
Forgetting to remove the event listener when a component unmounts in frameworks like React, which can cause memory leaks on single-page applications.
Assuming matchMedia is always supported. It is available in every current browser, but a quick if (window.matchMedia) guard is still good defensive coding for older environments.

Testing Your Implementation Properly

Do not rely only on changing your OS setting to test this feature, since that is slow and easy to forget. Chrome, Firefox, and Safari all let you emulate prefers-color-scheme directly inside developer tools, which makes testing both states in seconds instead of minutes.

Final Thoughts

Reading the system theme in JavaScript takes only a few lines of code, but getting it right, without flicker, without stale state, and with proper cleanup, is what separates a rushed implementation from a genuinely polished one. This is the exact kind of detail we handle across our frontend development and React work at Code with Amrendra.

If you are working through a similar frontend challenge or want a second pair of eyes on your theming setup, browse more guides on our engineering blog or reach out through our contact page and we will be glad to help.

Microservices vs Modular Monolith in 2026: Which Architecture Actually Scales?

Amrendra kumar — Wed, 05 Aug 2026 10:22:34 +0000

Choosing between a modular monolith and microservices is one of the most important architectural decisions for modern software teams. While microservices remain popular for large-scale distributed systems, they also introduce operational complexity that many applications do not need.

In 2026, the industry trend is shifting toward modular monoliths as a practical starting point, with services extracted only when business and organizational requirements justify the transition.

Introduction

This article gives you a code-level pattern for enforcing module boundaries, a comparison table with real cost figures, and a checklist to decide when extraction is justified. You will be able to structure a modular monolith that avoids the "big ball of mud" failure mode and know exactly which signals mean it is time to split a service out. For a deeper look at how these boundaries hold up at scale, see this breakdown of SaaS system design and multi-tenant architecture.

What a Modular Monolith Actually Is

A modular monolith is not "a monolith with folders." It requires enforced module boundaries at the code level, not convention-based ones that erode after six sprints.

/src

/billing

/internal <- not importable from other modules

api.ts <- the only public surface

/catalog

/internal

api.ts

/shipping

/internal

api.ts

Each module exposes one api.ts file. Nothing outside /billing imports from /billing/internal. Linting rules (ESLint boundaries plugin, or a build-time check in CI) fail the build if that rule is broken. This is the difference between a modular monolith and a monolith that will need a rewrite in two years.

Microservices vs Modular Monolith: Comparison Table


Factor	Modular Monolith	Microservices
Development Speed	Faster	Slower initially
CI/CD Complexity	Low	High
Testing	Easier	More complex
Monitoring	Simple	Requires observability tools
Learning Curve	Lower	Higher
Infrastructure	Minimal	Extensive
Deployment Risk	Single deployment	Isolated deployments

Source: AWS microservices architecture documentation (aws.amazon.com/docs), byteiota 2026 cost analysis. Last updated: August 2026.

When to Extract: The Signal Checklist

Do not extract a service because a blog post told you to. Extract when at least two of these are true at the same time:

One module needs 10x the compute or scaling profile of the rest of the system
Two or more teams are blocked waiting on each other's deploys inside the same codebase
A specific module has a regulatory isolation requirement, such as PCI-scoped payment processing
Engineering headcount on the codebase has passed roughly 50 and merge conflicts across domains are routine

If none of these apply, extraction adds network latency and operational surface area for no measurable gain.

From Startup to Platform Engineering: A Practical Architecture Evolution

Most successful software products do not begin with microservices. They start as a modular monolith, allowing teams to ship features quickly while keeping operational complexity low. As the product grows and more developers contribute, clear bounded contexts help organize the codebase into independent business domains without splitting the application.

When certain modules require independent scaling, faster release cycles, or regulatory isolation, those well-defined boundaries make it easier to extract selective microservices with minimal disruption.

Over time, larger engineering organizations often adopt platform engineering to standardize deployments, observability, security, and developer workflows. This evolutionary approach balances simplicity today with flexibility for tomorrow, avoiding unnecessary complexity while preparing the system for long-term growth.

The Distributed Monolith Trap

A distributed monolith happens when teams deploy separate services that still share a database or make synchronous chained calls to complete one request. You get all the network cost of microservices with none of the independence benefit. As per the GitHub-documented modular monolith reference implementations (github.com), the fix is establishing bounded contexts through Domain-Driven Design before any physical service split, not after. If your "microservices" cannot deploy independently without coordinating a release, you have not built microservices. You have built a monolith with extra network hops.

FAQ

1. What is a modular monolith? A single deployable application organized into modules with enforced boundaries: separate internal namespaces, one public API per module, and no direct imports across module internals.

2. When should you choose microservices over a modular monolith? When independent scaling, regulatory isolation, or a team size past roughly 50 engineers creates coordination costs that outweigh the network and operational overhead of distributed services.

3. Can a modular monolith scale like microservices? Yes for most workloads. Shopify runs a modular monolith at enterprise transaction volume by keeping strict internal boundaries and extracting only specific high-load services.

4. How do you migrate from a modular monolith to microservices? Identify bounded contexts using Domain-Driven Design, confirm the module already has a clean internal API, then extract it behind that same interface as a networked service.

5. What is a distributed monolith and why is it bad? It is multiple deployed services that still share a database or require synchronous coordinated releases. It combines microservices' network cost with a monolith's coupling.

6. Do you need Domain-Driven Design for a modular monolith? Not strictly, but bounded context modeling is the most reliable method for drawing module boundaries that will not need to be redrawn after launch.

7. How many developers before microservices make sense? Most 2026 industry data points to roughly 50 to 100 engineers as the threshold where coordination overhead in a single codebase starts to exceed distributed systems overhead.

8. Is Shopify a monolith or microservices? Shopify's core platform is a modular monolith built on Ruby on Rails, with services extracted selectively only where independent scaling justifies it.

About the Author

Amrendra Kumar is a software engineer and technical writer at
Code with Amrendra, where he
covers React, Next.js, AI Agents, SaaS architecture, and cloud
infrastructure. He has written 200+ technical articles on frontend
engineering, system design, and modern web development.

LinkedIn |GitHub

AI Chatbots for Small Business: Do You Really Need One?

Amrendra kumar — Wed, 29 Jul 2026 09:54:43 +0000

AI chatbots for small business make sense when repetitive questions eat more than a few hours a week, or when traffic arrives after hours with nobody there to answer it. code with Amrendra cost far less per interaction than a human agent and typically pay for themselves within one to three months.

They are a poor fit for low-traffic sites or complex, high-touch sales conversations that need a real person on the other end.

Introduction

This article answers one question directly: does your business actually need an AI chatbot, or is it another tool you will pay for and ignore by month three. Most content on this topic comes from chatbot vendors, so the numbers get generous fast.

Here you get the real cost math, the signals that matter, and the cases where a chatbot is the wrong call.

If you are also weighing broader automation beyond support tickets, our AI agent workflows and automation guides cover the wider landscape.

By the end, you will have a simple framework to decide, not a sales pitch.

What an AI Chatbot Actually Does for a Small Business

An AI chatbot for small business handles three jobs well: answering repeated FAQs, capturing leads outside business hours, and routing complex questions to a human.

It does not run your business for you. Most tools train on your existing website content or help docs and go live in under a day. The value is not the technology itself. It is the hours it takes off your plate every week that you were previously spending on the same five questions.

The Real Cost-Per-Interaction Math

Here is the number that actually matters before you buy anything: what does each customer interaction cost you today, and what would it cost through a bot.

Support method	Cost per interaction	Typical availability	Setup time
Human agent (part-time or owner)	$6 to $15	Business hours only	N/A
AI chatbot (no-code SaaS)	$0.50 to $0.70	24/7	Minutes to a few hours
AI chatbot (custom-built)	Varies by volume	24/7	Days to weeks

Industry reports consistently put first-year ROI for small businesses somewhere between 150% and 1,000%, with payback in one to three months for anyone handling a meaningful volume of repeat questions.

Below roughly 100 conversations a month, fixed platform costs eat most of that advantage, so the math only works once you have enough volume to matter.

3 Signals You Actually Need One

You spend 30 minutes or more a day answering the same handful of questions across email, WhatsApp, or your website
Your analytics show real traffic arriving after hours or on weekends with no one available to respond
You are losing leads because a visitor asks a question, gets no answer fast enough, and leaves

If none of these apply, a chatbot will sit unused. If two or more apply, you are already paying the cost of not having one, you just are not seeing it as a line item.

For businesses ready to move past support automation into broader workflow automation, our AI automation services team scopes exactly this kind of decision before recommending a build.

When It's a Bad Investment

Skip the chatbot if your site gets under 300 to 500 monthly visitors. There is not enough volume for the automation to pay for the platform fee, let alone save meaningful time.

Skip it too if your sales process depends on a real conversation, high-ticket consulting, complex custom quotes, relationship-driven B2B deals. A bot that mishandles a $20,000 deal because it guessed at an answer costs more than the support hours it saved.

Why Most Small Business Chatbots Underperform

A large share of small business chatbots get switched off within the first year despite promising ROI numbers on paper. The reason is rarely the AI model. It is scope.

Teams point the bot at every question instead of the repetitive ones, skip the escalation path to a human, and never review transcripts to catch bad answers. A narrow bot with a fast handoff to a person outperforms a broad bot with no supervision, every time.

How to Decide: A 60-Second Framework

Count your repetitive interactions per week. Multiply by $6 to $15 to get your current cost.
Check if that number exceeds $50 to $100 a month, roughly the cost of a no-code chatbot plan.
If yes, and you have the traffic volume to support it, a chatbot is a reasonable bet.
If your sales process is high-touch and low-volume, do not automate it. Automate FAQs instead and keep humans on the deals.

Frequently Asked Questions

1. Do small businesses actually need an AI chatbot?

Not always. It depends on traffic volume and how much time you currently spend on repetitive questions.

2. How much does an AI chatbot cost for a small business?

No-code SaaS chatbots typically run $20 to $100 a month, with per-interaction costs around $0.50 to $0.70 compared to $6 to $15 for a human agent handling the same query.

3. What is the typical ROI of an AI chatbot?

Industry benchmarks report first-year ROI ranging from 150% to over 1,000%, depending on conversation volume, deflection rate, and your existing support costs.

4. Can a chatbot fully replace human customer support?

No. It should handle repetitive, low-complexity questions and escalate anything ambiguous or high-stakes to a human. Bots without an escalation path are the main reason chatbot projects get abandoned.

5. How long does it take to set up a chatbot?

A no-code SaaS chatbot trained on your existing FAQs or help docs can go live in minutes to a few hours. Custom-built bots integrated with internal tools take longer, typically days to weeks.

About the Author

Amrendra Kumar is a Frontend developer and Senior technical writer at Code with Amrendra, where he
covers React, Next.js, AI Agents, SaaS architecture, and cloud
infrastructure. He has written 27+ technical articles on frontend
engineering, system design, and modern web development.

LinkedIn |
GitHub

Postman vs Insomnia: Which API Testing Tool Wins in 2026

Amrendra kumar — Wed, 22 Jul 2026 10:37:54 +0000

Postman vs Insomnia comes down to storage model and automation depth, not features. Postman ships Newman for CI/CD, richer mock servers, and a paid team model starting at $19/user/month after cutting its free tier to one user in March 2026.

Choosing between Postman and Insomnia in 2026 means picking a storage model and an automation pipeline, not just a UI.

Both tools cover REST, GraphQL, and basic collaboration, but they diverge hard on CI/CD tooling, pricing at scale, and how they fit into modern engineering workflows, including the AI agent tool-calling pipelines teams are now building around OpenAPI specs.

This article benchmarks both CLIs in an actual GitHub Actions run, walks through migrating a real collection between the two, and covers pricing changes that shipped earlier this year.

Postman vs Insomnia at a Glance

Postman is the broader platform. Insomnia is the leaner client with more storage flexibility.

Category	Postman	Insomnia
Founded	2014, originally a Chrome extension	2016, acquired by Kong in 2019
License	Proprietary, free tier	Core is Apache 2.0, open source
Protocols	REST, GraphQL, gRPC, WebSocket, MQTT	REST, GraphQL, gRPC, WebSocket, SSE, SOAP
Storage	Cloud-first, account required	Local Vault, Git Sync, or Cloud Sync per project
CLI	Newman	inso
Memory footprint	500MB or more, 2-3 second startup	200-300MB, under 1 second startup
Mock servers	Yes, with request/response simulation	Yes, via plugin-based mock responses

Insomnia's per-project storage choice is the detail most comparisons skip. A regulated team can keep everything in Local Vault with no account. A platform team can commit collections to the same monorepo as the services they test using Git Sync.

Storage Model: Local Vault, Git Sync, and Cloud Sync

Insomnia lets you pick storage per project instead of forcing one model on the whole team. Local Vault keeps collections entirely on-device. Cloud Sync adds optional end-to-end encryption for teams that want centralized access without a Git workflow.

Postman took the opposite direction. Since it discontinued Scratch Pad, its offline mode, in September 2023, the default workspace experience requires an account and cloud sync.

There is no equivalent to Git Sync built into the core product. Teams in healthcare, finance, or air-gapped environments that need collections to live in version control alongside code have to route through export/import workflows instead of native sync.

If your team already lives in Git for everything else, Insomnia's model removes a step. If your team is fine with cloud accounts and wants Postman's monitoring and mock server depth, the storage difference matters less.

CI/CD in Practice: Newman vs inso

Postman automates through Newman, its Node-based CLI. Insomnia automates through inso, bundled as the insomnia-inso npm package. Both run inside GitHub Actions, GitLab CI, or Jenkins without a GUI.

GitHub Actions Workflow Comparison

Here is a single workflow file running both tools against the same API so you can compare output format and setup cost directly.

name: api-tests
on: [push]

jobs:
  postman-newman:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g newman
      - name: Run Postman collection
        run: |
          newman run ./collections/orders-api.postman_collection.json \
            -e ./environments/staging.postman_environment.json \
            --reporters cli,junit \
            --reporter-junit-export ./newman-report.xml

  insomnia-inso:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g insomnia-inso
      - name: Run Insomnia unit tests
        run: |
          inso run test orders-api \
            --workspace ./insomnia \
            --env Staging \
            --reporter junit \
            --output ./inso-report.xml

Both jobs exit non-zero on a failed assertion, so either integrates cleanly into a required status check.

The practical difference shows up in maintenance: Newman has a larger reporter ecosystem (HTML, Slack, Datadog exporters exist as separate packages), while inso ships fewer built-in reporters but needs less configuration to point at a Git-synced workspace, since the workspace folder is already a plain directory of files.

Tool	CLI package	Config source	Reporter ecosystem
Newman	`newman` (npm)	Exported `.postman_collection.json`	Large, many third-party reporters
inso	`insomnia-inso` (npm)	Native workspace directory (Git Sync friendly)	Smaller, built-in JUnit/JSON only

For more CI/CD patterns beyond API clients, see the DevOps automation guides on this blog.

Migrating a Postman Collection to Insomnia

Insomnia's inso CLI imports Postman v2.1 collections directly. This is the part most comparisons skip entirely.

# Convert a Postman v2.1 collection into an Insomnia workspace
npx insomnia-inso import \
  --type postman \
  --src ./collections/orders-api.postman_collection.json \
  --workspace ./insomnia/orders-api.insomnia.json

# inso writes a new Insomnia workspace file at the target path.
# Environment variables map 1:1 between the two formats.
# Pre-request scripts and tests written in pm.* syntax do NOT convert automatically.
# Rewrite pm.test() assertions using Insomnia's chai-based assertion API before relying on the import.

The gap that costs the most time in practice is scripting. Postman's pm.sendRequest, pm.test, and pm.environment.set calls have no direct Insomnia equivalent. Budget time to manually port any collection that leans on pre-request scripts, not just simple request/response pairs.

GraphQL and Multi-Protocol Support

Insomnia's GraphQL interface has cleaner schema introspection and autocomplete out of the box, which is why it shows up repeatedly in comparisons as the pick for GraphQL-heavy teams. Postman supports GraphQL too, but the request builder treats it closer to a REST body with a query string rather than as a first-class protocol.

For gRPC and WebSocket testing, both tools support connection reuse and streaming responses. Insomnia adds native SOAP and Server-Sent Events support, which Postman does not offer directly.

If your team's API surface is REST-only, this distinction will not affect your decision. If GraphQL or gRPC is a meaningful share of your traffic, test both interfaces against your actual schema before standardizing.

Pricing in 2026: What Actually Changed

Postman's Free plan dropped to a single user on March 1, 2026, ending the free multi-user collaboration that many small teams relied on. Any shared workspace now requires a paid Team plan.

Plan tier	Postman	Insomnia
Free	1 user only (since March 2026)	Unlimited users, Hobby/Essentials tier
Entry paid	Team, $19/user/month	Solo/Pro, $12/user/month
Enterprise	$49/user/month	$45/user/month

Insomnia still advertises free cloud collaboration for unlimited users on its core plan, which is the opposite direction from Postman's March 2026 change.

For a 10-person team, that gap alone can run into thousands of dollars a year, so confirm current tier limits on each vendor's pricing page before budgeting, since both companies have changed terms more than once in the past 18 months.

Using API Collections in AI Agent Workflows

Neither tool markets itself around AI agents, but both export OpenAPI specs, and that export is what makes them useful in tool-calling pipelines.

If you are building an agent that needs to call your internal API, the OpenAPI spec your Postman or Insomnia collection already produces can be converted directly into a tool schema.

// Convert an exported OpenAPI spec into an LLM tool schema
import { readFileSync, writeFileSync } from "fs";

const spec = JSON.parse(readFileSync("./openapi.json", "utf-8"));

const tools = Object.entries(spec.paths).map(([path, methods]: [string, any]) => {
  const [method, def] = Object.entries(methods)[0] as [string, any];
  return {
    name: def.operationId ?? `${method}_${path.replace(/\W+/g, "_")}`,
    description: def.summary ?? "",
    input_schema:
      def.requestBody?.content?.["application/json"]?.schema ??
      { type: "object", properties: {} }
  };
});

writeFileSync("./tools.json", JSON.stringify(tools, null, 2));
// Each entry now matches the shape an LLM tool-use API expects directly.

In production agent systems, this pattern removes the need to hand-write a tool schema for every internal endpoint. Whichever client your team already uses to maintain the collection becomes the source of truth for the agent's tool definitions too, so the API documentation and the agent's capabilities never drift apart.

This is the one place in this comparison where the choice of Postman or Insomnia genuinely does not matter, since both export a standard OpenAPI document that the conversion script above accepts unchanged.

Which Tool Should You Standardize On

Pick Postman if your team needs Newman's mature reporter ecosystem, built-in monitoring, and mock server depth, and the per-seat pricing at your team size is acceptable after the March 2026 free tier cut.

Pick Insomnia if your team wants Git-native collection storage, faster local performance, stronger GraphQL and multi-protocol support, or you are trying to avoid Postman's account requirement for offline work.

Neither choice is permanent. The migration script above makes switching a matter of hours for simple collections, and days for collections with heavy pre-request scripting, not a rebuild from scratch.

Frequently Asked Questions

1. Is Insomnia better than Postman for GraphQL?

Insomnia's GraphQL interface has cleaner schema introspection and query building.

2. Can you import Postman collections into Insomnia?

Yes, using inso import --type postman. Requests and environment variables convert directly. Pre-request scripts and pm.test() assertions do not convert automatically and need to be rewritten.

3. Is Insomnia really free?

The core client is Apache 2.0 licensed and free for unlimited users on the Hobby or Essentials tier, including Local Vault, Git Sync, and Cloud Sync. The Pro tier at $12/user/month adds RBAC and higher mock request limits.

4. Which is better for CI/CD, Newman or inso?

Both integrate cleanly into GitHub Actions and exit non-zero on failed assertions. Newman has a larger third-party reporter ecosystem.

5. Is Postman still free for teams in 2026?

Not for shared workspaces. As of March 1, 2026, Postman's Free plan is limited to one user. Any team collaboration requires the paid Team plan at $19/user/month.

If this helped, follow along on GitHub for the migration script and CI workflow files used in this comparison: github.com/AmrendraCodes.

About the Author

Amrendra Kumar is a software engineer and technical writer at Code with Amrendra, where he covers React, Next.js, AI Agents, SaaS architecture, and cloud infrastructure.

He has written 15+ technical articles on frontend engineering, system design, and modern web development.

LinkedIn | GitHub

Stop Using Media Queries for Everything: Learn CSS Container Queries

Amrendra kumar — Sun, 05 Jul 2026 17:52:54 +0000

Every frontend developer reaches for media queries as the default tool for responsive design. For years, that's made sense media queries check the size of the browser viewport and adjust styles accordingly.

But once you start building smaller, reusable pieces of UI sidebar widgets, product cards, dashboard tiles media queries alone start to fall short. This is where CSS container queries come in, and if you're building components for real projects, they're worth adding to your toolkit today.

Quick Introduction

If you're still getting comfortable with component-based frontend development in general, my post on how to learn React is a good companion read alongside this one.

In this blog, I'll cover:

Media Queries Syntax
CSS Media Types
Enter Container Queries
Why This Matters for Component-Driven Design
Browser Support: When to Use Them
Conclusion

Media Queries Syntax

Media queries let you apply CSS styles based on features of a device or the environment a webpage is displayed in. They're the foundation of responsive web design, and you add them to a stylesheet using the @media rule.

A media query consists of an optional media type and one or more media features, each of which resolves to either true or false:

@media [not] media-type and (media-feature: value) and (media-feature: value) {
  /* CSS rules to apply */
}

The media type is optional — but if you use not, you must specify a media type explicitly.

The overall query evaluates to true if the specified media type matches the current device and all listed media features are also true. When that happens, the corresponding style rules are applied.

CSS Media Types

The optional media type specifies which kind of media the styles are meant for. If it's omitted, it defaults to all.

Value	Description
all	Used for all media type devices
print	Used for print preview mode
screen	Used for computer screens, tablets, and smartphones

This works well at the page level. But a card or widget component doesn't actually care how wide the browser window is — it cares how much space it has been given inside its parent. That's the gap container queries were built to close.

Enter Container Queries

Container queries flip the logic. Instead of asking "how wide is the browser window?", they ask "how wide is the element's parent container?" This means a single component can adapt intelligently no matter where it's placed on the page.

Here's the basic syntax:

.card-container {
  container-type: inline-size;
  container-name: card;
}

@container card (min-width: 400px) {
  .card {
    display: flex;
    gap: 1rem;
  }
}

Two things are happening here:

container-type: inline-size tells the browser to treat this element as a query container, tracking its inline (usually horizontal) size.
@container is the at-rule that lets you write conditional styles based on that container's size, not the viewport.

Now the .card component adapts based on the space it's actually given — whether that's a full-width hero section or a 300px sidebar slot.

Why This Matters for Component-Driven Design

Modern frontend development leans heavily on reusable components — design systems, React component libraries, CMS-driven page builders. These components get dropped into all kinds of layouts, often ones the original developer never anticipated.

Container queries make components genuinely self-sufficient. They don't need to know about the page; they only need to know about their own boundaries.

That's a meaningful shift in mindset: responsive design stops being purely a page-level concern and becomes something you build directly into individual components.

Browser Support and When to Use Them

Container queries now have solid support across all major modern browsers — Chrome, Firefox, Safari, and Edge. For most production use cases today, they're safe to adopt, especially with a graceful fallback in place for older browsers if you need to support legacy environments.

That said, container queries aren't a full replacement for media queries — they solve a different problem. Use media queries for overall page-level layout decisions (like switching from a single-column to a multi-column layout based on viewport width), and use container queries when a specific component needs to adapt based on its own available space.

Conclusion

Media queries aren't going away, but relying on them for every responsive decision creates unnecessary rigidity. Container queries give developers a more precise, component-first tool — one that matches how modern UIs are actually built.

If you're designing reusable components, it's worth adding container queries to your toolkit today. Want to go deeper? Check out more frontend breakdowns like this on the CodeWithAmrendra blog. And if you'd like to talk shop, learn more about my work on the about page, or hire me for your next project. You can also get in touch here.

Happy coding!

Improving Your React Code by Avoiding Hooks Mistakes

Amrendra kumar — Tue, 30 Jun 2026 09:21:14 +0000

Quick Summary:

In 2026, planning to design a website or apps is quite easier. One more thing is came which named as React hooks, that also discussed in this Blog, Mainly react hooks are came from three sources like as: missing dependencies from component also breaks render component for 'useffect'.

Most teams reach for useCallback and useMemo before diagnosing the actual re-render cause, which adds complexity without fixing the bug. Fix the dependency array first, profile second, memoize last.

After this, you will be able to triage a Hooks-related bug report without guessing, and decide whether useMemo is solving a real problem or just adding noise.

For deeper patterns on component design, see these React architecture patterns.

What Actually Breaks: The 3 Hook Mistakes That Cause Production Bugs

These three are responsible for the majority of Hooks bugs that make it past code review. Each one looks correct at a glance and only breaks under specific render conditions.

Stale closures from missing dependencies

A closure inside useEffect, useCallback, or useMemo captures variables at the time the function was created, not at call time. Omit a dependency and the callback keeps using the value from the render where it was defined.

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      console.log(count); // always logs 0 — stale closure
    }, 1000);
    return () => clearInterval(id);
  }, []); // missing 'count' dependency

  return <button onClick={() => setCount((c) => c + 1)}>Increment</button>;
}

The fix is not to silence the lint rule. Add count to the dependency array, or switch to the functional update form (setCount(c => c + 1)) if the effect doesn't actually need to read count directly. As per the React docs (react.dev, 2025), the dependency array exists specifically to keep effect callbacks synchronized with the latest render's values.

Conditional hook calls breaking render order

React tracks hook state by call order, not by name. A hook called behind a condition shifts every hook after it on the next render where the condition changes.

// Wrong — breaks hook order when `id` becomes empty
function Game({ id }) {
  if (!id) return <p>Select a game</p>;
  const [game, setGame] = useState(null);
  useEffect(() => { /* fetch game */ }, [id]);
  return <GameView game={game} />;
}

// Correct — hooks run unconditionally, logic moves after
function Game({ id }) {
  const [game, setGame] = useState(null);
  useEffect(() => {
    if (!id) return;
    /* fetch game */
  }, [id]);
  if (!id) return <p>Select a game</p>;
  return <GameView game={game} />;
}

Run eslint-plugin-react-hooks (npmjs.com) in CI, not just locally. This class of bug often passes a quick manual test and fails only under specific prop transitions in production.

Unbounded useEffect re-runs without cleanup

Every useEffect that sets a timer, subscription, or listener needs a cleanup function. Skip it and every re-run stacks another active subscription on top of the last one.

useEffect(() => {
  const timer = setTimeout(() => doSomething(), 1000);
  return () => clearTimeout(timer); // prevents leaks and duplicate timers
}, [doSomething]);

In codebases without this pattern enforced, a single screen with three subscribing effects can leak dozens of listeners after a few minutes of normal navigation. The symptom is rarely a crash — it's degraded performance that only shows up after the app has been open a while, which is why it survives code review.

useCallback vs useMemo vs Doing Nothing

Most Hooks guides tell you to memoize without explaining when memoization is wasted work. React re-runs a component function on every render regardless of memoization; useCallback and useMemo only stop downstream re-renders or recomputation, and they cost a comparison check every render to do it.

Situation	Use	Why
Function passed to a `React.memo` child	`useCallback`	Without it, a new function reference breaks the child's prop equality check every render
Expensive computation (sort, filter, transform) on large data	`useMemo`	Skips recomputation when inputs are unchanged
Function or value used only inside the same component	Neither	No downstream consumer benefits from referential stability; the memoization check costs more than the work it saves
Object or array literal passed as a prop	`useMemo` (or restructure props)	Object literals are a new reference every render, defeating `React.memo` on the receiving component
Simple inline handler with no memoized child	Neither	Premature memoization here is dead weight

In large React codebases, unnecessary useMemo/useCallback calls are one of the more common causes of code review churn — they signal a performance concern that was never measured, and they make diffs harder to read for no measurable gain.

How to Diagnose a Re-render Problem Before You Memoize Anything

Don't memoize speculatively. Open React DevTools, enable the Profiler tab, and record an interaction that feels slow. The flame graph shows which components re-rendered and why DevTools labels the trigger as props, state, context, or parent re-render.

If the trigger is "parent re-rendered" and the child's props are unchanged primitives, wrap the child in React.memo first. Only add useCallback/useMemo upstream if the Profiler still shows the child re-rendering after that change that's the signal a new reference is breaking the memo check, not a guess.

This sequence (profile, then memo the child, then memoize the source if needed) catches the actual bottleneck instead of scattering useCallback across a component tree based on intuition. Teams that skip the Profiler step typically end up memoizing the wrong layer and still ship the original slowdown.

Do React 19's Compiler and Actions Change These Mistakes?

The React Compiler (react.dev, 2025) auto-memoizes components and values at build time, which removes the need for manual useCallback/useMemo in most cases when the compiler is enabled. It does not fix stale closures or conditional hook calls those are still runtime correctness bugs the compiler can't infer away.

useActionState and form Actions, introduced in React 19, replace a chunk of the manual useState + useEffect pattern previously used for form submission and pending states, which removes one entire category of dependency-array mistakes by removing the effect itself. The mistakes in this guide are not obsolete; they shift toward correctness (closures, hook order) rather than performance, since the compiler increasingly handles the performance side.

FAQ

1. What is the most common mistake with useEffect?

Omitting a dependency that the callback actually reads, which produces a stale closure. The effect keeps using the value from whichever render it was created in, not the latest one, until something forces a re-run with the correct dependency array.

2. Why does my useEffect cause an infinite loop?

Usually an object or array literal in the dependency array, or a state setter inside the effect that updates a value the effect also depends on. Each render creates a new reference, which the dependency comparison treats as changed, triggering another run.

3. Can I call a Hook inside a condition or loop?

No. React tracks hook state by call order across renders, and a conditional call shifts that order whenever the condition changes. Call hooks unconditionally at the top level and move conditional logic after the hook calls.

4. What is a stale closure in React Hooks?

A closure that captured a variable's value from a previous render and never updates, because it's missing from the dependency array. It shows up as a callback that logs or uses an outdated value even though the component has re-rendered with new state.

5. When should I use useCallback vs useMemo?

Use useCallback when passing a function to a memoized child component. Use useMemo for expensive computations or to stabilize object/array references passed as props. Skip both when nothing downstream depends on referential stability.

About the Author

Amrendra Kumar is a software engineer and technical writer at Code with Amrendra, where he covers React, Next.js, AI Agents, SaaS architecture, and cloud infrastructure. He has written 15+ technical articles on frontend engineering, system design, and modern web development.

LinkedIn | GitHub

Stop Wasting Renders: How to Handle Complex REST APIs in Your Frontend

Amrendra kumar — Tue, 16 Jun 2026 11:52:03 +0000

React REST API render optimization comes down to three problems: mixing server state with client state in useState, firing network requests on every component mount because staleTime defaults to 0, and creating request waterfalls through nested component data fetching.

This article covers the three architectural patterns that cause render waste when integrating REST APIs in React, and the exact production fixes for each. You will come away knowing how to separate server state from client state, configure TanStack Query's cache correctly, and eliminate request waterfalls without restructuring your entire component tree.

If you are also thinking about how component architecture affects render behaviour at scale, Building Reusable React Component Systems at Scale covers the structural decisions that compound with API integration patterns.

The Real Source of React Render Waste

Most render waste does not come from missing React.memo. It comes from storing server state in local useState.

Server state and client state have fundamentally different update requirements:

Server state: async, shared across components, stale after time, needs background refresh
Client state: synchronous, local to a component or feature, user-driven

When you put an API response into useState, every parent re-render, every context update, every sibling state change can cause your fetch cycle to reset or your component to re-render with data it already had. There is no deduplication, no shared cache, no background refresh. Separating these two concerns is the foundational step before any library decision.

For teams building on Next.js, the same separation applies at the framework level — Building Scalable Next.js Applications covers how to structure data fetching across App Router without coupling server state to component lifecycle.

Why `useEffect` + `useState` for API Calls Doesn't Scale

// This pattern breaks at scale
function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    const controller = new AbortController();

    fetch(`/api/users/${userId}`, { signal: controller.signal })
      .then(res => res.json())
      .then(setUser);

    // AbortController required to handle race conditions
    // when userId changes faster than the previous request resolves
    return () => controller.abort();
  }, [userId]);
}

Two components mounting simultaneously with the same userId fire two separate network requests. No shared cache. No deduplication.

Manual AbortController just to handle race conditions. This is not a pattern to optimise with memoization it is a pattern to replace above a certain complexity threshold.

Request Waterfalls: How to Diagnose and Fix Them

A request waterfall is when network requests execute sequentially that could run in parallel. Two patterns cause this in React.

Pattern 1 : Dependent queries: fetch user, then fetch posts using the user ID. The posts request cannot start until the user request resolves.

Pattern 2 : Nested component waterfalls: parent fetches data, conditionally renders a child, child fetches its own data. The child's request cannot start until the parent finishes rendering.

Both are diagnosable in Chrome DevTools Network tab. Look for sequential same-domain requests with no timing overlap.

Fixing Dependent Queries with `useQueries`

import { useQueries } from '@tanstack/react-query';

function Dashboard({ userId }: { userId: string }) {
  const results = useQueries({
    queries: [
      {
        queryKey: ['user', userId],
        queryFn: () => fetchUser(userId),
      },
      {
        queryKey: ['posts', userId],
        queryFn: () => fetchPosts(userId),
        // enabled prevents firing until userId exists,
        // but does NOT create a waterfall both queries
        // are registered and run in parallel on mount
        enabled: !!userId,
      },
    ],
  });

  const [userQuery, postsQuery] = results;
}

As per TanStack Query v5 docs (tanstack.com/query/latest/docs), useQueries runs all queries in parallel by default. The enabled flag controls whether a query fires not whether it waits for another query to complete.

Fixing Nested Component Waterfalls with Prefetching

// Route loader  executes before the component tree renders
export async function loader({ params }) {
  const queryClient = getQueryClient();

  // Prefetch child data so it's already in cache
  // when the child component mounts and calls useQuery
  await queryClient.prefetchQuery({
    queryKey: ['comments', params.postId],
    queryFn: () => fetchComments(params.postId),
  });

  return null;
}

The child component calls useQuery for comments and gets a cache hit immediately. The network request is gone from the component render cycle entirely.

`staleTime` and `gcTime`: The Two Config Values That Matter Most

The TanStack Query default is staleTime: 0. This means every component mount is treated as a cache miss and fires a network request. In a dashboard with 10 components reading the same endpoint, that is 10 requests on a single page load.

Configure staleTime per data type based on how often that data actually changes:

Data Type	Recommended `staleTime`	`gcTime`	Reasoning
User profile	5 minutes	10 minutes	Changes rarely mid-session
Live feed / notifications	10-30 seconds	1 minute	Needs to stay current
Config / reference data	1 hour	24 hours	Almost never changes
Search results	30 seconds	2 minutes	User expects fresh results

Source: TanStack Query v5 docs (tanstack.com/query/latest/docs). Configuration values based on production patterns. Last updated: June 2026.

For multi-tenant SaaS products where different tenants have different data freshness requirements, this configuration approach changes significantly — Designing Multi-Tenant SaaS Platforms for Scale covers the database and routing strategies that inform how per-tenant cache configuration should be structured.

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 5 * 60 * 1000,  // 5 minutes: safe default for stable data
      gcTime: 10 * 60 * 1000,    // 10 minutes: keep in memory after unmount
    },
  },
});

// Override per query where freshness requirements differ
useQuery({
  queryKey: ['notifications'],
  queryFn: fetchNotifications,
  staleTime: 15 * 1000, // 15 seconds: this data must stay current
});

gcTime controls when inactive cached data gets garbage collected not how long it is considered fresh. Setting gcTime lower than staleTime means data is garbage collected before it goes stale, which defeats the cache entirely.

SWR vs TanStack Query: Which One for Your Use Case

Feature	SWR v2	TanStack Query v5
Bundle size (gzipped)	~4.2KB	~13KB
Request deduplication	YES	YES
`staleTime` control	Limited	Full, per-query
Mutation handling	`useSWRMutation` (basic)	`useMutation` (full)
DevTools	NO (official)	YES
`useSuspenseQueries`	NO	YES
TypeScript inference	Good	Excellent (v5)
Optimistic updates	Manual	Built-in with rollback

Source: swr.vercel.app, tanstack.com/query/latest/docs. Bundle sizes from bundlephobia.com. Last updated: June 2026.

Decision rule: Use SWR if you need minimal bundle size and simple fetch-cache-revalidate patterns with Next.js. Use TanStack Query if you have mutations, dependent queries, DevTools requirements, or need useSuspenseQueries for waterfall elimination.

Optimistic Updates Without Breaking Data Integrity

The trap with optimistic updates is rollback handling. If the mutation fails, you must revert the UI without a flash or a stale cache entry surviving into the next render cycle.

const mutation = useMutation({
  mutationFn: (updatedPost) => updatePost(updatedPost),

  onMutate: async (updatedPost) => {
    // Cancel outgoing refetches to avoid overwriting
    // the optimistic update with stale server data
    await queryClient.cancelQueries({ queryKey: ['posts', updatedPost.id] });

    // Snapshot the previous value  this is the rollback target
    const previousPost = queryClient.getQueryData(['posts', updatedPost.id]);

    // Apply the optimistic change to the cache immediately
    queryClient.setQueryData(['posts', updatedPost.id], updatedPost);

    return { previousPost };
  },

  onError: (err, updatedPost, context) => {
    // Restore snapshot on failure
    queryClient.setQueryData(['posts', updatedPost.id], context.previousPost);
  },

  onSettled: (updatedPost) => {
    // Always refetch after success or error
    // to sync cache with actual server truth
    queryClient.invalidateQueries({ queryKey: ['posts', updatedPost.id] });
  },
});

onSettled runs after both success and error, ensuring the cache eventually reflects server truth regardless of what happened during the optimistic phase. Skipping onSettled leaves the cache in an optimistic state permanently if the server silently rejects the mutation

Production Checklist: React REST API Integration

Before shipping any React feature that calls a REST API, verify:

Server state lives in TanStack Query or SWR, not in useState
staleTime is configured per query based on actual data freshness requirements — not left at the default of 0
Network tab shows no sequential same-domain requests that could run in parallel
Mutations use onError rollback — not just onSuccess handling
QueryClient is instantiated per request in SSR contexts, never at module level (module-level QueryClient leaks data across users in server environments)
Query cancellation is wired for queries that depend on rapidly-changing props like search input

Conclusion

React render waste from REST APIs is an architectural problem, not a component-level one. The fix starts with separating server state from client state, then configuring your cache to match actual data freshness requirements, then eliminating waterfalls before they reach production.

Every pattern in this article is production-tested and applies directly to dashboards, SaaS products, and admin panels hitting REST endpoints at scale.

If this helped, follow on GitHub for production React patterns and annotated code samples: github.com/AmrendraCodes

About the Author

Amrendra Kumar is a software engineer and technical writer at Code with Amrendra, where he covers React, Next.js, AI Agents, SaaS architecture, and cloud infrastructure.

LinkedIn | GitHub

DEV Community: Amrendra kumar

Next.js showing old data after a save? Here are 10 checks, in order, that find the cause fast.

Next.js Cache Not Working? A 10-Step Checklist for Next.js 15 and 16

Next.js Cache Not Working? A 10-Step Checklist for Next.js 15 and 16

Quick Summary

Key Highlight

Your page lives in 4 places

5 quick questions to ask first

The 10-step checklist

1. Try it on a real build

2. Check which caching style you use

3. Is your page built at build time?

4. Look for settings that force caching

5. revalidate does not mean "every N seconds"

6. Make sure revalidatePath points to the right page

7. updateTag or revalidateTag? Pick the right one

8. Check the browser's own copy

9. Check your 'use cache' code

10. Check what sits in front of your app

How fresh should your data be?

Mistakes that waste the most time

FAQ

Why is my Next.js revalidate not working?

Why does Next.js show old data after I save something?

Why does my page show old data after I deploy?

How do I clear the Next.js cache?

Why does the App Router show old data when I click a link?

Is fetch cached by default in Next.js 15 and 16?

What is the difference between revalidateTag and updateTag?

Conclusion

Disclosure

AI Crawlers in robots.txt: Should You Block or Allow Them?

Quick Summary

Key Highlights

How AI Crawlers Work (and Why robots.txt Matters)

Should You Block AI Crawlers?

GPTBot vs OAI-SearchBot: Can You Separate Training from Search?

Google-Extended robots.txt: What It Does

ClaudeBot robots.txt: The Anthropic Example

Which AI Crawlers Should You Allow?

How to Block AI Bots Using robots.txt

Check That It Works

Common Mistakes to Avoid

FAQ

Does robots.txt affect ChatGPT search?

Can I block GPTBot but allow ChatGPT search?

Will blocking Google-Extended hurt my Google rankings?

How do I control AI crawlers on my website?

Does robots.txt hide my page from Google?

How do I get cited by ChatGPT?

Conclusion

GPT-6 Sol vs Claude Opus 5.5: Which Is Actually Cheaper for Agentic Workflows?

Quick Answer

Price on paper: GPT-6 Sol vs Claude Opus 5.5

The real question: cost per finished task

Worked example: a 20-turn coding agent loop

But There Is Another Cost: Retries

The Main Lesson

Hidden costs and mistakes to avoid

Hidden Costs That Can Increase Your AI Bill

The Bottom Line

Which Model Should You Pick?

A Practical Approach

Conclusion

AWS vs Google Cloud for Startups: Which Cloud Platform Should You Choose in 2026?

Quick Answer

Cloud Computing Patterns You Need Before Choosing

AWS vs Google Cloud: Pricing for Startups in 2026

What Docker Actually Means

Docker Use Cases for Early-Stage Startups

Application Architecture Diagram: A Startup Stack on Each Cloud

Well-Architected Framework: AWS vs Google Cloud

Hidden Costs, Mistakes, and Red Flags

FAQ

Conclusion

Get System Theme in JavaScript: Detect Dark/Light Mode Automatically

What Does "System Theme" Actually Mean

The Core Code Snippet

Reacting to Live Theme Changes

Avoiding the Flash of Wrong Theme

5. `revalidate` does not mean "every N seconds"

6. Make sure `revalidatePath` points to the right page

7. `updateTag` or `revalidateTag`? Pick the right one

9. Check your `'use cache'` code

Why `useEffect` + `useState` for API Calls Doesn't Scale

Fixing Dependent Queries with `useQueries`

`staleTime` and `gcTime`: The Two Config Values That Matter Most