DEV Community: Muhammad Ahsan

When One Line of Code Works Everywhere - Except Behind CloudFront

Muhammad Ahsan — Mon, 16 Feb 2026 05:44:03 +0000

How a Single CDN Addition Broke Our App, and What It Taught Us About the Invisible Contract Between Infrastructure and Code

Your code doesn't run in a vacuum. It runs on infrastructure. And infrastructure has opinions.

The Setup That Should Have Been Identical

We had a production-grade AI chatbot platform a Next.js dashboard backed by a FastAPI server. Three AWS deployments, same codebase, same Docker image, same CI/CD pipeline.

Server A and Server B worked flawlessly. Users could open a chat, send a message, and get an AI response. Simple.

Server C did something different. When a user sent the very first message in a new chat:

The screen blinked
The message vanished
No response appeared
The network tab showed a cancelled request

But here's the maddening part if the user refreshed the page, the chat appeared in the sidebar. The backend had received and processed the message. The data was there. The UI just... self-destructed before it could render.

Same code. Same image. Three servers. One broken.

The Debugging Spiral

We started where any engineer would the code.

We checked the API layer. Intact. We checked the Redux store. Correct. We checked the authentication interceptors. No rogue logouts. We added debug logging to every layer component mount/unmount, axios interceptors, Redux dispatches.

The logs told us something strange: the entire React component tree was unmounting and remounting during the first message send. Not a re-render. A full destruction and reconstruction. The Redux store was being wiped clean mid-API-call.

This wasn't a React bug. This was a navigation event.

The Invisible Culprit

Here's the code that worked perfectly on two servers and catastrophically failed on the third:

// ChatBlank.tsx  The "new chat" screen
const handleSend = async (text: string) => {
  // 1. Create optimistic thread in Redux
  dispatch(addThread(optimisticThread));
  dispatch(setCurrentThread(tempThreadId));

  // 2. Navigate to the thread view
  router.replace(`/dashboard/chat?threadKey=${tempThreadId}`);

  // 3. Fire the API call
  const response = await chatApi.sendMessage({ question: text, ... });

  // 4. Update with real data
  dispatch(replaceThreadId({ oldId: tempThreadId, newThread: response }));
};

On the surface, this is textbook optimistic UI. Create a temporary thread, navigate to it, fire the API, swap in real data when it arrives. And on Servers A and B, it worked exactly like that.

Server C had one infrastructure difference: CloudFront sat in front of Nginx.

Server A: Browser → Nginx → Next.js     ✅
Server B: Browser → Nginx → Next.js     ✅
Server C: Browser → CloudFront → Nginx → Next.js  💥

The Chain Reaction

Here's what router.replace() actually does under the hood in Next.js App Router (v14+):

It sends an HTTP request to the server with special headers: RSC: 1, Next-Router-State-Tree, Next-Url
The server responds with a lightweight RSC payload (text/x-component) not full HTML
React reconciles the diff and updates the DOM in-place

This is the React Server Components flight protocol. It's elegant and fast when those headers reach the server intact.

CloudFront's default Origin Request Policy (Managed-HostHeaderOnly) forwards exactly one header to the origin: Host. Every other header including RSC: 1 gets silently stripped.

So when router.replace() fired on Server C:

Browser sends: GET /dashboard/chat?threadKey=abc with RSC: 1
CloudFront strips RSC: 1, forwards a plain GET
Next.js sees a normal page request, responds with full HTML (text/html)
The browser receives HTML where it expected an RSC payload
Next.js client-side router falls back to a hard navigation full page reload
The Redux store is destroyed
The in-flight sendMessage API call is cancelled
The page remounts with a blank slate

The message reached the backend (it was already in-flight before the reload), but the response had nowhere to land. The component that dispatched it no longer existed.

The Real Lesson: Infrastructure Is a Runtime Dependency

The fix wasn't a one-line change. It required rethinking the assumption that was baked into the code:

