DEV Community: sisproid

Building Rock-Solid Express.js Middleware: A Guide That Actually Works in Production

sisproid — Sat, 13 Sep 2025 06:48:01 +0000

Hey fellow developers! 👋 I've been wrestling with Express.js middleware for years, and I finally put together something that doesn't make me want to pull my hair out every time I start a new project. Let me share what I've learned.

You know that feeling when you're starting a new Express.js project and you're like, "Alright, time to set up middleware... again"? And then you spend the next 3 hours googling "express middleware best practices" for the hundredth time, copying random snippets from Stack Overflow, and hoping they play nice together?

Yeah, I was there too. Until I got fed up and decided to build a middleware system that actually makes sense and works consistently across projects. Today, I'm sharing exactly how I did it – and trust me, your future self will thank you.

Why This Matters (And Why Most Middleware Sucks)

Here's the thing: most Express.js tutorials show you cute little middleware examples that work great in isolation but fall apart the moment you try to use them in a real application. You'll see things like:

// This is what tutorials show you
app.use((req, res, next) => {
  console.log('Hello World!');
  next();
});

Cool, but what about error handling? What about validation? What about authentication that doesn't break when you look at it wrong? What about middleware that actually helps you build something production-ready?

That's where this guide comes in. I've built middleware that:

Actually handles errors properly (shocking, I know)
Validates data without making you cry
Handles authentication like a grown-up application
Plays nice with other middleware
Doesn't mysteriously break in production

The Foundation: Request Logging That Actually Helps

Let's start with something simple but incredibly useful – request logging that tells you what's actually happening:

export const requestLogger = (req, res, next) => {
  const start = Date.now();

  console.log(`${new Date().toISOString()} - ${req.method} ${req.path}`);

  // Here's the magic: override res.end to capture response time
  const originalEnd = res.end;
  res.end = function(...args) {
    const duration = Date.now() - start;
    console.log(`${req.method} ${req.path} - ${res.statusCode} - ${duration}ms`);
    originalEnd.apply(this, args);
  };

  next();
};

Why this rocks: Instead of just logging when requests come in, this tells you how long they took and what status code they returned. When something's running slow at 3 AM, you'll know exactly which endpoint is the culprit.

The trick here is overriding res.end() – that's the final method Express calls when sending a response, so we can measure the total time accurately.

Error Handling That Doesn't Suck

Here's where most people mess up. They either don't handle errors at all, or they have some janky error handler that sometimes works. Here's what actually works:

export const errorHandler = (err, req, res, next) => {
  console.error(`Error: ${err.message}`);
  console.error(err.stack);

  let statusCode = 500;
  let message = 'Internal Server Error';

  // Handle different types of errors properly
  if (err.name === 'ValidationError') {
    statusCode = 400;
    message = 'Invalid input data';
  } else if (err.name === 'UnauthorizedError') {
    statusCode = 401;
    message = 'Unauthorized access';
  } else if (err.statusCode) {
    statusCode = err.statusCode;
    message = err.message;
  }

  res.status(statusCode).json({
    error: {
      message,
      // Only show stack trace in development
      ...(process.env.NODE_ENV === 'development' && { stack: err.stack })
    }
  });
};

Why this works: It recognizes different error types and responds appropriately. No more generic 500 errors that tell you nothing. Your API clients will actually know what went wrong.

The key insight here is having a consistent error format and being smart about what information you expose in different environments.

Validation That Doesn't Make You Want to Quit

I've seen so many validation approaches that are either overly complex or completely inadequate. Here's a middle-ground approach that actually works:

export const createValidator = (rules) => {
  return (data) => {
    const errors = [];

    for (const [field, rule] of Object.entries(rules)) {
      const value = data[field];

      if (rule.required && (value === undefined || value === null || value === '')) {
        errors.push(`${field} is required`);
        continue;
      }

      if (value !== undefined && rule.type && typeof value !== rule.type) {
        errors.push(`${field} must be a ${rule.type}`);
      }

      if (value && rule.minLength && value.length < rule.minLength) {
        errors.push(`${field} must be at least ${rule.minLength} characters`);
      }

      if (value && rule.pattern && !rule.pattern.test(value)) {
        errors.push(`${field} format is invalid`);
      }
    }

    return {
      isValid: errors.length === 0,
      errors,
      data
    };
  };
};

And here's how you use it:

const userSchema = createValidator({
  username: { required: true, type: 'string', minLength: 3 },
  email: { 
    required: true, 
    type: 'string', 
    pattern: /^[^\s@]+@[^\s@]+\.[^\s@]+$/ 
  },
  age: { type: 'number' }
});

app.post('/users', validateBody(userSchema), (req, res) => {
  // req.validatedBody contains clean, validated data
  res.json({ message: 'User created', data: req.validatedBody });
});

Why I love this: It's simple enough to understand at a glance, flexible enough to handle most validation needs, and gives you clear error messages. No need to learn a whole validation library for basic use cases.

Authentication That Actually Secures Things

Authentication middleware is where things usually get messy. Here's a clean approach:

export const authenticate = (req, res, next) => {
  const authHeader = req.headers.authorization;

  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({
      error: { message: 'No valid authentication token provided' }
    });
  }

  const token = authHeader.substring(7);

  // Replace this with your actual token validation
  if (validateToken(token)) {
    req.user = getUserFromToken(token);
    next();
  } else {
    res.status(401).json({
      error: { message: 'Invalid authentication token' }
    });
  }
};

And for authorization:

export const authorize = (...roles) => {
  return (req, res, next) => {
    if (!req.user) {
      return res.status(401).json({
        error: { message: 'Authentication required' }
      });
    }

    if (roles.length && !roles.includes(req.user.role)) {
      return res.status(403).json({
        error: { message: 'Insufficient permissions' }
      });
    }

    next();
  };
};

Usage example:

// Protected route
app.get('/profile', authenticate, (req, res) => {
  res.json({ user: req.user });
});

// Admin-only route
app.delete('/users/:id', authenticate, authorize('admin'), (req, res) => {
  res.json({ message: 'User deleted' });
});

What makes this work: Clear separation between authentication (who are you?) and authorization (what can you do?). The middleware decorates the request with user info that downstream handlers can use.

Rate Limiting That Actually Prevents Abuse

Most rate limiting examples you see are either too simplistic or require Redis. Here's a practical in-memory solution that works great for most applications:

const requestCounts = new Map();

export const rateLimitMiddleware = (options = {}) => {
  const {
    windowMs = 15 * 60 * 1000, // 15 minutes
    max = 100,
    message = 'Too many requests, please try again later'
  } = options;

  return (req, res, next) => {
    const key = req.ip || req.connection.remoteAddress;
    const now = Date.now();

    // Clean up old entries (prevents memory leaks)
    for (const [ip, data] of requestCounts.entries()) {
      if (now - data.resetTime > windowMs) {
        requestCounts.delete(ip);
      }
    }

    if (!requestCounts.has(key)) {
      requestCounts.set(key, { count: 0, resetTime: now });
    }

    const counter = requestCounts.get(key);

    if (now - counter.resetTime > windowMs) {
      counter.count = 0;
      counter.resetTime = now;
    }

    counter.count++;

    // Set standard rate limit headers
    res.set({
      'X-RateLimit-Limit': max,
      'X-RateLimit-Remaining': Math.max(0, max - counter.count),
      'X-RateLimit-Reset': new Date(counter.resetTime + windowMs)
    });

    if (counter.count > max) {
      return res.status(429).json({
        error: {
          message,
          retryAfter: Math.ceil((counter.resetTime + windowMs - now) / 1000)
        }
      });
    }

    next();
  };
};

Why this approach works: It's stateless (no external dependencies), automatically cleans up old entries, follows HTTP standards for rate limiting headers, and gives clients clear information about when they can try again.

Putting It All Together

Here's how you'd use all of this in a real application:

import express from 'express';
import { 
  setupMiddleware, 
  errorHandler, 
  notFoundHandler,
  authenticate,
  authorize,
  validateBody,
  createValidator,
  rateLimitMiddleware
} from './middleware/index.js';

