DEV Community: Muhammad Rabbi

I Thought This E-commerce Site Was Making Zero API Requests. I Was Wrong.

Muhammad Rabbi — Wed, 30 Sep 2026 18:10:58 +0000

I Thought This E-commerce Site Was Making Zero API Requests. I Was Wrong.

A few days ago, I was inspecting an e-commerce website because I wanted to understand one thing:

"How the hell is this page getting its data without making an obvious API request?"

The site was Ghorer Bazar, and I was looking at a collection page:

/collections/honey-2

I opened Chrome DevTools, went straight to the Network tab, filtered the requests, and started looking for the usual suspects:

/api/products
/api/products?category=honey
/graphql
/products

Nothing obvious.

And that tiny observation sent me down a much deeper rabbit hole.

I started asking questions that turned into a complete architecture investigation:

Is the data being fetched from an API?
Is it rendered on the server?
Is the HTML cached?
Is Cloudflare involved?
Why does navigation sometimes feel instant?
Is the browser prefetching pages?
What exactly are Priority Hints?
Could I build my own Next.js e-commerce site like this?
Most importantly, how do all these pieces fit together?

This article is the story of what I learned.

The First Clue: "Where Is the API?"

I started with the most basic assumption.

An e-commerce page has products.

Products live in a database.

Therefore:

Browser
   ↓
API
   ↓
Database

Right?

That's one common architecture.

For example:

Browser
   ↓
GET /api/products?category=honey
   ↓
Backend
   ↓
PostgreSQL

The browser receives JSON:

{
  "products": [
    {
      "id": 1,
      "name": "Premium Honey",
      "price": 850
    }
  ]
}

Then JavaScript renders the products.

So naturally I expected to see something similar in DevTools.

But I didn't.

Instead, the important request looked like this:

GET https://ghorerbazar.com/collections/honey-2

Status: 200
Type: document
Content-Type: text/html

And that changed the direction of the investigation.

The Browser Was Already Receiving HTML

The request wasn't:

/api/products

It was:

/collections/honey-2

And the response was:

text/html

That means the browser wasn't necessarily asking:

"Give me the product data."

It could simply be asking:

"Give me the page."

And somewhere on the server, the application can do the database work before sending the result back.

Conceptually:

Browser
   │
   │ GET /collections/honey-2
   ▼
Server
   │
   │ Query database
   ▼
Database
   │
   │ Products
   ▼
Server
   │
   │ Render HTML
   ▼
Browser

So there doesn't have to be a visible browser request such as:

/api/products

The database query can happen entirely on the server.

That distinction was probably the biggest lesson of this whole investigation.

"No API Request" Does Not Mean "No Data Request"

This is something I think many frontend developers misunderstand at first.

There are two very different things.

Browser → API

Browser → /api/products → Server → DB

And:

Browser → Page → Server → DB

Browser → /collections/honey-2 → Server → DB

In the second architecture, the database request exists.

You just don't see it from the browser.

It's server-side work.

This is one of the reasons frameworks such as Next.js are interesting.

With the App Router, Next.js supports Server Components and server-side data fetching, so application code can retrieve data on the server rather than forcing every database interaction through a browser-visible REST endpoint.

For example, conceptually:

export default async function CollectionPage() {
  const products = await prisma.product.findMany({
    where: {
      category: "honey",
    },
  });

  return (
    <div>
      {products.map((product) => (
        <ProductCard
          key={product.id}
          product={product}
        />
      ))}
    </div>
  );
}

The browser doesn't need to know that Prisma exists.

It simply receives the rendered result.

Then I Looked at the Network Headers

Now things became even more interesting.

The collection page response showed headers like:

Server: cloudflare
Content-Encoding: br
Cache-Control: max-age=600, public
CF-Cache-Status: DYNAMIC

There were also cookies being set.

The response was going through Cloudflare.

This immediately gave me another piece of the architecture.

Instead of:

Browser
   ↓
Next.js
   ↓
Database

the architecture can look more like:

Browser
   ↓
Cloudflare
   ↓