"Client-side navigation is always a lightweight, in-place update."

That assumption holds when your infrastructure is transparent to the framework's protocol. The moment a CDN, proxy, or WAF modifies headers, the contract breaks and it breaks silently. No error. No warning. Just a fallback behavior that looks like a bug in your code.

The Fix: Decouple Navigation from API Calls

We moved the API call out of the component lifecycle entirely, into a Redux thunk. And we replaced router.replace() with window.history.replaceState() a browser-native API that updates the URL without triggering any server request.

// ChatBlank.tsx  After fix
const handleSend = async (text: string) => {
  // 1. Create optimistic thread in Redux
  dispatch(addThread(optimisticThread));
  dispatch(setCurrentThread(tempThreadId));

  // 2. NO router.replace()  let React re-render via Redux state change
  // 3. Fire API call at Redux level (survives component unmount)
  dispatch(sendFirstMessage({ text, model, user, tempThreadId }));
};

// page.tsx  View switches on Redux state, not URL
const activeThreadId = threadKey || currentThreadId;

if (composeMode || (!threadKey && !currentThreadId)) {
  return <ChatBlank />;
}
return <ChatThread threadId={activeThreadId} />;

// thunks/chat.ts  API call + URL update happens at store level
const sendFirstMessage = (params) => async (dispatch) => {
  const response = await chatApi.sendMessage({ ... });

  dispatch(replaceThreadId({ oldId: tempThreadId, newThread }));
  dispatch(setCurrentThread(response.external_chat_id));

  // Update URL only after API completes, using browser API (no RSC fetch)
  window.history.replaceState(
    null, '', 
    `/dashboard/chat?threadKey=${response.external_chat_id}`
  );
};

What changed:

Before	After
`router.replace()` triggers RSC fetch	`window.history.replaceState()` – no server request
API call lives in component (dies on unmount)	API call lives in Redux thunk (survives any re-render)
View switches based on URL	View switches based on Redux state
URL updates reactively via useEffect	URL updates imperatively after API success

The Broader Takeaway

This bug didn't appear in any test suite. It couldn't it only manifested when a CDN sat between the browser and the server. The code was correct. The infrastructure was correctly configured for a traditional web app. But Next.js App Router isn't a traditional web app. It has an implicit runtime protocol (RSC flight) that requires specific headers to pass through every layer of your infrastructure.

Three rules we now follow:

1. Treat your deployment topology as a code dependency.
If your code assumes router.push() does a lightweight RSC fetch, your infrastructure must forward RSC headers. Document this. Test this. Don't discover it in production.

2. Never couple API calls to navigation events.
If a user action requires both "navigate somewhere" and "call an API," those should be independent operations. Navigation can fail, be intercepted, or behave differently across environments. Your API call shouldn't be collateral damage.

3. The same Docker image on different infrastructure is NOT the same deployment.
A CDN, a WAF, a reverse proxy each one is a participant in your application's runtime behavior. "Works on my server" is the new "works on my machine."

The Humbling Part

The CloudFront distribution was added to Server C as a performance optimization faster static asset delivery, edge caching, DDoS protection. A routine infrastructure improvement. No one thought to check whether the CDN would interfere with a framework-level protocol that operates over HTTP headers.

It took a few hours of debugging across application code, Redux state, authentication flows, and network traces before we even looked at the infrastructure layer. The fix was ultimately ~40 lines of code. The diagnosis was the hard part.

Sometimes the most dangerous bugs aren't in the code you write. They're in the assumptions your code makes about the world it runs in.

The Myth of the 10x Developer 🦄

Muhammad Ahsan — Mon, 28 Apr 2025 11:32:24 +0000

The tech world loves the idea of the "10x developer" — someone who can supposedly produce 10 times more results than a typical programmer.

But is it real? Let's dive in.

What Is a 10x Developer?

A 10x developer is imagined to:

