Coder Legion - Recent posts tagged express

Stop Inventing Custom API Errors: A Guide to RFC 7807 Problem Details

Mon, 26 Oct 2026 17:41:23 +0000

RFC 7807 Problem Details is an official technical specification that defines a standard JSON format for describing errors returned by HTTP web APIs. Instead of having every software engineer create their own custom fields like message, err_code, or reason, this standard establishes predictable key names such as type, title, status, detail, and instance. This gives both computer programs and human developers a uniform way to understand exactly what went wrong during an API request.

The Everyday Analogy: Car Diagnostic Reports

Imagine taking your car to a mechanic when the check engine light comes on.

Option A: The mechanic hands you a piece of paper that simply says: "Car is broken. Cost: $300."

Option B: The mechanic hands you a standardized vehicle diagnostic report that lists the exact sensor code (e.g., P0300), a short title ("Random Cylinder Misfire"), the severity level, specific details ("Cylinder 3 failed 14 times in the past 10 miles"), and a reference link to the manufacturer's repair guide.

Option A leaves you guessing and forces you to ask ten follow-up questions. Option B gives you instant, structured clarity. RFC 7807 acts as that standardized diagnostic report for your web applications.

Why RFC 7807 Matters for Engineers

In modern software engineering, web applications are built by connecting multiple services together. Front-end user interfaces (like React apps) communicate with back-end servers running Express.js, which in turn communicate with databases or external payment systems.

When something fails—such as an invalid credit card or an out-of-stock product—the back-end server must notify the front-end application. Without a standard like RFC 7807, team A might structure errors as { "error": "Invalid payload" }, while team B uses { "statusCode": 400, "description": "Bad input" }.

This inconsistency causes real operational pain:

Fragile UI Code: Front-end developers must write endless conditional if/else checks to parse different error formats from different endpoints.
Wasted Debugging Hours: Software engineers spend extra time reading through server logs trying to figure out what a vague error message actually means.
Poor User Experience: Applications fail silently or show generic "An unknown error occurred" popups because the front-end couldn't parse the unexpected error structure.

By enforcing RFC 7807, teams agree on a single contract. Front-end apps can use one central error-handling mechanism to extract the exact field that failed and display a meaningful message to the user.

Code Example: Express.js Error Handler

Here is how you can implement an RFC 7807 compliant error handler in a Node.js and Express server. The custom HTTP content type for this standard is application/problem+json.

const express = require('express');
const app = express();

app.use(express.json());

// Route that triggers a validation error
app.post('/api/users', (req, res, next) => {
  const { email } = req.body;
  if (!email) {
    const error = new Error('Email field is required.');
    error.status = 400;
    error.type = 'https://api.example.com/errors/missing-field';
    error.title = 'Invalid Request Payload';
    error.instance = '/api/users';
    return next(error);
  }
  res.status(201).json({ message: 'User created' });
});

// Central RFC 7807 Error Handling Middleware
app.use((err, req, res, next) => {
  const status = err.status || 500;
  
  const problemDetails = {
    type: err.type || 'https://api.example.com/errors/internal-error',
    title: err.title || 'Internal Server Error',
    status: status,
    detail: err.message || 'An unexpected error occurred on the server.',
    instance: err.instance || req.originalUrl
  };

  // Set the standard RFC 7807 header
  res.setHeader('Content-Type', 'application/problem+json');
  res.status(status).json(problemDetails);
});

app.listen(3000, () => console.log('Server running on port 3000'));

Key Takeaway

RFC 7807 transforms unpredictable API errors into predictable, structured data that both machines and humans can process seamlessly. Adopting this standard eliminates entire classes of error-handling bugs, simplifies frontend integration, and establishes clear debugging contracts across your entire software ecosystem.

Enjoyed this breakdown? Support my open-source work on Buy Me a Coffee or explore react-hook-lab!

Originally published on my blog. You can read the alternative breakdown here.

Stop Hardcoding Secrets: Master Environment Variables and Dotenv in Node.js

Sat, 17 Oct 2026 08:03:00 +0000

Stop Hardcoding Secrets: Master Environment Variables and Dotenv in Node.js

When building modern web applications, keeping sensitive information secure is just as critical as writing functional code. One of the most fundamental practices every developer must learn is using environment variables and dotenv configuration.

What Are Environment Variables and Dotenv Configuration?

Environment variables are dynamic key-value pairs stored at the operating system or runtime level outside of an application's codebase. In Node.js development, dotenv configuration refers to utilizing a lightweight library called dotenv that automatically loads settings from a plain .env file into Node's runtime environment (process.env). This mechanism allows developers to customize application behavior and supply secret credentials without modifying source code files.

A Real-World Analogy: The Wallet Index Card

Imagine you own a custom leather wallet. Instead of permanently embroidering your house address, garage passcode, and emergency contact numbers onto the outer leather where every passerby can read them, you write those sensitive details on a small index card and slide it into an interior pocket.

When you move to a new apartment or change your passcode, you do not buy a brand-new wallet or destroy the leather stitching. You simply pull out the old index card and slide in an updated one. In this analogy, your wallet is your core application codebase, while the index card inside the pocket acts as your local .env file holding temporary, site-specific configuration details.

Why Environment Variables Matter Every Single Day

In professional software engineering, committing raw passwords, secret encryption keys, or API tokens directly into a Git repository is a dangerous vulnerability. Automated web scraping bots constantly crawl public code repositories like GitHub, scanning for exposed database passwords or cloud provider credentials within seconds of a commit. Exposing these keys can lead to compromised database instances, stolen customer data, or massive financial liability from unauthorized cloud usage.

Furthermore, modern applications run across multiple environments throughout their lifecycle, including local development machines, staging servers for testing, and live production servers handling real user traffic. Environment variables allow engineers to deploy the exact same application code across all these distinct targets. The application simply reads its configuration from whatever local environment variables exist on that specific host server.

Code Example: Configuring Express with Dotenv

Below is a standard Node.js and Express server setup using the dotenv package to securely access server configuration values and third-party API credentials.

// Step 1: Import dependencies
// Ensure you have installed express and dotenv via npm: npm install express dotenv
require('dotenv').config();
const express = require('express');

const app = express();