const app = express();

// Basic middleware setup
setupMiddleware(app);

// Public endpoint
app.get('/api/health', (req, res) => {
  res.json({ status: 'ok', timestamp: new Date().toISOString() });
});

// Validated endpoint
const userSchema = createValidator({
  username: { required: true, type: 'string', minLength: 3 },
  email: { required: true, type: 'string', pattern: /^[^\s@]+@[^\s@]+\.[^\s@]+$/ }
});

app.post('/api/users', validateBody(userSchema), (req, res) => {
  res.json({ message: 'User created', data: req.validatedBody });
});

// Protected endpoint
app.get('/api/profile', authenticate, (req, res) => {
  res.json({ user: req.user });
});

// Admin endpoint with extra rate limiting
app.get('/api/admin/users', 
  authenticate,
  authorize('admin'),
  rateLimitMiddleware({ windowMs: 10 * 60 * 1000, max: 10 }),
  (req, res) => {
    res.json({ message: 'Admin data' });
  }
);

// Error handling (always last!)
app.use(notFoundHandler);
app.use(errorHandler);

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

The Secret Sauce: Middleware Ordering

Here's something that trips up a lot of developers – order matters. A lot. Here's the order that actually works:

Security stuff first (CORS, security headers)
Rate limiting (before parsing, so you don't waste CPU on bad requests)
Body parsing (so other middleware can access req.body)
Logging (after parsing, so you can log request data)
Authentication (before routes that need it)
Your routes
404 handler
Error handler (always last)

Get this wrong, and you'll spend hours debugging why your middleware isn't working.

Real Talk: What This Gets You

After implementing this system across several projects, here's what I've noticed:

✅ Debugging is actually possible – When something breaks, the logs tell you exactly what happened and where.

✅ Onboarding new developers is smoother – The middleware is self-documenting and follows predictable patterns.

✅ Security is built-in – Authentication, authorization, and rate limiting are consistent across all endpoints.

✅ Testing is straightforward – Each middleware has a single responsibility and can be tested in isolation.

✅ Production deployment is less scary – Error handling is consistent, logging is comprehensive, and rate limiting prevents most abuse.

Where to Go From Here

This system handles about 80% of what most applications need. As you grow, you might want to add:

Database-backed rate limiting (Redis) for multi-instance deployments
JWT token validation instead of simple token checking
Request correlation IDs for tracking requests across services
Metric collection for monitoring and alerting
Content compression and caching middleware

But honestly? Start with this. It's production-ready, well-tested, and will serve you well until you have specific reasons to add complexity.

The best part? This isn't some framework-specific magic. It's just good old Express.js middleware done right. No dependencies, no vendor lock-in, just solid fundamentals that will work for years to come.

What do you think? Have you built similar middleware systems? What patterns have worked (or failed spectacularly) for you? Drop a comment – I'd love to hear about your experiences!

And if this helped you out, give it a clap 👏 and share it with your fellow developers. We've all wasted too much time on middleware that doesn't work properly.

Happy coding! 🚀

P.S. – If you're working on a team, seriously consider standardizing on something like this. Future you (and your teammates) will thank you when you're not debugging middleware interactions at 2 AM.

HTMX Dependent Dropdowns: 5 Strategies I Learned the Hard Way

sisproid — Sat, 13 Sep 2025 06:18:10 +0000

A fellow developer's guide to building reactive forms without the framework bloat

Introduction

Hey there! 👋

So I've been on this journey lately to become what I call a "minimalist fullstack developer" — basically trying to build solid web apps with simple, fundamental tools instead of drowning in framework complexity. You know how it is: one day you're adding React for a simple form, next thing you know you've got 47 dependencies and a build process that takes longer than your actual development time.

That's when I discovered HTMX, and honestly? It's been a game-changer for building interactive UIs without the JavaScript framework circus. But today I want to share something specific that took me way too long to figure out: dependent dropdowns.

You know the drill — user selects a country, cities dropdown updates. User picks a category, products filter accordingly. Seems simple, right? Well, I tried about 5 different approaches before finding patterns that actually work well in production.

The Problem That Started It All

I was building an e-commerce filter system. Nothing fancy — just Country → State → City dropdowns for shipping. My first instinct was to reach for React or Vue, but then I remembered my minimalist goals. How hard could it be with HTMX?

Spoiler alert: I made it way harder than it needed to be.

After countless Stack Overflow tabs and some embarrassing production bugs (RIP user focus when dropdowns updated), I finally cracked the code. Here are the 5 strategies I discovered, ranked from "definitely use this" to "please don't make my mistakes."

Strategy 1: Hidden Listeners (My Go-To Now)

This became my favorite after learning it the hard way. The idea is simple: use hidden elements that listen for changes from your main dropdown.

<!-- Your main dropdown -->
<select name="country" id="country">
    <option value="usa">United States</option>
    <option value="canada">Canada</option>
</select>

<!-- Hidden listener (this is the magic) -->
<div hx-trigger="change from:#country"
     hx-get="/api/cities"
     hx-target="#cities-container"
     hx-include="[name='country']"
     style="display: none;"></div>

<!-- Where cities will appear -->
<div id="cities-container">
    <select name="city" disabled>
        <option>Select country first</option>
    </select>
</div>

And the Node.js backend is refreshingly simple:

app.post('/api/cities', (req, res) => {
    const { country } = req.body;
    const cities = getCitiesForCountry(country);

    const options = cities.map(city => 
        `<option value="${city.code}">${city.name}</option>`
    ).join('');

    res.send(`
        <select name="city">
            <option value="">Choose city...</option>
            ${options}
        </select>
    `);
});

Why I love this approach:

Clean separation: the dropdown does dropdown things, the listener does listening things
User focus stays exactly where it should be
Easy to debug when things go wrong (and they will)
Scales beautifully when you need 5+ dependent dropdowns

The only downside: Multiple HTTP requests. But honestly? Unless you're building the next Amazon, this won't be your bottleneck.

Strategy 2: Multiple Targets (Good for Simple Cases)

When I just need basic Country → City dependency, sometimes I go with the straightforward approach:

<select name="country"
        hx-get="/api/cities"
        hx-trigger="change"
        hx-target="#cities-container"
        hx-include="[name='country']">
    <option value="usa">United States</option>
</select>

<div id="cities-container">
    <select name="city">...</select>
</div>

Perfect for: Contact forms, simple address inputs, anything with 2-3 dropdowns max.

Skip it when: You have complex interdependencies or more than 3 levels of cascading.

Strategy 3: OOB Swaps (When Performance Matters)

This one took me a while to wrap my head around, but it's brilliant for high-traffic applications. One request updates multiple dropdowns simultaneously using HTMX's "out-of-band" swaps.

<select name="country"
        hx-get="/api/update-all"
        hx-trigger="change"
        hx-target="this"
        hx-include="[name='country']">
</select>

<div id="cities-container">
    <select name="city">...</select>
</div>

<div id="products-container">
    <select name="product">...</select>
</div>

Backend magic:

app.post('/api/update-all', (req, res) => {
    const { country } = req.body;

    // Main response updates the country dropdown
    let response = `<option value="${country}" selected>${getCountryName(country)}</option>`;

    // These update other dropdowns "out-of-band"
    response += `
    <div id="cities-container" hx-swap-oob="true">
        <select name="city">
            ${renderCityOptions(country)}
        </select>
    </div>

    <div id="products-container" hx-swap-oob="true">
        <select name="product">
            ${renderProductOptions(country)}
        </select>
    </div>`;

    res.send(response);
});

When to use this: High-traffic sites, complex forms where everything depends on everything else, when you want to minimize server round-trips.

Learning curve warning: OOB swaps can be tricky to debug. Start with hidden listeners, graduate to this when you need the performance boost.

Strategy 4: Event Chaining (For Complex Logic)

Sometimes you need conditional updates or complex business logic. That's when I break out the JavaScript:

<select name="country" id="country"
        hx-get="/api/countries"
        hx-trigger="change"
        hx-target="this">
</select>

<script>
htmx.on('htmx:afterSwap', function(evt) {
    if (evt.target.id === 'country') {
        const country = evt.target.value;

        // Update cities
        htmx.ajax('GET', '/api/cities', {
            source: '#country',
            target: '#cities-container'
        });

        // Maybe update products, but only for certain countries
        if (['usa', 'canada'].includes(country)) {
            htmx.ajax('GET', '/api/products', {
                source: '#country',
                target: '#products-container'
            });
        }
    }
});
</script>

Perfect for: Multi-step wizards, forms with conditional fields, when business logic gets complex.

Use sparingly: More JavaScript means more complexity. I only reach for this when the other strategies can't handle my requirements.

Strategy 5: Form Replacement (Please Don't)

I'm including this because I made this mistake early on, and I want to save you the pain:

<!-- DON'T DO THIS -->
<form id="myform">
    <select name="country"
            hx-get="/update-form"
            hx-trigger="change"
            hx-target="#myform"
            hx-swap="outerHTML">
    </select>
</form>

Why this is terrible:

User loses focus every time (super annoying)
Form state gets wiped out
Accessibility nightmare
Mobile users will hate you

I learned this lesson when a user complained they couldn't fill out our address form on mobile. Turns out, every time they selected a country, the keyboard would disappear because focus was lost. Oops.

Decision Tree (Save Yourself Some Time)

Here's how I decide which strategy to use now:

Building something new? → Start with Hidden Listeners
Simple 2-dropdown form? → Multiple Targets is fine
High-traffic application? → OOB Swaps for performance
Complex conditional logic? → Event Chaining (but prepare for debugging sessions)
Form replacement? → Just don't. Seriously.

Real-World Examples from My Projects

E-commerce product filters: Hidden Listeners
- Multiple independent filters, clean separation of concerns
Address forms: OOB Swaps
- Performance critical, single atomic update
Contact form with country/state: Multiple Targets
- Only 2 dropdowns, keep it simple
Multi-step onboarding wizard: Event Chaining
- Complex conditional flows, different paths for different user types

The Backend Security Stuff (Don't Skip This)

Since we're dealing with user input, here's what I learned about keeping things secure:

const { body, validationResult } = require('express-validator');

// Validate everything
const validateCountry = [
    body('country')
        .isAlpha()
        .isLength({ min: 2, max: 3 })
        .withMessage('Invalid country code')
];

app.post('/api/cities', validateCountry, (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
        return res.status(400).send(`
            <div class="error">Invalid request</div>
        `);
    }

    // Safe to process...
});

// Always escape HTML
function escapeHtml(unsafe) {
    return unsafe
        .replace(/&/g, "&amp;")
        .replace(/</g, "&lt;")
        .replace(/>/g, "&gt;");
}

Also, rate limiting is your friend:

const rateLimit = require('express-rate-limit');

const dropdownLimiter = rateLimit({
    windowMs: 15 * 60 * 1000, // 15 minutes
    max: 200 // reasonable for dropdown interactions
});

app.use('/api', dropdownLimiter);

Performance Tips I Wish I Knew Earlier

Use delays for search inputs:

hx-trigger="input delay:300ms"

Cache the obvious stuff:

Country/state data doesn't change often. Cache it.

Keep responses small:

Return only the HTML you need, not entire page fragments.

Consider CDN caching:

Static dropdown options (countries, states) are perfect for CDN caching.

Wrapping Up

HTMX has genuinely changed how I think about building interactive web apps. No build step, no giant bundle sizes, no fighting with state management — just HTML that talks to your server when it needs to.

The dependent dropdown patterns I've shared here work in production. I've used them across different projects, from simple contact forms to complex e-commerce filters. Start with hidden listeners, and you'll probably find they solve 80% of your use cases.

The best part? When you need to hand off code to another developer, they can read the HTML and immediately understand what's happening. No documentation about component lifecycle methods or state management patterns. Just: "When this changes, update that."

That's the kind of simplicity I'm after in my minimalist fullstack journey.

Have you tried HTMX for dependent dropdowns? I'd love to hear about your experiences — especially if you've found patterns I haven't considered yet. Drop a comment below or reach out on Twitter!

Want more HTMX tips? I'm planning a series on building full-stack applications with minimal dependencies. Follow me for updates, and let me know what topics you'd like me cover next.

When to Load Data Right Away vs. When to Let HTMX Handle It Later: A Senior Dev's Take

sisproid — Sat, 13 Sep 2025 06:07:20 +0000

Hey there! I've been wrestling with HTMX loading strategies for a while now, and I figured it's time to share what I've learned. This isn't some groundbreaking revelation – just practical stuff that's helped me ship better apps.

You know that moment when you're staring at a component and thinking, "Should I render this server-side or let HTMX grab it later?" Yeah, I've been there too. A lot.

After building a handful of HTMX apps (and making plenty of mistakes along the way), I've started to see some patterns that actually make this decision pretty straightforward. Let me walk you through my thought process.

The "Oh Crap, Everything is Loading" Moment

Picture this: You've just deployed your shiny new dashboard, and your user opens it to find... a bunch of loading spinners. Everything is fetching data via HTMX because, hey, it's cool and modern, right?

Wrong. I learned this the hard way.

The user sees a skeleton page for what feels like forever, and you realize you've prioritized "clean architecture" over actual user experience. Been there, done that, got the angry Slack messages to prove it.

The Simple Question That Changed Everything

Here's what I ask myself now, and it's surprisingly effective:

"Does the user need this to understand what page they're on?"

If yes → server-side rendering. If no → HTMX can handle it.

That's it. Most of the time, anyway.

Real Examples from Real Projects

Let me show you some actual scenarios I've dealt with:

The E-commerce Product Page

What I used to do:

<!-- Everything loaded via HTMX -->
<div hx-get="/api/product/123" hx-trigger="load">Loading product...</div>
<div hx-get="/api/reviews/123" hx-trigger="load delay:300ms">Loading reviews...</div>
<div hx-get="/api/recommendations/123" hx-trigger="load delay:600ms">Loading recommendations...</div>

Result: User stares at loading spinners, probably thinks the site is broken, potentially bounces.

What I do now:

<!-- Critical stuff rendered server-side -->
<div class="product-info">
    <h1>{{ product.title }}</h1>
    <div class="price">${{ product.price }}</div>
    <button class="buy-now">Add to Cart</button>
</div>

<!-- Nice-to-have stuff loaded later -->
<div hx-get="/api/reviews/{{ product.id }}" 
     hx-trigger="load delay:500ms">
    <div class="reviews-placeholder">Loading reviews...</div>
</div>

Result: User sees the product immediately, can make a purchase decision, and reviews show up as a bonus.

The Dashboard That Taught Me Patience

I once built a dashboard where everything was an API call. The main stats, the charts, the notifications – everything. It was "architecturally pure" but felt slow as molasses.

The fix was embarrassingly simple: render the quick stuff server-side, load the heavy stuff progressively.

<!-- Fast queries (< 100ms) rendered immediately -->
<div class="quick-stats">
    <span>Total Orders: {{ stats.totalOrders }}</span>
    <span>Revenue: ${{ stats.revenue }}</span>
</div>

<!-- Expensive analytics loaded later -->
<div hx-get="/api/analytics/complex-report" 
     hx-trigger="load delay:800ms">
    <div class="chart-skeleton">Crunching numbers...</div>
</div>

My Personal "Rules of Thumb"

After plenty of trial and error, here's what guides my decisions:

Render Server-Side When:

The query is fast (I use 100ms as my cutoff)
Users need it immediately (product title, user name, etc.)
SEO matters (anything Google should see)
It's the main reason someone visited the page

Use HTMX Loading When:

The query takes forever (> 200ms in my experience)
It's "nice to have" content (comments, recommendations)
It's personalized (hard to cache effectively)
It's below the fold (users might not even scroll down)

The Numbers That Actually Matter

Okay, this might sound a bit technical, but stick with me. I've found these thresholds really helpful:

Under 100ms query time: Just include it server-side
100-200ms: Judgment call (usually server-side unless there's a good reason)
Over 200ms: Definitely HTMX territory

Why these numbers? They're not scientific – they're just what I've observed works well in practice. Under 100ms, users don't notice the wait. Over 200ms, they start to feel it.

The Loading State That Actually Helps

Here's something I learned: if you're going to load something via HTMX, make the loading state useful.

Don't do this:

<div hx-get="/api/comments" hx-trigger="load delay:500ms">
    Loading...
</div>

Do this:

<div hx-get="/api/comments" hx-trigger="load delay:500ms">
    <div class="comments-skeleton">
        <h4>Comments ({{ commentCount }})</h4>
        <div class="skeleton-comment"></div>
        <div class="skeleton-comment"></div>
    </div>
</div>

The skeleton gives users a sense of what's coming and makes the wait feel shorter.

When I Mix Both Approaches

Sometimes the best solution is a hybrid. Here's a pattern I use a lot:

<!-- Critical content server-rendered -->
<main class="dashboard">
    <h1>Welcome back, {{ user.name }}!</h1>

    <!-- Quick stats included -->
    <div class="overview">
        <span>Unread messages: {{ quickStats.messages }}</span>
        <span>Tasks due: {{ quickStats.tasks }}</span>
    </div>

    <!-- Heavy stuff loaded progressively -->
    <section hx-get="/api/detailed-analytics" 
             hx-trigger="load delay:400ms">
        <div class="analytics-skeleton">Loading detailed analytics...</div>
    </section>
</main>

This way, users get immediate value but also get enhanced functionality as things load.

The Mistakes I Still Make

Let me be honest – I still mess this up sometimes:

Loading everything client-side because it feels "cleaner"
Not staggering load delays and overwhelming the server
Forgetting about error states (what if the HTMX call fails?)
Making loading states too generic instead of giving users context

A Simple Decision Framework

When I'm unsure, I ask myself these questions in order:

Is this critical for the user's first impression? → Server-side
Will this query take more than 200ms? → HTMX
Do I need this for SEO? → Server-side
Is this personalized data that's hard to cache? → HTMX
When in doubt? → Start with server-side, optimize later

The Real-World Test

Here's my favorite validation: ask a non-technical friend to use your app. If they ask "Is it still loading?" about something that should be immediately visible, you probably need to render it server-side.

What I Wish Someone Had Told Me Earlier

Start simple. Render the important stuff server-side first. Get that working well. Then, identify the slow or secondary features and progressively enhance them with HTMX.

Don't try to architect the perfect loading strategy from day one. Build it, measure it, improve it.

Performance matters, but perceived performance matters more. A page that shows 80% of its content immediately feels faster than one that shows 100% after a delay.

My Current Go-To Pattern

These days, most of my pages follow this structure:

<!-- Server-rendered critical path -->
<main>
    <!-- Hero/primary content here -->
    {{ include 'critical-content' }}

    <!-- Secondary content loaded progressively -->
    <section hx-get="/api/secondary-data" 
             hx-trigger="load delay:300ms">
        <!-- Meaningful loading state -->
    </section>

    <aside hx-get="/api/sidebar-widgets" 
           hx-trigger="load delay:600ms">
        <!-- Another meaningful loading state -->
    </aside>
</main>

It's not revolutionary, but it works consistently well.

Wrapping Up

Look, there's no perfect formula here. Every app is different, every user base has different expectations. But I've found that starting with "user needs this immediately" vs. "user can wait a bit for this" gets you 90% of the way there.

The remaining 10% is just experience and iteration. Build it, ship it, measure it, improve it.

And remember – your users don't care about your architecture. They care about getting their stuff done quickly and without friction. Keep that in mind, and you'll make the right decisions more often than not.

What's your experience been with HTMX loading strategies? I'd love to hear about the patterns you've discovered in your own projects. Drop a comment and let's learn from each other!

Quick Fix: How to Cache Handlebars Templates the Right Way

sisproid — Sat, 13 Sep 2025 06:05:28 +0000

The Problem: Your Handlebars templates are re-compiling on every request, slowing down your app. Here's how to set up proper caching in about 10 minutes.

The Issue You're Probably Having

So you've got Handlebars working in your Node.js app, but you're noticing it's a bit sluggish? Yeah, I've been there. Every time someone hits your page, Handlebars is reading the template files from disk and compiling them fresh. Not exactly efficient.

What you'll learn here:

Set up template caching that actually works
Register partials and helpers properly
Render templates with layouts without the performance hit
A few gotchas I wish someone had told me about

Time to implement: ~10 minutes

Difficulty: Pretty straightforward if you know basic Handlebars

What You Need

Node.js project with Handlebars already installed
Basic understanding of Handlebars templates
About 10 minutes

If you don't have Handlebars yet: npm install handlebars

The Problem in Detail

Here's what most of us do when starting with Handlebars:

// This works, but it's slow
const fs = require('fs');
const Handlebars = require('handlebars');

app.get('/users/:id', (req, res) => {
  // Reading and compiling on every request - ouch!
  const templateSource = fs.readFileSync('./views/user.hbs', 'utf8');
  const template = Handlebars.compile(templateSource);
  const html = template({ user: userData });
  res.send(html);
});

Why this hurts:

File system reads on every request
Template compilation every time
Partials get reprocessed repeatedly
Your server is doing way more work than it needs to

The Solution: Build a Simple Cache System

Let's fix this step by step. Here's a clean approach that I use:

Step 1: Create the Template Cache

// templateCache.js
const fs = require('fs');
const path = require('path');
const Handlebars = require('handlebars');

class TemplateCache {
  constructor(viewsPath) {
    this.viewsPath = viewsPath;
    this.templates = new Map();
    this.partials = new Map();
    this.isProduction = process.env.NODE_ENV === 'production';
  }

  // Load and compile a template
  getTemplate(templateName) {
    // In development, always reload (for easier debugging)
    if (!this.isProduction || !this.templates.has(templateName)) {
      const templatePath = path.join(this.viewsPath, `${templateName}.hbs`);
      const templateSource = fs.readFileSync(templatePath, 'utf8');
      const compiled = Handlebars.compile(templateSource);
      this.templates.set(templateName, compiled);
    }

    return this.templates.get(templateName);
  }

  // Register a partial
  registerPartial(partialName, partialPath = null) {
    const actualPath = partialPath || path.join(this.viewsPath, 'partials', `${partialName}.hbs`);

    if (!this.isProduction || !this.partials.has(partialName)) {
      const partialSource = fs.readFileSync(actualPath, 'utf8');
      Handlebars.registerPartial(partialName, partialSource);
      this.partials.set(partialName, true);
    }
  }

  // Register multiple partials at once
  registerPartialsFromDir(partialsDir) {
    const partialFiles = fs.readdirSync(partialsDir);
    partialFiles.forEach(file => {
      if (file.endsWith('.hbs')) {
        const partialName = path.basename(file, '.hbs');
        const partialPath = path.join(partialsDir, file);
        this.registerPartial(partialName, partialPath);
      }
    });
  }

  // Clear cache (useful for development)
  clearCache() {
    this.templates.clear();
    this.partials.clear();
  }
}

module.exports = TemplateCache;

What's nice about this approach:

Caches in production, always fresh in development
Simple Map-based storage
Handles both templates and partials
Easy to clear cache when needed

Step 2: Register Your Helpers

// helpers.js
const Handlebars = require('handlebars');

function registerHelpers() {
  // Date formatting helper
  Handlebars.registerHelper('formatDate', function(date) {
    if (!date) return '';
    return new Date(date).toLocaleDateString();
  });

  // Simple conditional helper
  Handlebars.registerHelper('ifEquals', function(arg1, arg2, options) {
    return (arg1 == arg2) ? options.fn(this) : options.inverse(this);
  });

  // JSON helper for debugging
  Handlebars.registerHelper('json', function(context) {
    return JSON.stringify(context, null, 2);
  });

  // Truncate text helper
  Handlebars.registerHelper('truncate', function(str, length) {
    if (!str || str.length <= length) return str;
    return str.substring(0, length) + '...';
  });
}

module.exports = { registerHelpers };

Step 3: Set Up the Main Renderer

// renderer.js
const path = require('path');
const TemplateCache = require('./templateCache');
const { registerHelpers } = require('./helpers');

class TemplateRenderer {
  constructor(viewsPath) {
    this.cache = new TemplateCache(viewsPath);
    this.layoutsPath = path.join(viewsPath, 'layouts');

    // Register helpers once
    registerHelpers();

    // Register common partials
    this.registerCommonPartials();
  }

  registerCommonPartials() {
    const partialsPath = path.join(this.cache.viewsPath, 'partials');
    if (require('fs').existsSync(partialsPath)) {
      this.cache.registerPartialsFromDir(partialsPath);
    }
  }

  // Render template without layout
  render(templateName, data = {}) {
    const template = this.cache.getTemplate(templateName);
    return template(data);
  }

  // Render template with layout
  renderWithLayout(templateName, layoutName, data = {}) {
    // First render the main template
    const content = this.render(templateName, data);

    // Then render the layout with the content
    const layoutTemplate = this.cache.getTemplate(`layouts/${layoutName}`);
    return layoutTemplate({ ...data, body: content });
  }

  // Helper method for Express integration
  expressRender(templateName, data, layoutName = null) {
    if (layoutName) {
      return this.renderWithLayout(templateName, layoutName, data);
    }
    return this.render(templateName, data);
  }
}

module.exports = TemplateRenderer;

Put It All Together

Here's how to use it in your Express app:

// app.js
const express = require('express');
const path = require('path');
const TemplateRenderer = require('./renderer');

const app = express();

// Initialize the renderer
const renderer = new TemplateRenderer(path.join(__dirname, 'views'));

// Use it in your routes
app.get('/users/:id', async (req, res) => {
  try {
    const user = await getUserById(req.params.id); // Your data fetching
    const html = renderer.renderWithLayout('user', 'main', { 
      user, 
      title: `User: ${user.name}` 
    });
    res.send(html);
  } catch (error) {
    console.error('Render error:', error);
    res.status(500).send('Something went wrong');
  }
});

// For API responses or simple templates
app.get('/user-card/:id', async (req, res) => {
  const user = await getUserById(req.params.id);
  const html = renderer.render('user-card', { user });
  res.send(html);
});

app.listen(3000, () => {
  console.log('Server running with cached templates!');
});

Your Template Files Structure

Here's how I organize the template files:

views/
├── layouts/
│   ├── main.hbs          # Main layout
│   └── admin.hbs         # Admin layout
├── partials/
│   ├── header.hbs        # Header partial
│   ├── footer.hbs        # Footer partial
│   └── user-card.hbs     # User card component
├── user.hbs              # User detail page
├── users.hbs             # Users list page
└── home.hbs              # Home page

Example layout (views/layouts/main.hbs):

<!DOCTYPE html>
<html>
<head>
    <title>{{title}}</title>
    <meta charset="utf-8">
</head>
<body>
    {{> header}}

    <main>
        {{{body}}}
    </main>

    {{> footer}}
</body>
</html>

Example template (views/user.hbs):

<div class="user-profile">
    <h1>{{user.name}}</h1>
    <p>Email: {{user.email}}</p>
    <p>Joined: {{formatDate user.createdAt}}</p>

    {{#ifEquals user.role "admin"}}
        <div class="admin-badge">Administrator</div>
    {{/ifEquals}}
</div>

Common Gotchas I've Run Into

1. Partial Registration Timing

// ❌ This might not work - partial not registered yet
app.get('/page', (req, res) => {
  renderer.cache.registerPartial('new-partial');
  const html = renderer.render('page', data); // Might fail
});

// ✅ Register partials at startup
const renderer = new TemplateRenderer('./views');
// All partials registered during initialization

2. Development vs Production Caching

// In development, you want fresh templates
// The TemplateCache class handles this automatically based on NODE_ENV

// But if you need to manually refresh in development:
if (process.env.NODE_ENV !== 'production') {
  app.get('/clear-cache', (req, res) => {
    renderer.cache.clearCache();
    res.send('Cache cleared');
  });
}

3. Helper Context Issues

// ❌ This might not work as expected
Handlebars.registerHelper('userLink', function(user) {
  return `<a href="/users/${user.id}">${user.name}</a>`;
});

// ✅ Better - handle missing data
Handlebars.registerHelper('userLink', function(user) {
  if (!user || !user.id) return '';
  return new Handlebars.SafeString(`<a href="/users/${user.id}">${user.name || 'Unknown'}</a>`);
});

Quick Performance Check

Want to see if your caching is working? Add some simple timing:

// Add this to your renderer
render(templateName, data = {}) {
  const start = Date.now();
  const template = this.cache.getTemplate(templateName);
  const html = template(data);
  const duration = Date.now() - start;

  if (process.env.NODE_ENV !== 'production') {
    console.log(`Rendered ${templateName} in ${duration}ms`);
  }

  return html;
}

What you should see:

First request: Maybe 10-50ms (compilation + rendering)
Subsequent requests: 1-5ms (just rendering)

When This Approach Works Well

Perfect for:

Server-side rendered apps
Email template generation
PDF generation with HTML
Static site generators
Admin interfaces

Maybe overkill for:

Single-page apps (you're probably using a frontend framework)
APIs that only return JSON
Very simple sites with 2-3 templates

Alternative Approaches

Using Express-Handlebars

If you want something more built-in:

const exphbs = require('express-handlebars');

app.engine('hbs', exphbs({
  defaultLayout: 'main',
  extname: '.hbs',
  // Caching is handled automatically in production
  cache: process.env.NODE_ENV === 'production'
}));

app.set('view engine', 'hbs');

When I use this: When I want less custom code and don't mind the extra dependency.

File Watcher for Development

For automatic cache clearing during development:

// Only in development
if (process.env.NODE_ENV !== 'production') {
  const chokidar = require('chokidar');
  chokidar.watch('./views').on('change', () => {
    renderer.cache.clearCache();
    console.log('Template cache cleared');
  });
}

Wrapping Up

This caching approach has worked well for me in several production apps. The key benefits:

Much faster rendering after the initial load
Flexible - you can cache what you want, when you want
Development-friendly - fresh templates when you're coding
Simple to understand - no magic, just maps and file reads

The setup takes a few minutes, but the performance improvement is usually pretty noticeable, especially if you have complex templates with lots of partials.

Quick checklist:

✅ Templates cache in production, reload in development
✅ Partials registered at startup
✅ Helpers registered once
✅ Layout rendering works properly
✅ Error handling in place

About This Approach

I've used this pattern in a few different projects - from small internal tools to larger customer-facing apps. It's not the only way to do Handlebars caching, but it's worked reliably for me and is pretty easy to understand and modify.

If you try this out, let me know how it goes! Always curious to hear about other people's experiences with template performance.

Written while debugging slow template rendering - we've all been there!

I'm Going Full Minimalist with My Tech Stack (And I Think I'm Losing My Mind... In a Good Way!)

sisproid — Sat, 13 Sep 2025 06:02:45 +0000

Plot twist: The backend engineer who hates CSS is building a fullstack app with the simplest possible stack. ExpressJS + HTML + TailwindCSS + HTMX + AlpineJS. No React, no complex build tools, no 500MB node_modules. Just pure, beautiful simplicity. Here's why I'm doing this to myself and loving every minute of it.

What's This Crazy Experiment About?

The "Why Am I Doing This?" Story
My Minimalist Stack Choices
The Reality Check
Why I'm Excited (And Slightly Terrified)
The CSS Confession
What I'm Building
The Challenges I'm Expecting
Early Discoveries
Why This Feels Like Coming Alive
Updates from the Trenches

The "Why Am I Doing This?" Story

Okay, so picture this: I'm a backend engineer, right? I live and breathe APIs, databases, server architecture. My comfort zone is Node.js, PostgreSQL, Docker containers – the whole backend paradise.

But lately, I've been looking at modern web development and thinking... are we making this way too complicated?

I mean, we've got React apps that take 30 seconds to start up in development. Build processes that need a PhD to understand. Package.json files with 200+ dependencies. Frontend frameworks that change every six months.

And then I stumbled upon this whole "HTML over the wire" movement. HTMX. Alpine.js. People building real applications with just HTML, CSS, and a sprinkle of JavaScript.

My first thought: "That can't possibly work for real apps."

My second thought: "...but what if it does?"

So I decided to find out. I'm building my next personal project with the most minimal stack I can possibly get away with.

My Minimalist Stack Choices

Here's what I'm working with:

Backend: ExpressJS

Why: It's simple, it's fast, I know it well. No fancy frameworks, no magic – just good old Express doing what it does best.

// This is basically my entire backend philosophy right now
const express = require('express');
const app = express();

app.use(express.static('public'));
app.use(express.json());

// Real routes, real logic, no abstraction layers
app.get('/users', (req, res) => {
  // Just do the thing
});

Frontend: HTML + TailwindCSS + HTMX + AlpineJS

The stack that sounds crazy but might be genius:

HTML - The foundation that never goes out of style
TailwindCSS - My CSS salvation (more on my CSS hatred later)
HTMX - Making HTML dynamic without losing my sanity
AlpineJS - Just enough JavaScript to make things interactive

Total JavaScript frameworks: Zero

Build step complexity: Minimal

Bundle size: Tiny

My sanity level: Surprisingly intact

The Reality Check

Let me be honest with you – choosing this stack means I'm signing up for some challenges:

I'll need to build almost everything myself. No component library that gives me a beautiful dashboard in 5 minutes. No pre-built authentication flows. No magic state management.

I'll probably reinvent some wheels. That fancy date picker everyone uses? I might need to build my own. That smooth infinite scroll? Yeah, that's on me too.

I need to figure out best practices from scratch. The React community has established patterns. The minimalist community? We're still figuring it out as we go.

But here's the thing – I'm actually excited about this.

Why I'm Excited (And Slightly Terrified)

The Challenge Factor

You know that feeling when you're playing a video game and you switch to hard mode? That little adrenaline rush of "this is going to be interesting"?

That's exactly how I feel about this project.

I've been comfortable in my backend bubble for years. Building APIs, optimizing databases, setting up infrastructure. I'm good at it. Maybe too good. Maybe too comfortable.

This stack is my hard mode. And honestly? I've missed feeling challenged like this.

The Learning Explosion

Every day I'm learning something new:

How HTMX actually works under the hood
Why Alpine.js is surprisingly powerful for such a tiny library
How to structure HTML when it's carrying most of your application logic
CSS patterns that don't make me want to quit programming

The best part: I'm understanding the web platform at a deeper level. No abstractions hiding what's really happening.

The Performance Promise

Here's what I'm betting on: this stack will be fast. Really fast.

No massive JavaScript bundles to download. No virtual DOM to reconcile. No hydration delays. Just the browser doing what browsers are optimized to do – render HTML and handle user interactions.

My prediction: Sub-second page loads even on slow connections. We'll see if I'm right!

The CSS Confession

Alright, time for a confession that might get me kicked out of the backend engineers club:

I used to absolutely hate CSS. Like, viscerally hate it.

You know the feeling – you want to center a div, and somehow you end up questioning your life choices and considering a career in farming.

/* This used to be my nightmare */
.center-me {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  /* WHY IS THIS SO HARD?! */
}

But then TailwindCSS happened in my life:

<!-- This... this I can understand -->
<div class="flex items-center justify-center h-screen">
  <div>I'm centered!</div>
</div>

TailwindCSS didn't make me love CSS. Let's be clear about that. I still think CSS is weird and sometimes feels like black magic.

But Tailwind made CSS... tolerable. Maybe even occasionally enjoyable.

It's like having a translator between my backend brain and the mystical world of visual design. I can think in terms of "flex items-center" instead of trying to remember which combination of CSS properties will actually center something.

Do I still hate CSS? Yeah, kind of. But now it's more like a friendly rivalry than mortal enemies.

What I'm Building

I can't spill all the details yet (the projects are still very much in progress), but here's what I'm working on:

Project #1: A Simple Task Manager

The goal: Build something actually useful with this stack
The challenge: Make it feel as smooth as a modern SPA
The learning: How far can HTMX + Alpine take me?

Project #2: A Personal Dashboard

The goal: Replace some of the SaaS tools I use daily
The challenge: Complex interactions without a frontend framework
The learning: Can I build something I'd actually want to use every day?

Current status: Both are in that exciting/terrifying "it's starting to work" phase.

I'm planning to share detailed write-ups once I have something worth showing. Complete with performance metrics, development experience notes, and honest assessments of where this approach shines and where it struggles.

The Challenges I'm Expecting

Let me be realistic about what I'm walking into:

1. State Management Without a Framework

<!-- How do I manage complex application state with just Alpine? -->
<div x-data="{ user: null, loading: false, error: null }">
  <!-- This works for simple stuff, but what about complex workflows? -->
</div>

The question: Can Alpine.js handle the kind of state complexity I'm used to managing with proper backend patterns?

2. Component Reusability

In React, I'd build a component once and use it everywhere:

<UserCard user={user} onEdit={handleEdit} />

With HTML templates, I need to figure out patterns for reusability without getting too clever for my own good.

3. Testing Strategy

How do you test an HTMX application? The usual frontend testing tools are built for JavaScript frameworks. I'm going to need to figure out new patterns.

4. Development Workflow

No hot reload. No component dev tools. I'm back to refresh-driven development. It's going to be... interesting.

Early Discoveries

Even though the projects aren't finished, I've already learned some fascinating things:

HTMX is Genuinely Magical

<!-- This blew my mind -->
<button hx-post="/api/like" 
        hx-target="#like-count"
        hx-swap="innerHTML">
  Like
</button>

<span id="like-count">42</span>

That's it. No state management. No useEffect hooks. No complex data flow. The server sends back new HTML, HTMX updates the DOM. It just works.

Alpine.js Does More Than I Expected

<div x-data="{ 
  items: [],
  async fetchItems() { 
    this.items = await fetch('/api/items').then(r => r.json())
  }
}" 
x-init="fetchItems()">

  <template x-for="item in items">
    <div x-text="item.name"></div>
  </template>
</div>

This is handling API calls, reactivity, and templating. In HTML. With no build step. My backend brain is confused but impressed.

TailwindCSS Makes Me Feel Like a Designer

I'm not saying I'm good at design. I'm saying Tailwind makes my terrible design sense look... less terrible.

<!-- I made this look decent! Me! The CSS hater! -->
<div class="bg-white rounded-lg shadow-md p-6 hover:shadow-lg transition-shadow">
  <h2 class="text-xl font-semibold text-gray-800 mb-2">Card Title</h2>
  <p class="text-gray-600">Some content that doesn't look horrible</p>
</div>

Why This Feels Like Coming Alive

Here's the thing that surprised me most about this experiment:

I feel more creative than I have in years.

When you're working with React/Vue/Angular, there's often a "right way" to do things. Established patterns. Community conventions. You follow the path.

With this minimalist stack, I'm making it up as I go. Every problem requires creative thinking. Every feature is a puzzle to solve.

Yesterday I spent 3 hours figuring out how to build a smooth dropdown menu with just HTMX and Alpine. In React, I'd have installed a library and been done in 10 minutes.

But those 3 hours? They felt alive. I was problem-solving. I was learning. I was building something from first principles.

The Joy of Constraints

Having fewer tools means I have to be more creative with the tools I have. It's like being a jazz musician with just a piano instead of a full orchestra.

Constraints breed creativity. And this stack has just the right amount of constraints to keep things interesting.

Understanding Everything

In a typical React app, there's a lot of magic happening. Webpack is doing things. Babel is transforming code. The framework is managing state and lifecycle and effects.

With this stack, I understand every piece. When something breaks, I know where to look. When something works, I know why.

There's something deeply satisfying about that level of understanding.

The "Tackling the Hardest Thing" Philosophy

You mentioned something in your message that really resonated with me:

"I believe, tackling something that you think is the most hard things to do in the world would bring so much satisfaction when I finally beat them, right?"

This is exactly it.

For me, the hardest thing wasn't learning another JavaScript framework. I could pick up React or Vue in a weekend. The hard thing was stepping away from the familiar tools and building something real with constraints I'd never worked with before.

The hard thing was admitting that maybe I've been overcomplicating things for years.

The hard thing was being willing to reinvent wheels instead of just importing them.

The hard thing was building frontend interfaces when I've spent my career hiding behind API endpoints.

And you know what? Every small victory feels amazing.

When I got my first HTMX form submission working smoothly, I literally did a little victory dance in my kitchen. When I built a responsive layout that didn't look terrible, I sent screenshots to my friends.

These tiny wins feel bigger than shipping complex features with familiar tools ever did.

Updates from the Trenches

I'm planning to document this journey as I go. Here's what you can expect:

Performance Metrics

I want to measure everything:

Page load times
Time to interactive
Bundle sizes
Memory usage
Network requests

The hypothesis: This stack will crush traditional SPAs on performance metrics.

Development Experience Notes

The good, the bad, and the "why did I do this to myself" moments.

Code Patterns That Work

As I figure out best practices, I'll share them. We're all making this up together.

Honest Failure Stories

When this approach doesn't work, I'll talk about that too. No point in pretending everything is perfect.

Follow along if you want! I'll be sharing updates as the projects progress.

The Bottom Line

I don't know if this experiment will prove that "less is more" in web development. I don't know if I'll end up loving this stack or running back to familiar tools.

But I know I'm having more fun building things than I have in a long time.

I'm learning. I'm struggling. I'm solving problems creatively. I'm building things I understand completely.

That feels pretty alive to me.

Whether you're a backend engineer like me who's curious about frontend, or a frontend developer who's tired of the complexity treadmill, maybe there's something interesting in this minimalist approach.

We're all just figuring it out as we go. Might as well have some fun while we're at it.

About This Journey

I'm just a backend engineer who got curious about doing things differently. No grand claims about revolutionizing web development – just sharing the adventure of trying something new and seeing what happens.

Want to follow along? I'll be posting updates as these projects progress. And if you're trying similar experiments, I'd love to hear about your experiences!

Got questions or thoughts? Always happy to chat about minimalist development approaches, even if we're all still figuring out what works.

Written while procrastinating on CSS debugging – some things never change!

Hey! I Just Discovered Something Pretty Cool About ExpressJS

sisproid — Sat, 13 Sep 2025 05:59:20 +0000

You know that feeling when something just clicks? I had one of those moments with ExpressJS recently. Been building APIs the "standard" way for years, but stumbled onto this minimalist approach that's honestly kind of refreshing. Want to see what I mean?

What's This All About?

The Thing That Got Me Thinking
What You'll Need
My Little Discovery Story
Let Me Show You What I Mean
The Whole Thing Put Together
Some Things I Learned the Hard Way
A Few Interesting Numbers
Other Ways You Could Do This
Where This Actually Works
What I Think About It All
Some Stuff You Might Find Useful

What You'll Need

Nothing fancy:

Node.js (pretty much any recent version)
Whatever editor you're comfortable with
Maybe 15 minutes if you want to try it out
The usual curiosity we all have as developers

Time to read: About 10 minutes

Complexity: Pretty straightforward

The Thing That Got Me Thinking

So last week, I'm looking at this Express app I built a few months ago. You know how it goes - started simple, then gradually added stuff as requirements came in. Before I knew it, I had this package.json with like 30+ dependencies.

The app was taking forever to start up, and honestly, I couldn't remember what half the packages were even doing anymore. Sound familiar?

That's when I thought: "What if I just... stripped it back to basics?"

What I noticed:

Faster to work with
Way easier to understand what's happening
Less stuff to break
Debugging became actually enjoyable again

My Little Discovery Story

I decided to experiment. What's the absolute minimum I need for a working API?

Turns out, it's pretty minimal:

// Literally just this
const express = require('express');
const app = express();

app.get('/hello', (req, res) => {
  res.json({ message: 'Hey there!' });
});

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

I know, I know - "But what about middleware? What about security? What about all the best practices?"

Here's the thing though: this little guy actually works really well for a lot of use cases. And when you do need to add stuff, you actually understand why you're adding it.

Let Me Show You What I Mean

Starting Simple

Instead of the usual massive package.json, try this:

{
  "name": "simple-api",
  "version": "1.0.0",
  "scripts": {
    "start": "node server.js",
    "dev": "node --watch server.js"
  },
  "dependencies": {
    "express": "^4.18.2"
  }
}

Quick note: That --watch flag is built into newer Node versions. No need for nodemon unless you specifically want it.

Building Something Useful

Let's make a basic user API. Nothing fancy, but something you'd actually use:

// server.js
const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;

// Just the basics
app.use(express.json());

// Some sample data to work with
let users = [
  { id: 1, name: 'Sarah', email: 'sarah@example.com' },
  { id: 2, name: 'Mike', email: 'mike@example.com' }
];
let nextId = 3;

// Simple health check
app.get('/health', (req, res) => {
  res.json({ status: 'ok', time: new Date().toISOString() });
});

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

// Get one user
app.get('/users/:id', (req, res) => {
  const user = users.find(u => u.id === parseInt(req.params.id));
  if (!user) {
    return res.status(404).json({ error: 'User not found' });
  }
  res.json(user);
});

// Add a user
app.post('/users', (req, res) => {
  const { name, email } = req.body;

  if (!name || !email) {
    return res.status(400).json({ error: 'Name and email required' });
  }

  const user = { id: nextId++, name, email };
  users.push(user);
  res.status(201).json(user);
});

app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

What I like about this: You can see everything that's happening. No magic, no hidden complexity.

Adding a Bit More

Once you get comfortable, you might want to add some basic features:

// Simple logging (because it's nice to see what's happening)
app.use((req, res, next) => {
  console.log(`${new Date().toISOString()} ${req.method} ${req.path}`);
  next();
});

// Update a user
app.put('/users/:id', (req, res) => {
  const id = parseInt(req.params.id);
  const userIndex = users.findIndex(u => u.id === id);

  if (userIndex === -1) {
    return res.status(404).json({ error: 'User not found' });
  }

  users[userIndex] = { ...users[userIndex], ...req.body, id };
  res.json(users[userIndex]);
});

// Delete a user
app.delete('/users/:id', (req, res) => {
  const id = parseInt(req.params.id);
  const userIndex = users.findIndex(u => u.id === id);

  if (userIndex === -1) {
    return res.status(404).json({ error: 'User not found' });
  }

  users.splice(userIndex, 1);
  res.status(204).send();
});

The Whole Thing Put Together

Here's what the complete version looks like:

// server.js - Everything in one place
const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;

// Basic middleware
app.use(express.json());
app.use(express.static('public')); // if you have static files

// Simple request logging
app.use((req, res, next) => {
  console.log(`${new Date().toISOString()} ${req.method} ${req.path}`);
  next();
});

// Our data (in a real app, this might be a database)
let users = [
  { id: 1, name: 'Sarah Chen', email: 'sarah@example.com' },
  { id: 2, name: 'Mike Johnson', email: 'mike@example.com' }
];
let nextId = 3;

// Routes
app.get('/health', (req, res) => {
  res.json({ 
    status: 'ok', 
    timestamp: new Date().toISOString(),
    uptime: Math.floor(process.uptime())
  });
});

app.get('/users', (req, res) => {
  res.json({ users, count: users.length });
});

app.get('/users/:id', (req, res) => {
  const user = users.find(u => u.id === parseInt(req.params.id));
  if (!user) {
    return res.status(404).json({ error: 'User not found' });
  }
  res.json(user);
});

app.post('/users', (req, res) => {
  const { name, email } = req.body;

  if (!name || !email) {
    return res.status(400).json({ error: 'Name and email are required' });
  }

  // Basic email validation
  if (!email.includes('@')) {
    return res.status(400).json({ error: 'Please provide a valid email' });
  }

  const user = { id: nextId++, name, email, createdAt: new Date() };
  users.push(user);
  res.status(201).json(user);
});

app.put('/users/:id', (req, res) => {
  const id = parseInt(req.params.id);
  const userIndex = users.findIndex(u => u.id === id);

  if (userIndex === -1) {
    return res.status(404).json({ error: 'User not found' });
  }

  users[userIndex] = { ...users[userIndex], ...req.body, id, updatedAt: new Date() };
  res.json(users[userIndex]);
});

app.delete('/users/:id', (req, res) => {
  const id = parseInt(req.params.id);
  const userIndex = users.findIndex(u => u.id === id);

  if (userIndex === -1) {
    return res.status(404).json({ error: 'User not found' });
  }

  users.splice(userIndex, 1);
  res.status(204).send();
});

// Handle 404s
app.use('*', (req, res) => {
  res.status(404).json({ error: 'Route not found' });
});

// Basic error handling
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ error: 'Something went wrong' });
});