Write code 10x faster
Create 10x fewer bugs
Build 10x more scalable systems
Be 10x more productive solo than average devs in teams

Sounds impressive, right? But this idea is more myth than reality.

Why the 10x Developer Is a Myth

Productivity isn't linear: Programming is creative, complex, and deeply collaborative.
Context matters: Tools, teams, and project complexity shape productivity.
Domain-specific strengths: No one is 10x at everything (frontend ≠ backend ≠ DevOps).
Team dynamics: Big systems need communication, not just code speed.

What's More Important Than Being 10x

Instead of chasing myths, developers and teams should focus on:

📚 Continuous Learning: Stay curious, stay humble.
🗣️ Communication Skills: Share knowledge and ideas clearly.
🎯 Design Thinking: Solve real problems with empathy and creativity.
🔥 Agility: Adapt to change and feedback.
🧠 Attention to Detail: Write thoughtful, maintainable code.
🤝 Teamwork: Elevate each other.

Advice for Developers

Stop trying to be a 10x myth.

Start becoming a strong, reliable, ever-improving team player.

Advice for Employers

Stop searching for unicorns.

Start investing in building healthy, high-performance teams with growth mindsets.

🏁 In the end, great software is not built by superheroes.

It’s built by great teams. 🏁

Build Fast vs Build Right 🛠️

Muhammad Ahsan — Fri, 25 Apr 2025 10:46:55 +0000

Intro

"Move fast and break things" sounds exciting… until you’re the one cleaning up the mess.

In software engineering, speed can be deceptive. Often, the push to “build fast” leads to unscalable systems, messy architecture, and endless debugging.

Like financial debt, technical debt must be repaid. And unless it's a disposable one-off, building fast without thinking long-term only makes the project slower.

Make It Work → Make It Right → Make It Fast

This mantra has been around for a reason. Here's what it means:

Make it Work

Get the core functionality running. Validate your idea. Don’t over-polish at this stage.
Make it Right

Refactor. Clean up. Introduce structure. Follow standards. Think about readability, reusability, and maintainability.
Make it Fast

Only optimize after you're sure the code is solid. Premature optimization = unnecessary complexity.

But Reality Isn’t Always Linear

Sometimes, the real-world pressure flips the process:

MVPs need to ship yesterday.
Product-market fit takes priority.
Timelines are tight.

Still, doing things right doesn’t always take longer. Experience teaches you to build smart from the beginning — scalable layout systems, modular code, naming conventions. These don't slow you down, they protect your velocity.

Personal Lesson

At my first job, I rushed to ship a dashboard. I skipped layout planning, ignored consistency, and hardcoded everything.

It worked — barely.

Every minor change required editing 6–7 places. I saved no time. I just delayed the cost.

Conclusion

👉 Build right = build fast in the long run.

Even MVPs benefit from thoughtful design. Don’t trade future progress for present speed.

Have you had moments where "fast" came back to bite you?

Thanks for reading. If you liked this, follow me for more honest takes on software development.

Frontend Isn't Just UI

Muhammad Ahsan — Wed, 23 Apr 2025 09:19:18 +0000

When someone says "frontend," many still think it means styling buttons and aligning layouts. But frontend engineering is way more than UI.

At its core, it's about building systems that serve human experiences.

🔍 System Thinking in the Frontend

Frontend engineers make design decisions that ripple through the entire product.

We think in terms of:

Data flow: Where does the data come from? Who owns it? How is it updated?
State models: What does the UI look like in each state? Loading, error, empty, success?
Component architecture: How do we break the UI into reusable, testable pieces?
User experience flow: How does a user's action change the application state or behavior?
Accessibility and edge cases: Can everyone, regardless of ability or device, use the product?

This is system thinking — seeing the frontend not as isolated screens but as part of a living, breathing system that reacts, updates, and scales.

🧠 UI is Static. Frontend is Dynamic.