Application Server
   ↓
Database

Cloudflare can sit in front of the application as a CDN, reverse proxy, security layer, and cache.

But this is where I made another mistake.

Cloudflare ≠ Everything Is Cached

Seeing:

Server: cloudflare

does not automatically mean:

"This page came from Cloudflare's cache."

The response I inspected had:

CF-Cache-Status: DYNAMIC

That means the particular response was classified as dynamic rather than being returned as a cache hit.

This is an important distinction.

Cloudflare can be sitting in front of your application even when a request still reaches your origin server.

So the architecture could still be:

Browser
   ↓
Cloudflare
   ↓
Origin server
   ↓
Database

Cloudflare is still useful even if that HTML response isn't cached.

Then Why Was There `max-age=600`?

This was another nice DevTools lesson.

The page had:

Cache-Control: max-age=600, public

At first glance, that looks like:

"Great, the page is cached for 10 minutes."

But caching is more complicated than reading one header.

There are multiple layers involved:

Browser cache
       +
CDN cache
       +
Application/framework cache
       +
Database

A response can have cache-related headers without necessarily behaving exactly how you expect at every caching layer.

Things like cookies, cache rules, request headers, and CDN configuration can affect the result.

That's why:

Cache-Control: public

and:

CF-Cache-Status: DYNAMIC

can appear together.

The lesson wasn't:

"Cloudflare caching is broken."

The lesson was:

Never assume the caching architecture from a single header.

Inspect the entire request/response behavior.

The Page Was Loading A Lot More Than Just HTML

At this point I started looking at the complete Network waterfall instead of one request.

On my captured run, the page had roughly:

148 requests
4.6 MB transferred
14.5 MB resources
DOMContentLoaded ≈ 2.62s
Load ≈ 3.74s

There were:

JavaScript bundles
CSS
fonts
images
analytics
third-party scripts
security scripts
chat-related resources
application code

One JavaScript bundle alone was around hundreds of kilobytes.

So the page wasn't magically fast because it loaded "nothing."

It was loading plenty.

What mattered was how the work was organized.

Then I Discovered the Difference Between HTML and Navigation

This was the next puzzle.

I noticed that navigating around modern websites can feel almost instant.

You click:

Honey

Then:

Dates

Then:

Oil

And it feels like the browser never fully reloads.

But does that mean there was no network request?

Not necessarily.

Modern frameworks can change the meaning of navigation.

With Next.js App Router, client-side navigation, prefetching, Server Components, streaming, and caching can all work together.

So there are several possibilities.

Possibility One: Full Page Request

The simplest case:

Click link
   ↓
Browser requests page
   ↓
Server responds with HTML
   ↓
Browser loads it

This is a traditional navigation.

Possibility Two: Prefetching

Here's where things get interesting.

Imagine you are on:

And there is a link:

/collections/honey-2

The framework may decide to fetch information for that route before you click it.

So the timeline can become:

Page loaded
    ↓
Browser sees link
    ↓
Prefetch happens
    ↓
User clicks
    ↓
Already-prepared data is used
    ↓
Navigation feels instant

Now imagine opening DevTools after you've clicked.

You might think:

"There was no request!"

But the request may have happened before you clicked.

That completely changes how you debug performance.

You shouldn't only ask:

"What happened after the click?"

You should ask:

"What happened before the click?"

That Was My "Aha!" Moment

I had been treating the browser like a simple messenger:

User click
   ↓
Request
   ↓
Response

Modern applications are more like:

Initial load
   ↓
Prefetch
   ↓
Caching
   ↓
Server rendering
   ↓
Client-side navigation
   ↓
Streaming
   ↓
Image optimization

Several of those can happen before the user consciously notices anything.

That's why performance debugging requires watching the entire lifecycle rather than one request.

Then I Found Priority Hints

Another thing that caught my attention was Priority Hints.

This is one of those features that sounds complicated until you reduce it to one question:

"Which resource should the browser care about first?"

Imagine a product page contains:

Hero image
Product image
20 review avatars
Footer logo
Chat icon
Analytics script