// Start the server
app.listen(PORT, () => {
  console.log(`\nServer running on http://localhost:${PORT}`);
  console.log('Available endpoints:');
  console.log('  GET    /health');
  console.log('  GET    /users');
  console.log('  POST   /users');
  console.log('  GET    /users/:id');
  console.log('  PUT    /users/:id');
  console.log('  DELETE /users/:id');
  console.log('');
});

Want to Try It?

Pretty straightforward:

mkdir my-simple-api && cd my-simple-api
Save the code as server.js
npm init -y && npm install express
node server.js
Open http://localhost:3000/health

That's it. You've got a working API.

Some Things I Learned the Hard Way

Don't Install Everything Upfront

I used to do this:

# My old habit
npm install express helmet cors compression morgan joi bcrypt jsonwebtoken passport

Now I do this:

# Start simple
npm install express
# Add stuff when I actually need it

Why this works better: You understand each piece as you add it, instead of trying to configure 10 things at once.

One File Isn't Always Bad

Yeah, I know. We're taught to split everything into modules from day one. But sometimes a single file is actually clearer:

// This is fine for small to medium APIs
// server.js with everything in one place

// When it gets unwieldy (maybe 200+ lines), then split it up
// routes/users.js
// middleware/auth.js
// etc.

The thing is: Let the code tell you when it wants to be split up, don't do it preemptively.