Let’s break it down:

UI (Visual Layer)	Frontend Engineering
Buttons and colors	State handling (e.g., Redux)
Layout and spacing	API integration
Typography	Component lifecycle
Icons and visuals	Conditional rendering
Style guides	Form validation & error flows

🧩 A Real-World Example

Imagine building a simple to-do app.

Visually, it’s just:

An input field
A list
Some checkboxes

But behind the scenes, you’re designing:

A state model: What happens when a task is marked done? Deleted? Filtered?
A component structure: List → Item → Checkbox → Actions
Data synchronization: Does this update locally? Remotely? In both?
Error handling: What if the server fails?
Usability: Can a user with screen reader interact with it?

This is system-level thinking — applied to the browser.

🔄 It’s About Building Products That Think

Frontend engineering today is about:

Designing human-centered systems
Balancing speed and structure
Bridging design with logic
Making products that scale and feel good to use

👨‍💻 Final Thoughts

Frontend isn't fluff. It's not just CSS and colors.

It’s the glue between humans and machines.

Whether you’re designing a dashboard, a mobile app, or an interactive form — you’re thinking in systems. And that’s where the real challenge (and joy) lies.

💬 Do you see frontend as a system too? Or just presentation? Let’s talk in the comments.

🌀 Vibe Coding: Hype, Help, or Something In Between?

Muhammad Ahsan — Mon, 21 Apr 2025 09:04:06 +0000

Over the last couple of years, the AI space has exploded with new ideas and buzzwords: LLMs, agentic AI, multi-modal models… and now, the curious rise of "vibe coding."

You might’ve heard this term tossed around by influencers and tech Twitter. It’s essentially about coding with the help of AI — but more casually. Less deep-diving into documentation, and more relying on tools like:

bolt.new
loveable.dev
Cursor
Windsurf
Trae Editor …and dozens more launching every month.

At first glance, it sounds magical. Build apps just by talking to an AI? Dream come true, right?

But here’s the thing: real-world development isn’t just vibes.

🔍 My Personal Experiment with Vibe Coding
I wanted to test this out for myself, so I asked an AI tool to generate a basic portfolio site.

It started off… meh.
Despite clearly mentioning the framework I wanted, the tool picked a completely different stack. Fixing bugs took more time than expected. And to get anything non-trivial done, I had to explain every single logic flow in plain, ultra-specific English.

As the project grew more complex, this back-and-forth quickly turned frustrating.
It became clear: vibe coding wasn’t scalable for a structured project.

🤖 So Who Is Vibe Coding For?
I’d say vibe coding isn’t really beginner-friendly.
Here’s why:

✅ It requires clear, technical prompting
✅ You need to validate the code AI produces
✅ You must debug or refactor things when they break (and they will break)

It’s actually more beneficial for mid-to-senior developers who:

Know how to guide the AI properly
Understand code well enough to debug and iterate
Use AI for productivity boosts, not total replacements

💡 Where Vibe Coding Shines
That said, I’m not against the approach at all.

Vibe coding is great for:

Rapid prototyping
UI mockups and landing pages
Brainstorming technical flows
Automating repetitive boilerplate tasks

It saves time and unlocks creativity.
Just don’t expect it to replace the deep work of engineering — at least not yet.

📊 A Visual Summary
Here’s a summary that captures the reality of vibe coding in 2025:

🧠 Final Thoughts
AI is improving rapidly — and I genuinely believe vibe coding will get better at handling structured logic and long-term projects.

But today?
It’s a tool, not a replacement.

If you’re just starting out as an engineer, focus on learning the fundamentals. Once you know how to code, vibe coding can absolutely become part of your toolkit.

Have you built anything using vibe coding tools?
I’d love to hear your experience. Let’s talk!

#AI #SoftwareEngineering #MERNStack #VibeCoding #LLMs #DeveloperJourney #WebDev #PromptEngineering