// Step 2: Read configuration values from process.env
const PORT = process.env.PORT || 3000;
const API_KEY = process.env.PAYMENT_GATEWAY_KEY;
const DATABASE_URL = process.env.DATABASE_URL;

// Step 3: Define an Express route utilizing the loaded variables
app.get('/api/status', (req, res) => {
  if (!API_KEY) {
    return res.status(500).json({ error: 'Missing critical API configuration.' });
  }
  
  res.json({
    status: 'Server is running securely',
    connectedDatabase: DATABASE_URL ? 'Connected' : 'Not Configured',
    environment: process.env.NODE_ENV || 'development'
  });
});

// Step 4: Start the server using the dynamic PORT
app.listen(PORT, () => {
  console.log(`Server listening on port ${PORT}`);
});

Along with this JavaScript file, you create a file named .env in the root folder of your project:

PORT=5000
NODE_ENV=development
DATABASE_URL=mysql://user:password@localhost:3306/dev_db
PAYMENT_GATEWAY_KEY=secret_live_key_987654321

Crucially, you must add .env to your project's .gitignore file so it is never tracked by version control or pushed to remote repositories.

Key Takeaway

Decoupling application code from environment configuration is a foundational pillar of modern, secure software architecture. By adopting environment variables and dotenv configuration early in your development pipeline, you shield your systems from catastrophic credential leaks and build resilient applications ready to run anywhere without friction.

Enjoyed this breakdown? Support my open-source work on Buy Me a Coffee or explore react-hook-lab!

Originally published on my blog. You can read the alternative breakdown here.

Why Express Applications Become Difficult to Secure at Scale

Thu, 11 Jun 2026 09:14:39 +0000

Express has earned its place as one of the most influential web frameworks in the Node.js ecosystem. Its simplicity, flexibility, and minimal learning curve have enabled countless startups and enterprises to build production-ready applications quickly. But as applications grow, teams often discover an uncomfortable reality: securing an Express application at scale becomes increasingly difficult. This is not because Express is inherently insecure. In fact, Express intentionally stays minimal and gives developers total freedom to design systems however they choose. The real challenge is that security becomes a distributed responsibility—scattered across custom middleware, third-party packages, configuration files, team conventions, and individual developer discipline. As a system scales, this fragmented model inevitably starts to show its architectural limitations.

The Security Complexity Problem

A small Express application might begin with a few clean routes and a handful of dependencies:

app.get("/users", (req, res) => {
    res.json(users);
});

At this stage, everything feels manageable. Months later, however, the application evolves to meet production requirements, adding:

Authentication and Authorization logic
Strict input validation and sanitization
Rate limiting and DDoS protection
Complex CORS and CSRF configurations
Session management and logging utilities
Reverse proxy integrations (Nginx, Cloudflare, etc.) Suddenly, every single request must travel through a dense, sequential chain of middleware before even reaching the core business logic:

app.use(cors());
app.use(helmet());
app.use(rateLimiter());
app.use(authMiddleware());
app.use(validationMiddleware());
app.use(customSecurityChecks());

While nothing is inherently wrong with this middleware-driven approach, security is now distributed across multiple independent layers. This makes it incredibly difficult to reason about the overall security posture of the application. A single missing middleware registration or an incorrect execution order can silently create a critical vulnerability, accidentally allowing a route to bypass a vital protection layer.

When Security Relies on Team Convention

One of the most common pitfalls in large Express codebases is that security becomes convention-based rather than systemic. Engineering teams often rely on internal guidelines and code review checklists:

Always validate and sanitize inputs.
Always apply authentication guards to new routers.
Always implement specific security headers. The keyword here is always. Security controls that depend entirely on human memory and rigorous discipline are inherently vulnerable to human error. As engineering teams grow and release cycles accelerate, enforcing these conventions consistently across dozens of files becomes nearly impossible. Express’s highly flexible architecture doesn't cause this problem, but its complete lack of guardrails tends to expose it more clearly than any other framework.

The Dependency Explosion

Another challenge emerges from the growing ecosystem of security-related third-party packages. Because Express provides no native security features, a typical production-grade application must pull in a vast array of dependencies: helmet, express-rate-limit, express-validator, cookie-parser, passport, and various session management libraries. Every single one of these external dependencies introduces:

Additional maintenance overhead: Teams must constantly monitor, audit, and patch dependencies.
Supply-chain vulnerabilities: A compromise in a deeply nested sub-dependency can expose the entire global runtime.
Configuration complexity: Managing version compatibility and overlapping security assumptions across independently maintained packages becomes a shifting target. Security ceases to be a unified, cohesive system. Instead, it becomes an ecosystem of fragmented components where a breaking change in one package can silently disrupt security assumptions throughout the entire application.

The Middleware Visibility Problem

While middleware chains are exceptionally powerful, they can easily mask security-critical behavior. Consider an endpoint protected by several layers:

router.post(
    "/admin/users",
    authenticate,
    authorize,
    validate,
    createUser
);

At first glance, this declaration looks perfectly secure. However, the actual security guarantees are implicitly dependent on external factors: the exact execution order of the chain, the granular implementation details of each handler, how unhandled errors are passed down, and route registration consistency across separate router files. Understanding the true security model requires tracing request execution paths across multiple directories. As the codebase grows, this lack of centralized visibility drastically increases the probability of structural oversights.

Reactive vs. Proactive Architecture

In many development pipelines, applications are built with functionality as the primary metric. Security features arrive progressively: The result of this workflow is a security model layered on top of an existing architecture, rather than one integrated into the foundation itself. This fosters a inherently reactive security culture. Engineering teams spend valuable time hunting for missing protections, auditing endpoints, and patching gaps, instead of relying on an infrastructure that guarantees safety by default.

The True Cost of Human Error

Most devastating production security incidents are not caused by advanced attackers utilizing revolutionary zero-day exploits. They originate from simple, everyday mistakes made under tight deadlines:

An unprotected endpoint forgotten during a major refactor.
A missing validation rule leading to a prototype pollution or NoSQL injection.
An exposed environment variable leaked via an accidental memory dump or supply-chain attack.
A route that accidentally bypasses the authentication middleware due to a typo in the router configuration. As a system scales, the probability of these minor oversights reaching production increases exponentially. The architectural question shifts from "Can developers make mistakes?" to "How much structural damage can a single mistake cause?" Modern security architecture must focus on reducing the impact radius of inevitable human error.