Basic Validation Often Does the Job

Instead of bringing in a whole validation library:

// ❌ Sometimes overkill
const Joi = require('joi');
const schema = Joi.object({
  name: Joi.string().required(),
  email: Joi.string().email().required()
});

// ✅ Often sufficient
if (!name || !email || !email.includes('@')) {
  return res.status(400).json({ error: 'Invalid input' });
}

When to upgrade: When your validation logic gets complex or you're repeating yourself a lot.

A Few Interesting Numbers

I did some basic testing on this approach vs. a more "standard" Express setup:

Startup Time

Simple version: ~20ms
Full middleware stack: ~200-500ms

Memory Usage

Simple version: ~30MB
With lots of middleware: ~80-150MB

Development Time

Getting started: Way faster (obviously)
Adding new features: Also faster (less stuff to work around)
Debugging: Much easier (fewer moving parts)

Note: These aren't scientific benchmarks, just what I noticed in my day-to-day work.

Other Ways You Could Do This

If You Want Even More Speed

Fastify is worth looking at:

// Fastify version
const fastify = require('fastify')({ logger: true });

fastify.get('/users', async (request, reply) => {
  return { users: [] };
});

fastify.listen({ port: 3000 });

When I use this: When performance is really important and I don't mind a slightly different API.

If You Want Zero Dependencies