The browser has limited bandwidth and connection resources.

Should all of them have the same urgency?

Obviously not.

Your hero image might be extremely important because it is part of the first visible screen.

The footer logo?

Probably not.

Priority Hints allow developers to provide the browser with a hint about resource importance.

Conceptually:

<img
  src="/hero.webp"
  fetchpriority="high"
/>

versus:

<img
  src="/background-decoration.webp"
  fetchpriority="low"
/>

The important word is hint.

It's not a command saying:

"Browser, you MUST download this first."

It's a signal about relative priority.

And that distinction matters.

Priority and Lazy Loading Are Not the Same Thing

This was another useful distinction.

Developers often mix these together:

Lazy loading

and:

Fetch priority

They solve different problems.

Lazy loading asks:

"Should this resource wait until it is near the viewport?"

Priority asks:

"Once this resource is eligible to load, how urgent is it compared with other resources?"

For an e-commerce page, that can become a nice combination:

Hero image
→ load early
→ high importance

Below-the-fold images
→ lazy load
→ lower urgency

Decorative assets
→ low priority

Next.js's image tooling is designed to help with responsive image delivery, loading behavior, and image optimization.

But there is another important lesson:

Don't mark everything as high priority.

If everything is "high priority," then the concept loses much of its value.

This Made Me Think About My Own E-commerce Project

At this point, the investigation stopped being about another website.

I started thinking:

"What would I build if I wanted this same kind of architecture?"

My stack is already something like:

Next.js
Prisma
Neon PostgreSQL

So I started designing the architecture around the principles I had learned.

And this is what I came up with.

The Architecture I Want

Instead of building:

Browser
   ↓
REST API
   ↓
Database

for every single page, I can use:

                    ┌──────────────────────┐
                    │      Cloudflare      │
                    │ CDN / Security/Cache │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │       Next.js        │
                    │     App Router       │
                    └──────────┬───────────┘
                               │
             ┌─────────────────┼─────────────────┐
             │                 │                 │
             ▼                 ▼                 ▼
      Server Components   Client Components   Server Actions/
             │                 │               Route Handlers
             │                 │                 │
             ▼                 ▼                 ▼
          Prisma          Cart / UI          Orders / mutations
             │
             ▼
      Neon PostgreSQL

That architecture is much closer to how I now think about a modern e-commerce application.

Product Pages Don't Need to Be Fully Dynamic

This is another big lesson.

Consider:

/products/honey

Does every visitor need a completely different product page?

Usually, no.

The product title is shared.

The description is shared.

The images are shared.

The category is shared.

The public price may be shared.

So a product page can often take advantage of server rendering and caching strategies.

Next.js supports static and dynamic rendering patterns, allowing developers to choose where content needs to be generated dynamically and where it can be reused.

That means I can think about my website in categories:

Public catalog
    ↓
Cache-friendly

Search
    ↓
More dynamic

Cart
    ↓
Client-side state

Checkout
    ↓
Server-controlled

Admin
    ↓
Private / dynamic

This is much more useful than saying:

"Everything should be SSR."

or:

"Everything should be a client component."

Architecture is about choosing the right behavior for each type of data.

The Cart Is Different

A shopping cart is highly interactive.

The user can do:

+
-
remove
update quantity
apply coupon
open cart
close cart

That is a great place for client-side interaction.

So I don't necessarily want every tiny cart interaction to involve a full server round trip.

Something like:

Product page
    ↓
"Add to cart"
    ↓
Client-side cart state
    ↓
Cart UI updates instantly

But there is a very important security boundary.

At checkout:

Client says:

"I want 3 products."

        ↓

Server checks:

- current product price
- stock
- discounts
- user/session
- totals

        ↓

Create order

The client should never be trusted with final pricing logic.

The Most Dangerous Cloudflare Rule

After learning all this, I can imagine the next beginner mistake.

You add Cloudflare.

Everything looks fast.

Then you think:

"Let's cache everything!"

Bad idea.

Imagine:

/cart
/checkout
/account
/admin