The Rise of Secure-by-Default Framework Design

Faced with these scaling issues, the backend engineering community has begun questioning whether core security should heavily rely on developer discipline and middleware configuration. This has given rise to an alternative architectural philosophy: Security must be embedded directly into the framework core. Instead of requiring developers to remember to import and configure every single protection layer for every new project, the runtime infrastructure provides sensible, strict security guarantees out of the box. This mirrors the principles used in cryptographic and defense-grade hardware design: safe defaults drastically minimize the attack surface before any custom application code even executes.

Shifting the Paradigm: The XyPriss Approach

This vision is precisely what drives modern, secure-by-default runtime environments and frameworks like XyPriss. Rather than treating security as an optional collection of external middleware, XyPriss moves critical protection layers straight into the framework core. By utilizing a hardened infrastructure, the runtime natively handles concerns that traditionally required separate packages and meticulous setup:

Native Request Normalization & Path Traversal Protection: Preventing directory traversal and injection attempts at the routing level before they hit user code.
Anti-ReDoS Mechanisms: Protecting the application from Regular Expression Denial of Service attacks natively.
Protected Environment Handling: Isolating sensitive variables and preventing global scope leaks (like raw process.env exfiltration) via secure internal system gateways.
Zero-Trust Module Isolation: Ensuring that third-party plugins and untrusted code cannot inherit root-level privileges or inspect sensitive memory states by default. The objective here is not to eliminate developer responsibility or restrict architectural freedom. The objective is to eliminate repetitive, high-stakes security decisions, ensuring that a simple human oversight cannot compromise the entire production ecosystem.

Conclusion

Express remains an exceptional, lightweight tool that powers a massive portion of the modern web. However, when scaling backend applications, complexity is the ultimate enemy of security. The bottleneck is rarely the framework itself; it is the management of an ever-expanding web of middleware, configurations, third-party packages, and team conventions. As backend systems become more complex and hostile, the industry is shifting toward architectures where security is not merely an administrative layer added post-deployment, but an immutable part of the framework's foundation. Because at scale, the safest security control is the one developers never have to remember to enable.

XyPriss: Rethinking Core Performance and Zero-Trust Architecture in Modern Backends

Wed, 03 Jun 2026 12:01:18 +0000

After two years of intensive development and architectural refinement, XyPriss has officially reached full maturity. With the release of the v9.10.16++ stable branch, the framework is now 100% production-ready.

We designed XyPriss from the ground up as a secure-by-default backend framework, powered by native internals and engineered specifically to sustain heavy, production-grade systems.

The goal was never to build "just another framework". The goal was to solve critical infrastructure bottlenecks.

Core Architectural Pillars

XyPriss shifts the paradigm of modern backend development through four key principles:

Zero-Trust Security: Hardened by default. Security protocols and safe configurations are baked into the core, eliminating critical vulnerabilities before the first line of business logic is even written.
Native Performance: Driven by a high-performance native engine designed for low-level execution speed, minimal memory overhead, and extreme portability.
Modular by Design: A highly flexible architecture that lets you scale components independently without introducing technical debt or breaking monolithic dependencies.
Production Reliability: Rigorously tested to ensure operational stability under high-concurrency production workloads.

Battle-Tested and Growing

What started as an ambitious technical challenge two years ago has evolved into a stable, powerful ecosystem. With the stability achieved in the current v9.10.16++ release cycle, XyPriss is ready for deployment in mission-critical environments.

Whether you are optimizing transaction pipelines, building high-throughput APIs, or auditing system security, we invite you to explore what we have built.

Links and Resources

Documentation: xypriss.nehonix.com
GitHub Repository: Nehonix-Team/XyPriss

If you appreciate the work and engineering behind this framework, please take a second to star (like) our repository on GitHub. It costs nothing but it deeply encourages the team and gives the project the visibility it needs to grow.

Feel free to explore the repository, test the framework, or leave your technical feedback in the comments below. @typescripttutorials

How I built a Social Recipe Extractor that turns short-form video links into structured recipes

Wed, 13 May 2026 15:44:38 +0000

I recently built a feature for https://recipe-finder.org that takes a TikTok, Instagram, or YouTube cooking link and turns it into a structured recipe.

The goal was simple: recipe inspiration lives on social platforms, but the actual cooking steps are usually buried inside captions, spoken instructions, or fast cuts. I wanted a workflow where a user pastes a link and gets back something usable: a recipe title, ingredient list, instructions, and a cleaner format for the rest of the product.

The Flow

The core user journey is straightforward:

The user pastes a supported social video URL.
The frontend sends that URL to a protected backend endpoint.
The backend normalizes the link, fetches available source metadata and text, and runs an extraction pass.
The result is converted into a structured recipe object.
The app returns a clean recipe view, keeps recent imports in history, and can reuse cached results for repeated links.

What makes this interesting isn't just the form input—it's the cleanup step between raw social content and something a user can actually cook from.

Here is a look under the hood at how it's built using Vue 3, TypeScript, and Node.js/Express.

1. Frontend Entry Point

The feature lives behind authentication and opens as a dedicated page in the app. The page itself stays simple and hands the main workflow to a dedicated Social Recipe Extractor component.

To keep the UI predictable and sleek (opting for a dark mode aesthetic with vibrant orange accents for active states), the component manages four main states:

The pasted social link
Loading and error feedback
The extracted recipe result
Recent import history and usage state

This keeps the input on the left, the result on the right, and prior imports available without mixing feature logic across multiple pages.

2. Backend-Owned Extraction Flow

The frontend does not parse social content directly. Instead, it sends the link to a backend route dedicated to social recipe extraction.

That backend layer is responsible for:

Validating the request
Normalizing the URL into a canonical form
Checking whether a usable cached import already exists
Fetching source metadata and extracted text from the target platform
Transforming unstructured content into a recipe-shaped response
Returning a stable payload the frontend can render safely

This is the right ownership boundary because platform parsing, rate control, caching, and extraction quality all belong on the server. The frontend only ever deals with a typed response.

3. Structured Extraction

The most important design choice was ensuring the pipeline doesn't stop at "grab some text from the page." It pushes the output into a highly structured shape:

Recipe title
Prep time
Ingredients
Instructions
Normalized ingredients
Source metadata (platform, thumbnail, title, author)

This matters because a structured result is much easier to reuse than a raw text dump. It allows the data to power future features without rebuilding the extraction logic each time.

4. Normalization and Cleanup

Social content is inherently messy. Titles contain hashtags, descriptions are noisy, and ingredient mentions are often incomplete or informal.

The implementation handles this by cleaning and normalizing content before and after extraction:

URL normalization ensures equivalent links map to the same import record.
Title cleanup prevents social-platform suffixes and noisy text from leaking into the recipe title.
Whitespace and escaped-text cleanup is applied before extraction.
Ingredient normalization makes the output more consistent for downstream product use.

This cleanup layer is where a lot of the actual product quality is realized.

5. Caching and History

Two product decisions make the feature feel significantly faster and more useful:

Cached imports prevent unnecessary repeat processing for the same normalized link.
Import history gives users a lightweight library of recently extracted recipes.

The extractor isn't just a one-shot tool; it becomes a reusable workflow inside the product.

6. Premium-Friendly Usage Model

Finally, the feature returns usage information along with the extraction result. That allows the UI to immediately show whether the user can continue importing, how much of their current allowance is used, and when an upgrade prompt should appear.

This is a much better user experience than hard-failing late in the flow, as the interface can explain the state before the user hits a dead end.

Wrapping Up

This is one of those features where the product value comes purely from reducing friction. People already save recipes from social media. The real improvement is turning that saved link into something searchable, reusable, and easier to cook from.

If I were extending it further, the next logical step would be connecting the extracted, structured recipe directly into grocery list generation, smart meal planning, and nutrition analysis.

From Modal to Full Page: How We Refactored a Vue 3 Recipe Detail View (and Made It Faster)

Sun, 03 May 2026 19:43:07 +0000

From Modal to Full Page: How We Refactored a Vue 3 Recipe Detail View (and Made It Faster)

Demo:
https://recipe-finder.org/recipe/644488-german-rhubarb-cake-with-meringue

One of the longest-lived technical decisions in our recipe finder app was showing recipe details inside a dialog modal. It worked — until it didn't. Here's how we migrated from a bloated modal to a clean, SEO-friendly full page, what we cut along the way, and what the app looks like now.

The Old Approach: Everything in a Modal

The original setup opened a <v-dialog> when a user clicked a recipe card. The modal held the entire recipe detail UI: ingredients, nutrition, videos, AI chef, grocery import, recipe scaler — all of it. The logic for opening it, fetching the recipe, and handling deep-link slugs lived inside HomePage.vue.

<!-- Old: HomePage.vue controlled everything -->
<RecipeDetailsModal
  :is-open="isRecipeModalOpen"
  :recipe="selectedRecipeDetails"
  :loading="loadingRecipeDetails"
  @close="closeModal"
/>

The problem was that HomePage.vue had become a god component. It managed:

The search form and results
Cuisine carousel
Recipe of the day
Recent recipes
And the modal open/close state, slug parsing, and detail fetch

On top of that, because everything was in a modal, the URL never changed. Users couldn't share a link to a specific recipe, Google couldn't index the content, and the Back button did nothing useful.

The New Approach: Dedicated Route + Page

We created /recipe/:slug as a proper route and moved the recipe detail logic into a standalone RecipeDetailPage.vue.

// router/index.ts
{
  path: '/recipe/:slug',
  component: () => import('@/pages/RecipeDetailPage.vue'),
  meta: { title: 'Recipe' }
}

Slugs are derived from the recipe ID and title, making them human-readable and stable:

// utils/index.ts
export const toRecipeSlug = (id: number, title: string): string => {
  const slug = title
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/(^-|-$)/g, '');
  return `${id}-${slug}`;
};

export const extractRecipeIdFromSlug = (slug: string): number | null => {
  const id = parseInt(slug.split('-')[0]);
  return isNaN(id) ? null : id;
};

What We Cut From HomePage.vue

Once the page was independent, we stripped HomePage.vue of everything modal-related. Gone:

isRecipeModalOpen ref
selectedRecipeDetails and loadingRecipeDetails state
The openRecipeModal / closeModal handlers
The slug-watching watch that re-fetched on URL change
The <RecipeDetailsModal> import and component registration
The handleOpenRecipeDetails function passed down through three component layers

The result was HomePage.vue shrinking by roughly 40% in script size. It now does one thing: show the search form and results.

What the Page Layout Looks Like

The page uses a standard Vuetify two-column grid — main content on the left, sticky sidebar on the right (desktop only). On mobile, the sidebar collapses and the tools surface inline.

<v-row>
  <!-- Left: main content -->
  <v-col cols="12" lg="8">
    <v-img :src="recipe.image" cover rounded="lg" class="mb-6" />
    <h1 class="recipe-title">{{ recipe.title }}</h1>
    <!-- chips, rating, action buttons, summary, ingredients, instructions, nutrition -->
  </v-col>

  <!-- Right: sticky sidebar (desktop only) -->
  <v-col cols="12" lg="4" class="d-none d-lg-flex flex-column">
    <div class="sidebar-sticky">
      <!-- Recipe Tools card -->
      <!-- AI Cooking Chef card -->
      <!-- Nutrition Snapshot card -->
    </div>
  </v-col>
</v-row>

The sidebar cards use a glass morphism style that matches the rest of the app:

.glass-card {
  border: 1px solid rgba(255, 255, 255, 0.1);
  background:
    radial-gradient(circle at top right, rgba(255, 163, 92, 0.08), transparent 40%),
    linear-gradient(165deg, rgba(255, 255, 255, 0.07), rgba(255, 255, 255, 0.02));
  border-radius: 16px !important;
}

Mobile: Icon Buttons + Bottom Sheet AI

On mobile, the page can't show a sidebar. We solved this in two ways:

Action buttons become icon-only on small screens, matching how the modal used to look:

<!-- Mobile: icon-only -->
<div class="d-flex d-sm-none gap-2 mb-6 align-center">
  <v-btn icon variant="tonal" size="small" @click.stop="handleToggleFavoriteRecipe">
    <v-icon>{{ isFavorited ? 'mdi-heart' : 'mdi-heart-outline' }}</v-icon>
  </v-btn>
  <v-btn icon variant="tonal" size="small" @click="shareRecipe">
    <v-icon>{{ isCopied ? 'mdi-check' : 'mdi-share-variant' }}</v-icon>
  </v-btn>
  <v-btn icon variant="tonal" size="small" @click="printRecipe">
    <v-icon>mdi-printer</v-icon>
  </v-btn>