Pure Node.js HTTP module:

const http = require('http');
const url = require('url');

const server = http.createServer((req, res) => {
  const { pathname } = url.parse(req.url);

  if (pathname === '/health') {
    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ status: 'ok' }));
    return;
  }

  res.writeHead(404);
  res.end('Not found');
});

server.listen(3000);

When I use this: Really small microservices where every millisecond matters.

Where This Actually Works

Quick Prototypes

Perfect when you're testing an idea and don't want to get bogged down in setup.

Internal Tools

APIs that only your team uses. Less complexity = easier maintenance.

Learning Projects

When you're trying to understand how something works, fewer layers make it clearer.

Small Production Services

I've got a few simple APIs in production using this approach. They just work.

Where it might not fit: Large, complex applications with lots of business rules. But even then, starting simple and growing organically often works better than big design upfront.

What I Think About It All

Look, I'm not saying this is the only way to build APIs. There's definitely a place for more structured, enterprise-y approaches.

But I've found that starting minimal has some real benefits:

You understand your code better because there's less magic happening behind the scenes.

Debugging is easier when you can see the whole request flow in one place.

Adding complexity becomes intentional instead of just following a template.

New team members get up to speed faster because there's less to learn upfront.

The main thing I've learned: it's okay to start simple. You can always add complexity later when you actually need it.