These pages can contain personalized or sensitive information.

Caching them carelessly can create serious correctness and security problems.

So a much safer mental model is:

PUBLIC

/products/*
/collections/*
/
/blog/*

↓

Potentially cacheable

while:

PRIVATE

/cart
/checkout
/account/*
/admin/*

should generally be treated very differently.

Cloudflare provides Cache Rules specifically for configuring caching behavior rather than blindly caching everything.

My Final Mental Model

Before this investigation, I thought performance looked like:

Frontend
   ↓
API
   ↓
Database

Now I see a much larger picture:

                         USER
                           │
                           ▼
                    ┌─────────────┐
                    │  Browser    │
                    └──────┬──────┘
                           │
             prefetch / navigation / requests
                           │
                           ▼
                  ┌─────────────────┐
                  │   Cloudflare    │
                  │ CDN / Security  │
                  │     / Cache     │
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │     Next.js     │
                  │   App Router    │
                  └────────┬────────┘
                           │
             ┌─────────────┼─────────────┐
             │             │             │
             ▼             ▼             ▼
        Server          Client       Mutations
       Components     Components      / APIs
             │             │             │
             ▼             │             ▼
          Prisma           │          Server
             │             │          validation
             ▼             │             │
      Neon PostgreSQL      │             ▼
                           │           Order
                           ▼
                         Cart

And around all of that:

Images
   ↓
Next.js Image Optimization

Resources
   ↓
Priority hints / lazy loading

Navigation
   ↓
Prefetching

Public pages
   ↓
Caching / revalidation

Dynamic pages
   ↓
Server rendering

Static assets
   ↓
CDN

What I Actually Learned

The most valuable thing I learned wasn't one specific technology.

It was how to read a website from the outside.

When I see:

200 document

I don't immediately assume the site is static.

When I see:

Server: cloudflare

I don't assume everything is cached.

When I don't see:

/api/products

I don't assume there is no backend data fetching.

When navigation feels instant, I don't assume there is no network activity.

And when I see a fast page, I don't just ask:

"What framework are they using?"

I ask:

"Where is the work happening, when is it happening, and which layer is responsible for making it feel fast?"

That question is much more powerful.

The Bigger Lesson

Modern web performance isn't one trick.

It's a chain of decisions.

Maybe the database query happens on the server.

Maybe the page is statically generated.

Maybe the browser prefetched the next route.

Maybe Cloudflare delivered an asset from the edge.

Maybe Brotli reduced transfer size.

Maybe the hero image was prioritized.

Maybe below-the-fold images were lazy-loaded.

Maybe the browser reused previously fetched resources.

Maybe several of those things happened together.

That's why a site can look like it is doing "almost nothing" in the browser while actually doing a lot of work behind the scenes.

And honestly, that's what made this investigation fun.

I started by asking:

"Where is the API request?"

I ended by asking:

"What is the entire delivery architecture?"

That is a much better question to ask when building fast web applications.

What I'm Taking Into My Next.js Projects

My current checklist is now roughly:

✓ Server-render public catalog pages where appropriate
✓ Keep database access on the server
✓ Use client components only where interaction needs them
✓ Prefetch useful navigation where appropriate
✓ Optimize images
✓ Lazy-load content below the fold
✓ Prioritize critical resources selectively
✓ Use Cloudflare for the right caching layer
✓ Never blindly cache personalized pages
✓ Validate prices/stock on the server
✓ Measure with DevTools instead of guessing

The biggest change isn't in my code.

It's in how I think about performance.

Don't just look for requests. Look for the system behind the requests.

Final Thoughts

This whole thing started with a very simple question:

"Why can't I find the API request?"

But that question led me into:

Server-side rendering
Server Components
Next.js App Router
Prefetching
Client-side navigation
Cloudflare
CDN caching
Cache-Control
Brotli compression
Priority Hints
Lazy loading
Image optimization
Static vs dynamic rendering
Client-side cart architecture
Server-side checkout validation

And that's exactly what I love about web development.

Sometimes you open DevTools looking for one request...

…and end up discovering an entire architecture.

Passion Garage — Where Passion Meets Performance

Muhammad Rabbi — Mon, 13 Jul 2026 00:51:41 +0000

This is a submission for Weekend Challenge: Passion Edition

Update (Post-Deadline): I noticed a critical bug right at submission and pushed a quick fix after the deadline cutoff. The core features and functionality of the project were completed and submitted on time.

Passion Garage — A Cinematic Automotive Experience Powered by Google Gemini

What I Built

For this challenge, I wanted to explore passion through the world of automotive engineering. To millions of enthusiasts, cars are more than transportation—they represent innovation, performance, craftsmanship, and emotion.

To capture that feeling, I built Passion Garage, a cinematic web experience inspired by legendary performance cars. Instead of a traditional landing page, the website takes users on a scroll-driven journey featuring immersive GSAP animations, storytelling, and an AI-powered automotive assistant.

The experience includes:

Cinematic scroll storytelling
Featured performance cars
BMW Story chapter
AI Garage powered by Google Gemini
Smooth GSAP animations
Fully responsive modern UI

The AI Garage acts as an automotive expert, helping users compare cars, understand engine technologies, learn about performance specifications, and receive personalized recommendations.

My goal was to create something that feels less like a website and more like an interactive automotive experience.

Demo

🌐 Live Website

https://passion-garage-ai.vercel.app/

Screenshorts

Code

GitHub Repository

rafiqwe / passion-garage-ai

🚗 Passion Garage

A cinematic automotive experience powered by Google Gemini AI.

Passion Garage is an immersive web experience built for the DEV Weekend Challenge: Passion Edition. Inspired by the passion behind legendary performance cars, the project combines cinematic storytelling, smooth GSAP animations, and an AI-powered automotive assistant to create a unique journey for car enthusiasts.

✨ Features

🎬 Cinematic scroll-driven storytelling
🚘 Featured performance cars
📖 BMW Story experience
🤖 AI Garage powered by Google Gemini
⚡ GSAP & ScrollTrigger animations
📱 Fully responsive design
🌙 Modern dark UI inspired by premium automotive brands
🚀 Built with the latest Next.js App Router

🤖 AI Garage

AI Garage is an intelligent automotive assistant built using Google Gemini.

Users can:

Compare performance cars
Learn about engines and horsepower
Get buying recommendations
Explore automotive technologies
Ask questions about BMW, Porsche, Ferrari, Nissan, Audi, Toyota, Mercedes-Benz, Lamborghini, McLaren, and more

🛠

…

View on GitHub

How I Built It

The project was built using Next.js App Router, TypeScript, and Tailwind CSS for a fast and modern development experience.

The most exciting part was creating the cinematic scroll experience using GSAP and ScrollTrigger. Instead of relying on static sections, each chapter reveals itself through carefully timed animations to create a story-driven experience.

To qualify for the Best Use of Google AI category, I integrated Google Gemini into the AI Garage section. Rather than building a generic chatbot, I designed an automotive assistant that specializes in:

Comparing performance cars
Explaining engine technologies
Recommending vehicles based on user needs
Answering automotive questions
Providing structured, easy-to-read information

The frontend communicates with a Next.js API route, which securely interacts with the Gemini API to generate intelligent automotive responses.

Tech Stack

Next.js
React
TypeScript
Tailwind CSS
GSAP + ScrollTrigger
Google Gemini API
Vercel

Best Use of Google AI

Google Gemini powers the AI Garage, transforming it into an intelligent automotive assistant capable of providing comparisons, recommendations, and educational content about performance vehicles. The AI is integrated as a core feature of the experience rather than an optional add-on.

Thank you for checking out my submission!

I'd love to hear your feedback and suggestions for improving Passion Garage.

AI Can Build Applications, But Can It Debug Them?

Muhammad Rabbi — Sun, 31 May 2026 17:00:17 +0000

AI Can Build Applications, But Can It Debug Them?

We're living in an interesting era.

Today, someone with little to no programming experience can open an AI tool, describe an idea, and generate a working application within minutes. What once required weeks of learning and development can now be done through a conversation.

It's impressive.

But there's a difference between generating an application and understanding how it works.

A Real Experience

Yesterday, one of my friends told me he was building an automation tool using Claude.

At first, everything seemed to be going well. The AI generated the code, the application launched, and most of the features appeared to work.

Then a problem appeared.

The automation started making unexpected clicks and performing actions that weren't intended. Naturally, he asked Claude to fix the issue.

The problem was that he only provided screenshots of the behavior. There were no logs, no debugging information, no code explanations, and no additional context.

Without enough information, Claude started making assumptions about the root cause. It suggested multiple fixes, but none of them solved the actual issue.

In other words, it began hallucinating.

After spending hours going back and forth with AI-generated suggestions, he eventually asked me for help.

The Four-Hour Debugging Session

What looked like a simple issue turned into nearly four hours of debugging.

We inspected the automation flow, reviewed the code, traced event handlers, checked selectors, and analyzed how the application interacted with the target website.

Eventually, we identified the actual causes behind the unexpected behavior and fixed them one by one.

The automation tool finally worked as intended.

The interesting part wasn't the bug itself.

The interesting part was realizing that the biggest challenge wasn't generating the code—it was understanding it.

The Missing Piece

AI is excellent at accelerating development.

It can:

Generate boilerplate code
Create UI components
Write API integrations
Suggest solutions
Explain concepts
Speed up development workflows

But when something breaks, AI isn't always enough.

Debugging requires:

Understanding program flow
Reading logs
Analyzing errors
Identifying root causes
Testing assumptions
Knowing how different parts of a system interact

These skills come from learning software development fundamentals.

AI Is a Multiplier, Not a Replacement

Many people treat AI as a replacement for programming knowledge.

In reality, AI works best as a multiplier.

A developer with strong fundamentals can use AI to become significantly more productive.

Someone without those fundamentals may still build something impressive, but when problems appear, they often struggle to identify what's actually wrong.

The more complex the application becomes, the more important those fundamentals become.

Final Thoughts

AI has changed software development forever.

It has lowered barriers, accelerated learning, and made building applications more accessible than ever before.

But software engineering is more than generating code.

Understanding systems, debugging problems, and making informed technical decisions remain essential skills.

AI can write code for you.

But when the application behaves unexpectedly, understanding why it happened is still a human responsibility.

I Built My Portfolio to Look Like VS Code 👨‍💻

Muhammad Rabbi — Sat, 07 Mar 2026 15:23:03 +0000

Link: Portfolio

Most developer portfolios follow the same pattern:

A hero section
Some project cards
A contact form

Clean? Yes.
Memorable? Not always.

So I decided to try something different.

I built my portfolio to look and feel like VS Code.

Why a VS Code Style Portfolio?

As developers, we spend most of our time inside Visual Studio Code.

It’s the place where ideas turn into code.

So I thought:

Why not make my portfolio feel like a developer's natural environment?

Instead of a traditional website layout, the portfolio mimics the VS Code interface, including:

File explorer navigation
Code-style content sections
Developer-focused UI interactions
A familiar coding environment

The goal was to create something that feels natural for developers visiting the site.

What I Focused On
While building it, I tried to focus on three things:

1. Developer Experience
The interface should feel like a real coding environment, not just a visual copy.

2. Clean UI
Even though it mimics an editor, it still needs to be clear, readable, and responsive.

3. Personality **
Your portfolio should show **how you think as a developer, not just what tools you use.

What I Learned

Building this portfolio taught me a few things:

UI inspiration can come from tools developers already use
Small interactions make a big difference
Portfolios are a great place to experiment with ideas

Final Thought

Your portfolio doesn’t have to follow the same template as everyone else.

Sometimes, trying something different makes it more memorable.

If you're a developer, what kind of portfolio style do you prefer?

Minimal landing page
Interactive experience
Something creative like a dev environment

Curious to hear your thoughts 👇

AuthKit Pro – Simplifying NextAuth Setup in Next.js

Muhammad Rabbi — Sat, 14 Feb 2026 16:40:47 +0000

Setting up authentication in a Next.js project is powerful — but let’s be honest…

It’s repetitive.

Every time we start a new project with NextAuth, we end up writing the same boilerplate:

Provider configuration
Auth config setup
Environment variables
Basic file structure

After doing this multiple times, I thought:

Why not automate the boring part?

So I built authkit-pro — a CLI tool that initializes basic NextAuth setup instantly.

✨ What is authkit-pro?

authkit-pro is a simple CLI tool designed to:

1. Reduce authentication boilerplate
2. Speed up project setup
3. Let developers focus on core features
4. Provide a clean starting structure Instead of manually configuring everything, you just run one command.

⚡ How to Use
Simply run:

npx authkit-pro init

That’s it.

It scaffolds the basic authentication setup so you can move faster.

🎯 Why I Built This
As a developer, I love optimizing workflows.

When you repeatedly write the same setup code, it slows down creativity. I wanted something that:

Saves time
Keeps projects consistent
Makes starting new apps easier

So this is my small contribution to improving the developer experience.

🛠 Current Status

The project is still evolving.
I’m actively improving it and planning to add more features.

If you try it, I would genuinely appreciate your feedback.

💬 Feedback & Contribution
If you’re working with Next.js and authentication:

Give it a try → npx authkit-pro init

Let me know:

What should be improved?
What features would you like to see next?
Any bugs or suggestions?

Let’s build better developer tools together 🚀

I Tried Vibe Coding for the First Time Using Warp — Here’s What I Learned

Muhammad Rabbi — Sat, 24 Jan 2026 13:48:13 +0000

Today, I experimented with vibe coding for the first time using Warp, and honestly… it felt wild.

I didn’t write a single line of code manually.

Instead, I just described:

what I wanted to build
what should happen next
And Warp generated the code for me.

For quick prototyping, this felt incredibly fast and smooth.

The Good Part

Warp did a solid job with:
Generating project structure
Writing boilerplate code
Moving ideas forward quickly

For early-stage development, this can save a lot of time and mental energy.
If your goal is to test an idea fast, vibe coding definitely helps.

The Reality Check
Once I reviewed the generated code properly, I noticed:

Multiple bugs
Logical issues
Edge cases not handled well

The code worked, but it wasn’t production-ready.

This is where developer experience still matters:

Debugging
Refactoring
Understanding what the code is actually doing

AI can write code, but it doesn’t fully understand context, intent, or long-term maintainability.

Current Status of the Project

The site is still under development.

I’m actively:

Fixing bugs
Improving logic
Cleaning up the codebase

Once everything is stable, I’ll share:

What the site does
How it was built
What worked well with vibe coding (and what didn’t)

Key Takeaway

AI-assisted coding is a powerful accelerator, not a replacement for fundamentals.

Tools like Warp are great for:

Rapid experimentation
Reducing repetitive work
Exploring ideas faster

But understanding the code and taking responsibility for quality is still on us as developers.

If you’ve tried vibe coding or AI-first workflows, I’d love to hear your experience 👇

What worked for you, and what didn’t?

Happy building 🚀

React Design Patterns Every Frontend & FullStack Developer Should Know

Muhammad Rabbi — Fri, 09 Jan 2026 15:53:32 +0000

If you’re building modern web applications, React design patterns can completely change how you think about components, reusability, and scalability.

A month ago, I realized something important
I was using React every day, but I wasn’t truly thinking in patterns.

That’s when I discovered an amazing playlist by @atapas.

Why React Design Patterns Matter
React design patterns help you:

Write cleaner and more maintainable code
Avoid prop drilling & unnecessary re-renders
Scale applications without pain
Think like a senior engineer, not just a coder

Patterns are not about complexity —

they’re about clarity and intention.

What You’ll Learn From This Playlist

This playlist breaks down patterns in a practical and beginner-friendly way, including:

Container & Presentational Components
Compound Components
Render Props
Custom Hooks pattern
Controlled vs Uncontrolled Components
Reusability & separation of concerns

Each concept is explained with real-world use cases, not just theory.

Where to Watch 📺
You can find the playlist on:
Devguide : https://devguide-dev.vercel.app/playlist/PLIJrr73KDmRyQVT__uFZvaVfWPdfyMFHC ,
YouTube,

*A Small but Meaningful Moment *

I shared this playlist recently, and Tapas Adhikary himself commented:

“Thank you for sharing and the shoutout. The Devguide looks awesome. 🙌”
That meant a lot to me — and it motivated me to share this with more developers.

Final Thoughts

Whether you’re a frontend developer, backend developer, or moving toward full-stack, understanding React design patterns will level you up.

Don’t just write React.
Design with React.

If you’ve already explored these patterns, I’d love to know:
Which React pattern helped you the most?

*Happy coding *

coding #devguide #fullstack #frontend #developer

A few days ago, I was scrolling through YouTube playlists, thinking..

Muhammad Rabbi — Mon, 08 Sep 2025 04:48:40 +0000

One moment I’m watching a React tutorial… next moment I’m deep into cat videos 🐱😂

That’s when I realized — if DevGuide is about structured learning, then I needed a way to bring that same experience to playlists.

👉 So I built the Playlist Page.
Instead of random chaos, every playlist here is:
✨ Developer-focused
✨ Structured for learning (not distractions)
✨ Easy to browse, just like YouTube but with only dev content

It wasn’t easy.
I had to set up API calls, handle filter logic, deal with loading skeletons, and even fight with layout issues until it felt clean and smooth.

But in the end, the Playlist Page turned into something I’m proud of — a place where developers can binge-watch without losing focus. 🚀

🔗 Try it here: https://devguide-dev.vercel.app/playlists

Question for you:
👉 If you could design your dream developer playlist, what topics would be in it?

WebDevelopment #Frontend #LearningJourney #DevGuide #day100 #devguide #devguide

DEV Community: Muhammad Rabbi

I Thought This E-commerce Site Was Making Zero API Requests. I Was Wrong.

I Thought This E-commerce Site Was Making Zero API Requests. I Was Wrong.

The First Clue: "Where Is the API?"

The Browser Was Already Receiving HTML

"No API Request" Does Not Mean "No Data Request"

Browser → API

Browser → Page → Server → DB

Then I Looked at the Network Headers

Cloudflare ≠ Everything Is Cached

Then Why Was There max-age=600?

The Page Was Loading A Lot More Than Just HTML

Then I Discovered the Difference Between HTML and Navigation

Possibility One: Full Page Request

Possibility Two: Prefetching

That Was My "Aha!" Moment

Then I Found Priority Hints

Priority and Lazy Loading Are Not the Same Thing

Lazy loading asks:

Priority asks:

This Made Me Think About My Own E-commerce Project

The Architecture I Want

Product Pages Don't Need to Be Fully Dynamic

The Cart Is Different

The Most Dangerous Cloudflare Rule

My Final Mental Model

What I Actually Learned

The Bigger Lesson

What I'm Taking Into My Next.js Projects

Final Thoughts

Further Reading

Passion Garage — Where Passion Meets Performance

Passion Garage — A Cinematic Automotive Experience Powered by Google Gemini

What I Built

Demo

Code

rafiqwe / passion-garage-ai

🚗 Passion Garage

✨ Features

🤖 AI Garage

🛠

How I Built It

Tech Stack

AI Can Build Applications, But Can It Debug Them?

I Built My Portfolio to Look Like VS Code 👨‍💻

AuthKit Pro – Simplifying NextAuth Setup in Next.js

I Tried Vibe Coding for the First Time Using Warp — Here’s What I Learned

React Design Patterns Every Frontend & FullStack Developer Should Know

coding #devguide #fullstack #frontend #developer

A few days ago, I was scrolling through YouTube playlists, thinking..

WebDevelopment #Frontend #LearningJourney #DevGuide #day100 #devguide #devguide

Then Why Was There `max-age=600`?