</div>

<!-- Desktop: text buttons -->
<div class="d-none d-sm-flex flex-wrap gap-2 mb-6">
  <v-btn prepend-icon="mdi-heart-outline" variant="tonal" class="page-action-btn">
    Add to Favorites
  </v-btn>
  <!-- ... -->
</div>

The AI chef becomes a bottom sheet triggered by a text button inline with the ingredient tools (no floating action button cluttering the screen):

<!-- Ingredient row: Scale / Analyze / Grocery / AI Chef -->
<v-btn color="primary" variant="text" size="small"
  prepend-icon="mdi-robot-excited" @click="showAiSheet = true">
  AI Chef
</v-btn>

<v-bottom-sheet v-model="showAiSheet">
  <!-- full AI interface -->
</v-bottom-sheet>

SEO + Meta Tags

Since the content is now on a real URL, we inject <title> and Open Graph meta tags dynamically on load:

const injectMetaTags = (title: string, summary: string, imageUrl: string) => {
  const pageTitle = `${title} | Recipe Finder`;
  document.title = pageTitle;

  const setMeta = (selector: string, attr: string, value: string) => {
    document.querySelector(selector)?.setAttribute(attr, value);
  };

  setMeta("meta[property='og:title']", 'content', pageTitle);
  setMeta("meta[name='twitter:title']", 'content', pageTitle);

  if (summary) {
    const clean = summary.replace(/<[^>]*>/g, '').trim().slice(0, 155);
    setMeta("meta[name='description']", 'content', clean);
    setMeta("meta[property='og:description']", 'content', clean);
  }

  if (imageUrl) {
    setMeta("meta[property='og:image']", 'content', imageUrl);
  }
};

This is called inside a watch on the recipe computed ref, so it fires on both initial load and when navigating between similar recipes.

Async Components Throughout

Every non-critical UI piece is lazy-loaded:

const ImportToGroceryList = defineAsyncComponent(
  () => import('@/components/ImportToGroceryList.vue')
);
const PremiumUpgradeDialog = defineAsyncComponent(
  () => import('@/components/PremiumUpgradeDialog.vue')
);
const RecipeScaler = defineAsyncComponent(
  () => import('@/components/RecipeScaler.vue')
);
const RecipeEmbedWatermark = defineAsyncComponent(
  () => import('@/components/RecipeEmbedWatermark.vue')
);

The main recipe content renders immediately. The grocery dialog, scaler, embed widget, and upgrade dialog only load if the user actually interacts with them.

Auth Guard on Grocery Import

One regression we caught: clicking "Send to Grocery List" while logged out was calling getAccessTokenSilently() and throwing an Auth0 missing refresh token error. Fixed by checking auth state before opening the dialog:

const onDialogToggle = (open: boolean) => {
  if (open) {
    if (!isAuthenticated.value) {
      dialogOpen.value = false;
      loginWithRedirect();
      return;
    }
    loadGroceryLists();
  }
};

The Result

HomePage.vue Script Size: Reduced from ~650 lines to ~390 lines

Recipe URL: Now fully shareable

Google Indexing: Now fully indexable

Mobile Layout: Upgraded from a fullscreen modal to a native page with a bottom sheet

Auth Crash on Grocery: Fixed

AI on Mobile: Moved from a floating button to an inline trigger

The modal still exists for the recipe list view (quick-peek without leaving the page), but the canonical experience is now a proper page. The code is cleaner, the app is faster to load, and every recipe finally has a real URL.

Built with Vue 3, Vuetify 3, TypeScript, and Tailwind CSS. Auth via Auth0.

Built a Laravel-Inspired Framework in Node.js (Here’s Why) - NetPress

Mon, 27 Apr 2026 14:30:01 +0000

For years, I’ve been working with Laravel.

It gave me something most Node.js ecosystems don’t:
structure, clarity, and speed of development.

But every time I switched to Node.js, I felt like I was rebuilding the same things:

routing structure
middleware flow
validation
auth patterns
project organization

Everything felt… fragmented.

So I decided to build my own solution.

The Problem

Node.js is powerful, but:

too many choices
no clear “standard” architecture
a lot of boilerplate
every project looks different

Compare that to Laravel:

consistent structure
batteries included
clean developer experience

That’s what I wanted in Node.

The Idea

Build a framework that feels like Laravel…
but runs on Node.js.

That’s how Netpress started.

What I Focused On

Instead of building “just another framework”, I focused on:

Predictable Structure

Every project follows a clear pattern:

Controllers
Middleware
Services
Models

No chaos. No guessing.

Clean Routing

Grouping, middleware, prefixes… just like Laravel:

router.group(authMiddleware, (router) => {
  router.get('/me', meHandler);
});

Middleware Pipeline

Simple and powerful request flow:

auth
rate limiting
logging

Rendering Support

You can use:

Vue
React

Server-driven or hybrid apps without overcomplication.

Developer Experience

Commands, structure, and conventions that make you move fast:

generate app
setup rendering
run migrations
seed data
Why Not Just Use Express?

You can.

But then you’ll rebuild:

structure
conventions
patterns
architecture decisions

Again… and again.

Netpress tries to remove that friction.

A Real Example

Instead of wiring everything manually:

app.use(authMiddleware);
app.get('/me', handler);

You get a structured flow:

router.group(authMiddleware, (router) => {
  router.get('/me', meHandler);
});

What I Learned

Building this taught me:

developers don’t just need tools, they need opinionated structure
consistency beats flexibility in most real-world apps
good DX is underrated

Here’s the docs:
https://admicaa.github.io/netpress-docs/

Would love to hear your thoughts.

Error [err_http_headers_sent]: cannot set headers after they are sent to the client

Mon, 30 Mar 2026 04:06:22 +0000

**Before you dive into this article...**
Check out our vibrant new community at CoderLegion.com!
Share your knowledge, connect with like-minded developers, and grow together.
Click here to join now!