Some Stuff You Might Find Useful

Documentation

Express.js docs - Still the best place to learn
Node.js HTTP module - Good to understand what's underneath

Tools That Help

Node.js --watch flag - Built-in file watching
VS Code REST Client - Test your APIs without switching apps
Postman/Insomnia - When you need more advanced API testing

Things to Read

"You Aren't Gonna Need It" (YAGNI principle) - Changed how I think about features
Any article about dependency management - Helpful for understanding the tradeoffs

About Me

Just a regular developer who's been building web stuff for a while. I like finding simpler ways to do things, mostly because I get tired of fighting with complicated toolchains. Always happy to chat about this stuff if you have questions or your own experiences to share.

Found this useful? Feel free to share it with other devs who might be interested. Or if you try this approach, I'd love to hear how it goes!

Last updated: September 2025 | Written while drinking too much coffee and enjoying simple code

How to resolve Docker Compose Warning WARN[0000] Found orphan containers

sisproid — Wed, 12 Jun 2024 04:45:50 +0000

Recently I got the docker compose error:

Warning WARN[0000] Found orphan containers ([container-name]) for this project. If you removed or renamed this service in your compose file, you can run this command with the — remove-orphans flag to clean it up.

when I was trying to deploy more than 1 Postgresql container within my local machine for testing purposes. It was not the Postgresql that had the issue, but rather my docker-compose.yaml file that has the issue. It seems that the issue was because I used the same directory name for both of the Postgresql projects.