Problem :
I am very new to the Node.js and I am having few issues. I am using the Node.js 4.10 and Express 2.4.3. While trying to execute my code I am receiving the below error : Error: Can't render headers after they are sent to the client.

at ServerResponse. (http.js:580:12)
at ServerResponse._renderHeaders (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect/lib/patch.js:70:30)
at ServerResponse.writeHead (http.js:830:30)
at /home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect-auth/lib/auth.strategies/facebook.js:30:20
at /home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect-auth/lib/index.js:120:20
at next (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect-auth/lib/strategyExecutor.js:50:40)
at [object Object].pass (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect-auth/lib/authExecutionScope.js:29:6)
at [object Object].halt (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect-auth/lib/authExecutionScope.js:35:9)
at [object Object].redirect (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect-auth/lib/authExecutionScope.js:20:10)
at [object Object]. (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect-auth/lib/auth.strategies/facebook.js:80:21)
Error: Can't set headers after they are sent.
at ServerResponse. (http.js:540:22)
at ServerResponse.setHeader (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect/lib/patch.js:60:30)
at next (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect/lib/http.js:170:23)
at next (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect/lib/http.js:201:15)
at next (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect/lib/http.js:170:30)
at param (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect/lib/middleware/router.js:195:17)
at pass (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect/lib/middleware/router.js:202:16)
at Object.router [as handle] (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect/lib/middleware/router.js:209:10)
at next (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect/lib/http.js:204:20)
at Object.auth [as handle] (/home/eugene/public_html/all_things_node/projects/fb2/node_modules/connect-auth/lib/index.js:156:9)
Error: Can't set headers after they are sent.
.
.
.

My code as below :

var realfbId= "XXX";
var realfbSecret= "XXXXXX";
var realfbCallbackAddress= "http://127.0.0.1:8888/auth/facebook_callback"
var realcookieSecret = "node"; //please enter a random hash for security
var realexpress= require('realexpress');
var realauth = require('connect-auth')
var realapp = realexpress.createServer();
realapp.configure(function(){

realapp.use(realexpress.bodyParser());
realapp.use(realexpress.methodOverride());
realapp.use(realexpress.cookieParser());
realapp.use(realexpress.session({secret: cookieSecret}));
realapp.use(realauth([
    realauth.Facebook({
        appId : realfbId,
       appSecret: realfbSecret,
        callback: realfbCallbackAddress,
        scope: 'offline_access,email,user_about_me,user_activities,manage_pages,publish_stream',
        failedUri: '/noauth'
    })
]));

realapp.use(realapp.router);
});
.
.
.

Solution :
If you are using the callback functions then use the return after the err block. This is one of the most frequent scenarios in which this error can happen.

realuserModel.createUser(data, function(realerr, realdata) {

if(realerr) {

  res.status = 422

  res.json(realerr)

  return // without this return the error can happen.

}

return res.json(realdata)

})
I had Tested it on Node version v10.16.0 and express 4.16.4

Another Solution:
The res object in Express is a subclass of Node.js's http.ServerResponse (read the http.js source). You are allowed to call res.setHeader(name, value) as often as you want until you call res.writeHead(statusCode). After writeHead, the headers are baked in and you can only call res.write(data), and finally res.end(data).

The error "Error: Can't set headers after they are sent." means that you're already in the Body or Finished state, but some function tried to set a header or statusCode. When you see this error, try to look for anything that tries to send a header after some of the body has already been written. For example, look for callbacks that are accidentally called twice, or any error that happens after the body is sent.

In your case, you called res.redirect(), which caused the response to become Finished. Then your code threw an error (res.req is null). and since the error happened within your actual function(req, res, next) (not within a callback), Connect was able to catch it and then tried to send a 500 error page. But since the headers were already sent, Node.js's setHeader threw the error that you saw.

Good Middleware
Code:

// middleware that does not modify the response body
var doesNotModifyBody = function(request, response, next) {
request.params = {

a: "b"

};
// calls next because it hasn't modified the header
next();
};