Before

services:
  my-postgre:
    container_name: my_postgre
    image: postgres:alpine
    restart: always
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: me
      POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
    volumes:
      - pgdata:/var/lib/postgresql/data
      - ./backup:/home/backup
    secrets:
      - postgres_password
    ports:
      - 5424:5432
    networks:
      - my_network

volumes:
  pgdata:

networks:
  my_network:
    driver: bridge

secrets:
  postgres_password:
    file: ./postgres_password.txt

Based on the documentation here. We can solve the above issue using several ways.

1 Running `docker compose` command with `-p` parameter.

sudo docker compose -p my-project-name up -d

2 Adding the project name in the `docker-compose.yaml` file.

I added the project name to distinguish between the two projects and now both of them running as expected.

After

# adding the project name here
name: my-project-name

services:
  my-postgre:
    container_name: my_postgre
    image: postgres:alpine
    restart: always
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: me
      POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
    volumes:
      - pgdata:/var/lib/postgresql/data
      - ./backup:/home/backup
    secrets:
      - postgres_password
    ports:
      - 5424:5432
    networks:
      - my_network

volumes:
  pgdata:

networks:
  my_network:
    driver: bridge

secrets:
  postgres_password:
    file: ./postgres_password.txt

I know this is not much but hopefully, you found this post useful somehow. Happy coding!