// middleware that modify the response body
var doesModifyBody = function(request, response, next) {
response.setHeader("Content-Type", "text/html");
response.write("

Hello World

");
response.end();
// doesn't call next()
};

app.use(doesNotModifyBody);
app.use(doesModifyBody);

Problematic Middleware

var problemMiddleware = function(request, response, next) {
response.setHeader("Content-Type", "text/html");
response.write("

Hello World

");
next();
};
The problematic middleware sets the response header without calling response.end() and calls next(), which confuses connect's server.

Build a Personal Blog with Node.js and Express

Thu, 19 Feb 2026 08:29:45 +0000

Creating a personal blog is a great way to share your thoughts, ideas, and projects with the world. In this tutorial, we'll walk through building and deploying a blog application using Node.js and Express.

Prerequisites

Before starting, ensure you have the following:

Node.js installed on your machine
Basic understanding of JavaScript
A code editor (like VS Code)

Step 1: Set Up Your Project

Open your terminal and create a new directory for your blog. Navigate to it and initialize a new Node.js project:

mkdir my-personal-blog
cd my-personal-blog
npm init -y

This creates a package.json file, where all your project dependencies will reside.

Step 2: Install Necessary Packages

Next, you’ll need to install Express and some other helpful packages:

npm install express body-parser ejs mongoose dotenv

express handles your server logic.
body-parser helps parse incoming request bodies.
ejs is a templating engine for rendering HTML.
mongoose interacts with MongoDB for data management.
dotenv manages environment variables.

Step 3: Set Up Your Server

Create a new file called server.js and set up a basic Express server:

const express = require('express');
const bodyParser = require('body-parser');
const mongoose = require('mongoose');
const app = express();
const PORT = process.env.PORT || 5000;

mongoose.connect('mongodb://localhost/my-blog', { useNewUrlParser: true, useUnifiedTopology: true });

app.use(bodyParser.urlencoded({ extended: true }));
app.set('view engine', 'ejs');

app.get('/', (req, res) => {
  res.send('Welcome to My Personal Blog');
});

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

This simple setup initiates an Express server that listens for requests.

Step 4: Define Your Database Schema

Create a folder named models and add a file named Post.js for your blog posts schema:

const mongoose = require('mongoose');

const postSchema = new mongoose.Schema({
  title: String,
  content: String,
  createdAt: { type: Date, default: Date.now }
});

module.exports = mongoose.model('Post', postSchema);

Step 5: Create Blog Routes

Add routes to create and display posts. In your server.js, include the following:

const Post = require('./models/Post'); 

app.get('/posts', async (req, res) => {
  const posts = await Post.find();
  res.render('posts', { posts });
});

app.post('/posts', async (req, res) => {
  const newPost = new Post({ title: req.body.title, content: req.body.content });
  await newPost.save();
  res.redirect('/posts');
});

Step 6: Create Views

Create a views folder, and within it create posts.ejs which renders your posts:

<!DOCTYPE html>
<html>
<head>
  <title>My Blog</title>
</head>
<body>
  <h1>My Blog Posts</h1>
  <form action="/posts" method="POST">
    <input type="text" name="title" placeholder="Title" required>
    <textarea name="content" placeholder="Content" required></textarea>
    <button type="submit">Add Post</button>
  </form>
  <ul>
    <% posts.forEach(post => { %>
      <li><h2><%= post.title %></h2><p><%= post.content %></p></li>
    <% }) %>
  </ul>
</body>
</html>

Step 7: Test Your Application

Start your server:

node server.js

Open your browser and navigate to http://localhost:5000. You should see your personal blog!

Step 8: Deploy Your Blog

Now that your blog is up and running, consider deploying it using platforms like Heroku or Vercel. Follow their guides on how to deploy Node.js applications.

Conclusion

Congratulations! You’ve built and deployed a personal blog using Node.js and Express. This project sets a solid foundation for exploring more advanced features like user authentication, comments, or even media uploads in the future. Happy coding!

Building Web Servers with Node.js and Bun – A Backend Developer’s First Step

Mon, 28 Jul 2025 06:12:04 +0000

Welcome Back to the Backend Development Series!

In the previous post, we laid the groundwork:

✅ We explained what a web server is
✅ We explored the Client-Server Architecture
✅ We saw how JavaScript can run on the backend using Node.js and Bun
✅ And most importantly, we built our very first web server using Node’s built-in http module

But that server had one big limitation...

⚠️ The Problem With Our First Server

In our first server, no matter what URL you visited — whether it was /, /about, /ice-tea, or even /random-nonsense — the server would respond with the exact same message:

Hello from your first Node server!

Why? Because we didn’t check what URL the user was actually requesting.
We just responded blindly to every single request.

And that’s not how real-world websites work, right?

/login should show a login form
/about should show info about your site
/ice-tea should confirm your tea order ☕

This brings us to an important feature in every backend system:
Routing

What Is Routing?

Routing is the logic that tells your server:
➡️ “If a user visits this path (/), respond with this content.
If they visit that path (/ice-tea), respond differently.”

In simple terms:
Different URLs → Different responses

What You’ll Learn in This Blog

We’re going hands-on again — but this time, we’ll build two smart servers:

A Vanilla Node.js server (with manual routing using if-else)
A Bun server (with its built-in speedy tools)

By the end, you'll understand:

✅ How to respond to specific paths like /, /login, /ice-tea
✅ How routing works without any frameworks
✅ Why developer experience matters
✅ And why frameworks like Express.js were born to save our sanity

Let’s start with Node.js.

️ Building a Smarter Web Server in Node.js (Vanilla Style)

Step 1: Create a File

Create a new file named:

server-node.js

Step 2: Add This Code

const http = require("http");

const hostname = "127.0.0.1";
const port = 3000;

const server = http.createServer((req, res) => {
  if (req.url === "/") {
    res.statusCode = 200;
    res.setHeader("Content-Type", "text/plain");
    res.end("Hello, it's Ice Tea!");
  } else if (req.url === "/ice-tea") {
    res.statusCode = 200;
    res.setHeader("Content-Type", "text/plain");
    res.end("Thanks for ordering ice tea. It's really hot!");
  } else {
    res.statusCode = 404;
    res.setHeader("Content-Type", "text/plain");
    res.end("404 - Not Found");
  }
});

server.listen(port, hostname, () => {
  console.log(`Server is listening at http://${hostname}:${port}`);
});

What’s Happening Here?

Let’s break it down:

`req.url`

This gives us the path the user is trying to access. Examples:

/
/ice-tea
/something-weird

We use this value to decide what response to send back.

`if...else if...else`

This is basic routing logic:

If the user visits / → show the homepage
If they visit /ice-tea → give them a virtual cup ☕
If they visit anything else → show a 404 - Not Found message

▶️ How to Run It

Open your terminal
Run the server:

node server-node.js

Open your browser and go to:

http://127.0.0.1:3000/ → You’ll see: Hello, it's Ice Tea!
http://127.0.0.1:3000/ice-tea → You’ll see: Thanks for ordering ice tea. It's really hot!
http://127.0.0.1:3000/anything-else → You’ll see: 404 - Not Found

Why This Matters

In our first server (from the last post), we didn’t handle routes at all.
The result? Every request got the same reply. That’s not practical.

This version adds conditional logic — a baby step toward how real websites handle pages, endpoints, and APIs.

You’ve just built your first routing mechanism in Node.js!

Rebuilding the Same Server with Bun

We’ve already built a basic web server in Node.js using http.createServer and some conditional routing.

Now let’s recreate the exact same logic, but this time using Bun — the newer, faster JavaScript runtime that’s shaking up the backend ecosystem.

✅ If Node.js feels like a power drill, Bun is more like a Swiss Army knife — fast, modern, and loaded with built-in tools.

Step 1: Create a File

Create a new file named:

server-bun.js

Step 2: Add This Code

import { serve } from "bun";

serve({
  fetch(req) {
    const url = new URL(req.url);

    if (url.pathname === "/") {
      return new Response("Hello, it's Ice Tea!", { status: 200 });
    } else if (url.pathname === "/ice-tea") {
      return new Response("Ice tea is a good option!", { status: 200 });
    } else {
      return new Response("404 - Not Found", { status: 404 });
    }
  },
  port: 3000,
  hostname: "127.0.0.1"
});

What’s Going On Here?

Let’s break it down piece by piece:

✅ `import { serve } from "bun"`

No need for http module or third-party packages — Bun comes with serve built-in
This function spins up a server instantly with minimal setup

✅ `fetch(req)`

Instead of createServer((req, res) => {}), Bun uses a fetch()-like handler
If you've ever used fetch() in the browser, this will feel familiar
This function receives the request and is expected to return a Response object

✅ `new URL(req.url)`

This gives you an easy way to extract the pathname (like / or /ice-tea) from the request URL
Think of it like a more modern and cleaner way than parsing req.url manually in Node

✅ `return new Response(...)`

Just like the browser's fetch() API — you return a Response object with a body and status code

What You Just Did

You created a complete HTTP server using only 10 lines of code, with:

No external dependencies
No manual headers
No boilerplate setup

And it still behaves exactly like the Node.js version:

▶️ How to Run It

Make sure you have Bun installed. Then run:

bun server-bun.js

Now, visit these URLs in your browser:

URL	Response
`http://127.0.0.1:3000/`	`Hello, it's Ice Tea!`
`http://127.0.0.1:3000/ice-tea`	`Ice tea is a good option!`
`http://127.0.0.1:3000/random`	`404 - Not Found`

Key Learnings – Node.js vs Bun Syntax Comparison

Let’s break down how Node.js and Bun differ in terms of syntax and developer experience:

Feature	Node.js	Bun
Imports	`require("http")`	`import { serve } from "bun"`
Server creation	`http.createServer()`	`serve()`
Request object	`req.url`	`new URL(req.url)`
Response	`res.writeHead(), res.end()`	`return new Response(...)`
Port/Host setup	`server.listen(port, host)`	Included directly in `serve({})`
File support	CommonJS (`.js`)	ESM-first (`.js`, `.ts`, `.jsx`, etc.)
Auto Restart	❌ Manual restart required	❌ Not built-in (use `bunx nodemon` or `bun --watch`)

⚠️ The Problem: Code Reusability & Scalability

Let’s face it — even with just 3 routes, our if-else chain already looks messy.

Imagine managing 20+ routes in a real-world API this way.

Problem	Why It Matters
❌ Hard to read	Too much nesting, unclear logic
❌ Not modular	All logic in one file — no separation
❌ Difficult to test	No reusable structure, can't isolate parts

The Solution: Use a Framework

That’s why developers turn to backend frameworks — to make their code cleaner, modular, and scalable.

Some popular options:

Express (Node.js) – industry standard
Hono (Bun) – minimal, super fast
Fastify – fast, schema-based
Koa – modern, middleware-centric

These frameworks provide:

✅ Route grouping
✅ Middleware support (auth, logging, etc.)
✅ Centralized error handling
✅ Clean, readable syntax
✅ Better DX (Developer Experience)

What’s `Next`?

In the next blog, we’ll take things to the next level:

Explore backend frameworks (not just Express)
Start using Express.js to build cleaner, modular, and testable APIs
Learn about middleware, route grouping, and error handling

You’ve just taken your first real step toward backend mastery.
If you found this post helpful, just wait till we dive into frameworks — things are about to get way more powerful (and easier)!

Stay tuned.

Coder Legion - Recent posts tagged express

Stop Inventing Custom API Errors: A Guide to RFC 7807 Problem Details

The Everyday Analogy: Car Diagnostic Reports

Why RFC 7807 Matters for Engineers

Code Example: Express.js Error Handler

Key Takeaway

Stop Hardcoding Secrets: Master Environment Variables and Dotenv in Node.js

Stop Hardcoding Secrets: Master Environment Variables and Dotenv in Node.js

What Are Environment Variables and Dotenv Configuration?

A Real-World Analogy: The Wallet Index Card

Why Environment Variables Matter Every Single Day

Code Example: Configuring Express with Dotenv

Key Takeaway

Why Express Applications Become Difficult to Secure at Scale

The Security Complexity Problem

When Security Relies on Team Convention

The Dependency Explosion

The Middleware Visibility Problem

Reactive vs. Proactive Architecture

The True Cost of Human Error

The Rise of Secure-by-Default Framework Design

Shifting the Paradigm: The XyPriss Approach

Conclusion

Further Reading

XyPriss: Rethinking Core Performance and Zero-Trust Architecture in Modern Backends

Core Architectural Pillars

Battle-Tested and Growing

Links and Resources

How I built a Social Recipe Extractor that turns short-form video links into structured recipes

The Flow

1. Frontend Entry Point

2. Backend-Owned Extraction Flow

3. Structured Extraction

4. Normalization and Cleanup

5. Caching and History

6. Premium-Friendly Usage Model

Wrapping Up

From Modal to Full Page: How We Refactored a Vue 3 Recipe Detail View (and Made It Faster)

From Modal to Full Page: How We Refactored a Vue 3 Recipe Detail View (and Made It Faster)

The Old Approach: Everything in a Modal

The New Approach: Dedicated Route + Page

What We Cut From HomePage.vue

What the Page Layout Looks Like

Mobile: Icon Buttons + Bottom Sheet AI

SEO + Meta Tags

Async Components Throughout

Auth Guard on Grocery Import

The Result

Built a Laravel-Inspired Framework in Node.js (Here’s Why) - NetPress

Error [err_http_headers_sent]: cannot set headers after they are sent to the client

Build a Personal Blog with Node.js and Express

Prerequisites

Step 1: Set Up Your Project

Step 2: Install Necessary Packages

Step 3: Set Up Your Server

Step 4: Define Your Database Schema

Step 5: Create Blog Routes

Step 6: Create Views

Step 7: Test Your Application

Step 8: Deploy Your Blog

Conclusion

Building Web Servers with Node.js and Bun – A Backend Developer’s First Step

Welcome Back to the Backend Development Series!

⚠️ The Problem With Our First Server

What Is Routing?

What You’ll Learn in This Blog

️ Building a Smarter Web Server in Node.js (Vanilla Style)

Step 1: Create a File

Step 2: Add This Code

What’s Happening Here?

req.url

if...else if...else

▶️ How to Run It

Why This Matters

Rebuilding the Same Server with Bun

Step 1: Create a File

Step 2: Add This Code

What’s Going On Here?

✅ import { serve } from "bun"

✅ fetch(req)

`req.url`

`if...else if...else`

✅ `import { serve } from "bun"`

✅ `fetch(req)`

✅ `new URL(req.url)`

✅ `return new Response(...)`

What’s `Next`?