标签：#node

Poland runs a national e-invoicing system called KSeF (Krajowy System e-Faktur). Business-to-business invoices are submitted to a government API in a schema called FA(3) , and the system hands back an official confirmation of receipt. If you sell software to Polish companies, you will meet it. The Ministry of Finance publishes official SDKs for Java and .NET . There is nothing for JavaScript. A full client is a real project: authentication, session handling, certificates, XML signing. But a large share of rejected invoices have nothing to do with any of that. They are structural. A tax ID with a bad checksum. Net plus VAT that does not add up to gross. A date that does not exist. Those are worth catching on your side, before you build a session with anyone. So I pulled that layer out of a product I work on, rewrote it standalone, and published it: ksef-invoice-validate . Zero dependencies, no network calls, runs in the browser. npm i ksef-invoice-validate import { validateInvoiceForKsef } from " ksef-invoice-validate " ; const result = validateInvoiceForKsef ({ invoice_number : " FV/2026/07/1 " , issue_date : " 2026-07-01 " , seller_nip : " 1111111111 " , buyer_nip : " 1111111111 " , amount_net : 1000 , amount_vat : 230 , amount_gross : 1230 , }); Three things in it were more interesting than I expected. The NIP checksum A Polish tax identification number (NIP) is ten digits. The tenth is a checksum over the first nine, each weighted and reduced modulo 11. const weights = [ 6 , 5 , 7 , 2 , 3 , 4 , 5 , 6 , 7 ]; const digits = cleaned . split ( "" ). map ( Number ); const checksum = weights . reduce (( sum , w , i ) => sum + w * digits [ i ], 0 ) % 11 ; if ( checksum !== digits [ 9 ]) { // invalid } There is a small elegance here. The remainder can be 10, and no single digit equals 10, so those numbers simply cannot exist as valid NIPs. You do not need a special case. The comparison rejects them on its own. This alone catches a surprising amount. Most bad tax IDs in t

Why Claude Code runs on Bun: runtime tradeoffs in TypeScript CLI tooling Anthropic recently shipped Claude Code — their agentic CLI coding assistant — on Bun instead of Node.js. For most product announcements, the runtime choice would be a footnote. Here it's worth unpacking, because the tradeoffs Anthropic navigated are exactly the ones you hit when building or evaluating TypeScript-heavy developer tooling: startup latency, bundling strategy, native module compatibility, and what "good enough" dependency management actually looks like in 2025. This isn't a Bun vs. Node benchmarking post. It's an examination of why the decision makes sense for a CLI tool specifically, what it signals about the broader ecosystem, and where the tradeoffs still bite you. Why runtime choice matters more for CLIs than for servers For a long-running server process, Node.js startup cost of 50–150ms is irrelevant — you pay it once. For a CLI invoked dozens of times per development session, cold-start latency is a first-class UX concern. Bun's startup time is consistently in the 5–15ms range for a simple script. Node.js lands closer to 50–80ms before your first line of application code runs. That delta is imperceptible in a single invocation. Run a CLI 30 times in a session and you've saved a couple of seconds — more importantly, you've removed the subjective sense of lag that makes a tool feel heavy. This is the same reason Deno has gained traction in scripting contexts despite losing the server-side battle to Node. Fast startup is a feature, and for AI-assisted tooling where the human is waiting in a tight feedback loop, it matters. Bun's bundler as a distribution primitive Bun ships a first-party bundler. For a CLI, this is significant. The standard Node.js distribution story for a TypeScript CLI involves: Compile TypeScript with tsc or esbuild Bundle with esbuild or rollup to collapse the dependency graph Either ship node_modules (large, fragile) or use a tool like pkg or nexe to produce

Every service I've worked on eventually grows the same scar tissue: a retry loop copy-pasted into six files, a circuit breaker bolted onto the payment client after an outage, a timeout wrapper someone wrote at 3 a.m. Each one slightly different. None of them talking to each other. And when things go wrong, nobody can answer the only question that matters during an incident: what is the resilience layer actually doing right now? Java solved this years ago with resilience4j . .NET has Polly . Node.js... has pieces. The gap I evaluated what the ecosystem offers before writing a single line: opossum is the best-known circuit breaker, mature and well maintained. But it's only a circuit breaker — retry is rudimentary, there's no bulkhead, no composition. Metrics need a plugin. cockatiel is the closest thing to Polly: retry, breaker, timeout, bulkhead, composition. I genuinely like its design. But observability is where it stops — no native metrics, no pipeline-wide correlation — and maintenance has slowed. The Sindre micro-libs ( p-retry , p-timeout , p-limit ) are excellent at exactly one thing each. But resilience is a system : a retry that doesn't know the circuit is open will happily sleep through backoff to hammer a dead dependency. Isolated pieces can't coordinate. And there was one thing nobody documented properly, which became the reason I finally started typing: Ordering is the whole game Take four policies: retry, circuit breaker, timeout, fallback. The same four, nested in two different orders, produce two very different systems: retry ( circuitBreaker ( timeout ( fn ) ) ) // A circuitBreaker ( retry ( timeout ( fn ) ) ) // B In A , every attempt flows through the breaker, so the breaker sees the dependency's true failure rate — and when the circuit opens mid-retry, the retry finds out immediately. In B , the breaker sees one outcome per retry cycle : three real failures against the dependency count as a single failure. The circuit opens far later than the depe

Modern applications don't just need features—they need observability . When an API becomes slow, a database query takes too long, or an unexpected error occurs, developers need answers quickly. That's where SigNoz and OpenTelemetry come in. For the Agents of SigNoz Hackathon 2026 , I integrated SigNoz into my existing MERN Stack e-commerce application called Ram Store and transformed it into a fully observable application. In this blog, I'll walk through what I built, how I instrumented it, the challenges I faced, and what I learned. About the Project Ram Store is a full-stack e-commerce platform built using the MERN Stack. Features User Authentication Product Management Categories & Subcategories Shopping Cart Address Management Order Management MongoDB Database Tech Stack React (Vite) Node.js Express.js MongoDB Docker OpenTelemetry SigNoz Winston Logger Why Observability? Before integrating SigNoz, I could only rely on: console.log() Manual debugging Browser Network tab When something failed, I had questions like: Which API is slow? Why is the response delayed? Which MongoDB query is taking time? How many requests is my backend serving? Where exactly did the error happen? Without observability, finding answers takes time. I wanted a single place where I could monitor everything. That's why I chose SigNoz . Setting Up SigNoz I self-hosted SigNoz locally using Docker. Once all the containers were running successfully, the dashboard became available. After the initial setup, the next step was instrumenting my backend. Integrating OpenTelemetry I added OpenTelemetry to my Node.js backend. Using the Node SDK together with automatic instrumentation, I configured: Express instrumentation HTTP instrumentation MongoDB instrumentation OTLP gRPC exporter Now every request automatically generates telemetry without modifying every route. Distributed Traces One of my favorite features is Distributed Tracing . Whenever I perform an action in Ram Store—like opening products or ad

Over the past few months, I challenged myself to build a complete uptime monitoring platform from scratch. The goal wasn't to build another CRUD application—it was to understand what it actually takes to design, build, and deploy a production-ready SaaS. The result is CheckForge, an uptime monitoring platform that monitors websites, APIs, and SSL certificates while sending alerts through Email, Slack, Discord, and Webhooks. Why I built it Most portfolio projects stop after authentication and dashboards. I wanted to build something that solves real backend engineering problems, including: Background workers Scheduled health checks Incident tracking SSL certificate validation Alert delivery Public status pages SVG uptime badges Production deployment Building these features taught me far more than another tutorial project. Tech Stack Fastify Node.js React Supabase (PostgreSQL) Cloudflare Workers Redis Docker Features HTTP Monitoring SSL Certificate Monitoring Expected Status Code Validation Keyword Monitoring Email Alerts Slack Alerts Discord Alerts Webhook Notifications Incident Timeline Response Time History Public Status Pages SVG Uptime Badges How it works A background worker schedules health checks at regular intervals. Each check is executed through a Cloudflare Worker, which validates: HTTP status Response time SSL certificate Expected content The results are stored in Supabase. If a failure is detected, CheckForge automatically creates an incident and sends notifications through the configured channels. ** What I learned** Building CheckForge forced me to solve problems I hadn't faced before, including: Reliable background scheduling Timeout handling Preventing duplicate alerts Incident lifecycle management SVG badge generation SSL certificate validation Cloudflare Worker integration Production deployment Building an end-to-end SaaS was a completely different experience from building standalone APIs. next set of features : Multi-location monitoring Team workspa

The most misunderstood part of JavaScript — finally explained with analogies, diagrams, and zero hand-waving. If you've ever wondered why setTimeout(fn, 0) doesn't actually run in 0 milliseconds, or why Promises always run before your setTimeout callbacks, or how Node.js handles 10,000 simultaneous users on a single thread — you're about to have several "aha!" moments in a row. Buckle up. ☕ 🎤 Let's Start With an Icebreaker Pop quiz: What is JavaScript? Here's the most famous answer, often attributed to Philip Roberts' legendary JSConf talk: "JavaScript is a single-threaded, non-blocking, asynchronous, concurrent language. It has a Call Stack, an Event Loop, a Callback Queue, and some other APIs." Sounds sophisticated, right? Now ask the V8 engine the same question: "I have a Call Stack and a Memory Heap. I genuinely have no idea what those other things are." 🤯 That's the first paradox. The very features that make JavaScript powerful — the Event Loop, the queues, the async magic — are not part of the JavaScript engine itself . They live somewhere else entirely. Let's find out where. 📦 Part 1: The Basics You Need to Know JavaScript is Single-Threaded At its core, JavaScript has exactly one main thread of execution . This is the Golden Rule : One Thread = One Call Stack = One thing at a time. The Call Stack is a data structure that tracks where you are in your code. When you call a function, it gets pushed onto the stack. When it returns, it gets popped off. It follows a LIFO (Last In, First Out) principle — like a stack of plates. function greet ( name ) { console . log ( `Hello, ${ name } !` ); } function main () { greet ( " Ahmed " ); } main (); // Call Stack (reading bottom to top): // [greet] ← currently running // [main] // [global] Simple, right? But what happens when JavaScript encounters a task that takes time? 🚫 Part 2: The Problem — Blocking Imagine JavaScript has to fetch data from an API. That might take 2 seconds. Or it has to read a huge file from disk.

One of the most confusing topics for beginners in Node.js isn't Express, APIs, or asynchronous programming—it's understanding where npm packages should be installed. When I started learning Node.js, I thought there were only two commands: npm install package-name and npm install -g package-name I knew they both installed packages, but I had no idea when to use which one . Eventually, I realized they solve two completely different problems. If you're learning Node.js, this article will save you from one of the most common beginner mistakes. First, What Does npm Actually Do? npm (Node Package Manager) is the package manager that comes with Node.js. It helps you: Install libraries Manage project dependencies Update packages Share your own packages Run project scripts Whenever you install a package, npm has to decide where to install it. That's where local and global installations come in. Local Installation (The Default) When you run: npm install express npm installs Express inside your current project . Your folder now looks something like this: my-project/ │ ├── node_modules/ ├── package.json ├── package-lock.json └── app.js It also adds Express to your package.json : { "dependencies" : { "express" : "^5.0.0" } } This means: Express belongs to this project. Anyone who clones your repository can simply run: npm install and npm installs everything automatically. That's exactly what you want for project dependencies. Why Local Installation Matters Imagine you're building an API. Your code contains: const express = require ( " express " ); Now imagine another developer clones your project. If Express was installed locally, they only need to run: npm install Everything works. If it wasn't, they'll see something like: Cannot find module 'express' because the dependency isn't part of the project. That's why libraries your application depends on should almost always be installed locally. Global Installation Now consider this command: npm install -g nodemon This installs node

Every party game app I'd used before building this one wanted an account, a lobby website, or a subscription. I wanted the opposite: plug a laptop into the TV, run one command, and have everyone's phone connected in under thirty seconds — no internet required once the LAN is up. That constraint ends up dictating almost every architectural decision in GameNight : a Node/Express/Socket.io server that runs five real-time party games — a Mafia-style social deduction game I call Mongolpuri, UNO, a trivia quiz, Scribble, and Tic-Tac-Toe with tournament brackets — entirely from two in-memory Map s, no database, no auth, no build step on the frontend. Decision 1: A room is a plain object, not a schema const rooms = new Map (); // roomCode -> room const playerRooms = new Map (); // socketId -> roomCode const room = { code , gameType , host : socket . id , players : new Map ([[ socket . id , { id : socket . id , name , avatar }]]), status : ' lobby ' , gameState : null , timers : [], settings : defaultSettings ( gameType ), sessionStats : {}, }; Every game's state — the UNO deck, the Killer/Doctor night phase, the Scribble canvas buffer — lives in room.gameState , an untyped bag shaped differently per gameType . There's no ORM, no room class hierarchy, no GameEngine interface every game implements. Each game gets its own set of top-level functions ( startKD , kdResolveNight , startUno , unoPlayCard , …) that read and mutate room.gameState directly, dispatched through one handleAction switch: function handleAction ( room , socket , data ) { const gs = room . gameState ; if ( ! gs ) return ; switch ( room . gameType ) { case ' tictactoe ' : /* ... */ break ; case ' killerdoctor ' : kdAction ( room , socket , data ); break ; case ' scribble ' : scribbleAction ( room , socket , data ); break ; case ' uno ' : unoAction ( room , socket , data ); break ; case ' quiz ' : quizAction ( room , socket , data ); break ; } } For a five-game server built by one person, this is the right amo

Tokenization → embeddings → causal Transformer → LM head → softmax → loss → backpropagation. No TensorFlow, no PyTorch, and no hidden autograd. Repository: tiny-language-model-neuro-js . Most explanations of language models present correct formulas but hide the path between them inside a framework. I wanted the opposite: one small scenario where every scalar is visible and where the terminal clearly shows incorrect answers before learning and correct answers after it. The project now has one command: node src/train.js --generalize --adaptive-teach It requires Node.js 18.19+ and has no dependencies. The result first The model is queried immediately after random initialization: BEFORE TRAINING — random, usually wrong answers > can human read ? model: ? <unk> ... expected: human can read. [WRONG] > can fish swim ? model: ? <unk> ... expected: fish can swim. [WRONG] > can cat read ? model: ? <unk> ... expected: cat cannot read. [WRONG] After pre-training, SFT, and adaptive SFT, the same model produces: FINAL ANSWERS AFTER ADAPTIVE SFT > can human read ? model: human can read. [CORRECT] > can fish swim ? model: fish can swim. [CORRECT] > can bird fly ? model: bird can fly. [CORRECT] > can cat read ? model: cat cannot read. [CORRECT] Rehearsal controls preserved: 14/14. Stable criterion reached 11 times in a row. The initial text varies because initialization is random. The final acceptance criterion does not: all answers must be correct, every target token must have at least 95% probability, and the complete check must pass more than ten times consecutively. What remains after removing the extra modes The code previously contained several debug and training modes. They were useful while experimenting but obscured the main idea. The final version keeps one educational pipeline: text → word tokenization → token IDs → token + position embeddings → two causal Transformer blocks → multi-head self-attention → two-hidden-layer FFN → LM head → softmax → next-token probabilities

It's easy to reach for the popular tool before asking what your system actually needs. For job queueing, the usual advice is to use RabbitMQ or Kafka. The underlying burden of using these tools will be additional processes to deploy, monitor and reason about. But what if using your existing database is possible? I built a job queueing system with a PostgreSQL database that cleared the bar without adding infrastructure. The next question will be, does this solution meet the criteria of a job queue? A job needs a few things to execute properly within a system. It needs to be persistent, surviving unforeseen crashes. Jobs must not be processed more than once by workers; one job should be processed once by one worker. Also, a job's state has to be tracked through every step. A job state must show when it's pending, completed or failed. That's the bar any solution must clear. With the Postgres approach, persistence comes free. Jobs live in a table so when a worker dies mid-job, the job still exists in a row in the db. Whereas with in-memory queues, a crash loses everything still in memory. A broker like RabbitMQ has to be configured for persistence and if configured wrongly, jobs get lost. A database however is fundamentally built for durability. Now, let's say three workers poll the queue at the same instant and run the same query. They'll see the same pending job at the top and nothing stops them all from grabbing it. If that job is a payment, the customer gets charged three times for one service. All the workers successfully process the job with no indication of an error or alerts. This is the requirement that seems to demand a real message broker, and it's exactly where people assume a database can't compete. It can. Postgres has a specific tool for exactly this. The SQL clause FOR UPDATE is used to lock rows. This can be called on a job when a worker picks it up to process. By default other workers will get blocked during this process, they'll wait for the lock to r

# Module Resolution Algorithm (Part 1): How Node.js Finds the Right Module In the previous article, we explored one of the most fascinating parts of Node.js—the hidden Module Wrapper Function. We learned that every CommonJS module is wrapped inside a function before execution, and we also discovered that require() is not a JavaScript feature. It is provided by the Node.js runtime. But a very important mystery still remains. When we write: const fs = require ( " fs " ); or const math = require ( " ./math " ); how does Node.js know where these modules are located? How does it decide whether "fs" is a built-in module or a file inside your project? Why does require("./math") work even if you don't write .js ? And what happens internally before your code starts executing? The answer lies inside one of Node.js's most important systems: The Module Resolution Algorithm Understanding this algorithm is essential because every Node.js application uses it hundreds or even thousands of times while starting. What is Module Resolution? The word resolution simply means: Finding the actual file represented by the string passed to require() . Suppose you write: require ( " ./math " ); To you, "./math" looks like a file. But for Node.js, it is initially nothing more than a string. "./math" Node cannot execute a string. It needs the real file. So its first job is to answer one question: "Which exact file should I load?" The complete process of converting the string inside require() into an actual file on disk is called Module Resolution . Why Does Node Need a Resolution Algorithm? Imagine a project like this: project/ ├── app.js ├── math.js ├── database.js ├── auth.js └── utils/ ├── logger.js └── helper.js Now look at these statements. require ( " ./math " ); require ( " ./database " ); require ( " ./utils/logger " ); require ( " fs " ); require ( " express " ); All of them look similar. But internally they are completely different. Some point to your own files. Some point to Node's bu

When you're building a multi-tenant SaaS, the first architectural question is usually: how do you keep tenant data isolated? The options range from separate databases per tenant (maximum isolation, maximum cost) to a shared database with row-level filtering (minimum cost, more careful coding required). But there's an equally important question that gets less attention: how does your API know which tenant context a request belongs to? This post covers a pattern we've used in production: a custom request header for tenant scoping, combined with JWT authentication. Simple to implement, easy to audit, and flexible enough to support multi-tenant access from a single user account. The Three Common Approaches 1. Subdomain-based ( tenant.yourdomain.com ) The tenant is encoded in the hostname. Each subdomain routes to the same backend, which extracts the tenant from the Host header. Good: Intuitive, visible in the URL. Bad: Requires wildcard TLS certs, more complex DNS setup, awkward in development, doesn't work for mobile API clients the same way. 2. URL path-based ( /api/tenants/{tenantId}/... ) The tenant identifier is part of every route path. Good: RESTful, self-documenting. Bad: Bloats all route definitions, requires every endpoint to include the tenant segment, makes API versioning messier. 3. Header-based ( x-tenant-id: <id> ) A custom header carries the tenant context. Routes stay clean. The tenant scope is resolved in middleware before the handler runs. Good: Routes stay simple, middleware handles scoping uniformly, works well with JWT auth, easy to test. Bad: Less visible (the tenant isn't in the URL), requires clients to always include the header. We use the header approach. The Implementation The API accepts two forms of auth: A JWT token in the Authorization header — identifies who is making the request A tenant ID in the x-tenant-id header — identifies on behalf of which tenant POST /api/v1/members Authorization: Bearer eyJhbGciOiJIUzI1NiIs... x-tenant-id: ten

The problem Most resilience libraries in the TypeScript ecosystem are tied to HTTP clients (axios-retry, p-retry, Polly.js) or require wrapping your function in a class with a .execute() ceremony. What if you just want to wrap any async function — a database query, an internal service call, a file operation — with retry logic, a timeout, and a circuit breaker, without pulling in heavy dependencies? Enter houhou . What is houhou? Houhou is a zero-dependency TypeScript library (~500 LOC) that wraps any async function with composable resilience policies. The wrapped function keeps the exact same signature — you call it like the original. import { task } from ' houhou ' const charge = task ( chargeCard ) . retry ( 3 ) . timeout ( 10 _000 ) . fallback (() => ({ status : ' pending ' })) await charge ( account , amount ) Policies at a glance Retry Re-execute on failure with fixed or exponential backoff: task ( fetchUser ). retry ( 3 ) // shorthand task ( fetchUser ). retry ({ attempts : 5 , backoff : ' exponential ' , jitter : true , delay : 500 }) Timeout Reject if the function doesn't complete in time: task ( fetchUser ). timeout ( 5000 ) Fallback Run an alternative function on failure: task ( fetchUser ). fallback (() => loadFromCache ( id )) Circuit Breaker Prevent repeated calls to an unhealthy service: task ( queryDb ). circuitBreaker ({ failureThreshold : 5 , successThreshold : 2 , resetTimeout : 30 _000 }) Delay Wait before execution: task ( syncData ). delay ( 1000 ) Policy ordering matters Policies are nested : the last method called wraps the previous ones. Execution order is reverse of declaration order. task ( fn ). retry ( 3 ). timeout ( 1000 ) // → timeout wraps retry // → function runs → retry on failure (up to 3 times) → 1s total timeout // → if the timeout fires, there are no more retries task ( fn ). timeout ( 1000 ). retry ( 3 ) // → retry wraps timeout // → function runs → 1s timeout → if timeout fires, retry catches it // → the whole cycle repeats up

You've probably seen this: Kubernetes probes are green, /health returns 200, CPU isn't on fire - and users are timing out. Process is up. Just not doing anything useful. Classic event loop freeze. Something sync and expensive (or a dumb busy loop) grabs the thread, and suddenly timers, HTTP, DB callbacks - all of it waits. Including your health endpoint, because that also needs the loop. monitorEventLoopDelay() is fine for dashboards. It won't yell at you while the process is stuck, and it definitely won't write a log line from outside the frozen loop. That's the part that annoyed me enough to build this. I made @js-ak/watchdog - tiny N-API addon. The monitor runs in C++ on its own thread and writes JSON lines to stderr/file even while the JS event loop is stuck. Your freeze / recovered handlers only run after the loop unblocks. Optional RSS/CPU, optional stack sample. npm install @js-ak/watchdog const watchdog = require("@js-ak/watchdog"); watchdog.on("freeze", (e) => console.log(e.event, e.duration_ms)); watchdog.on("recovered", (e) => console.log("back after", e.duration_ms, "ms")); watchdog.start({ freezeThresholdMs: 1000, logTarget: "stderr", // or "file" | "both" source: "payments-api", }); Real freezes usually aren't while (true) . More like giant JSON.parse, a cursed regex, sync crypto/compress, or some dependency doing sync I/O on a hot path. Stuff you only notice after people complain. Prebuilds for the usual platforms (Node 22+). MIT. Repo: https://github.com/JS-AK/watchdog Curious how other people catch loop stalls in prod - and what you'd actually want in the freeze payload. Roast the API if it's wrong.

A background worker sits quietly for weeks, chewing through a job queue without incident, and then one Tuesday afternoon it disappears mid-batch, taking forty in-flight jobs down with it. No stack trace pointing at the offending line, no alert until a customer notices their export never finished. Nine times out of ten, the culprit is one of the most under-discussed failure modes in server-side JavaScript: unhandled promise rejections. They are easy to introduce, easy to miss in code review, and in modern Node.js they no longer just print a warning — they can end your process outright. This post walks through what unhandled promise rejections actually are at the engine level, why they are far more dangerous in long-running Node.js services than in typical web requests, how Node's default behavior around them has shifted over the years, and the concrete patterns you can use to stop them from quietly killing your jobs. What an Unhandled Promise Rejection Actually Is At the JavaScript engine level, a promise is a state machine with three possible states: pending, fulfilled, or rejected. When an async operation fails — a network call times out, a database query throws, a JSON parse blows up — the promise representing that operation transitions to the rejected state and carries a reason, usually an Error object. That's all a rejection is: a value flowing down the promise's error channel instead of its success channel. The engine only considers a rejection "handled" if, by the time it does its bookkeeping (which happens on a microtask checkpoint, not synchronously), there is a .catch() handler, a second argument to .then() , or a surrounding try/catch around an await somewhere in that promise's chain. If none of those exist anywhere in the chain, the rejection is classified as unhandled. This is the precise, narrow definition of unhandled promise rejections: a promise that reaches the rejected state with zero handlers attached anywhere along its chain of consumers. It's wo

For quite a while now, I've had the feeling that AI agents are surrounded by this mystical aura....

Express does not validate request input for you. Without a check at the edge, handlers get raw req.body , req.query , and req.params - strings where you expected numbers, missing fields, and shapes that only blow up deep in business logic. Zod is a TypeScript-first schema library. You declare the shape once, infer types with z.infer , and parse at the HTTP boundary so route handlers only see valid data. Invalid input becomes HTTP 400 before your code runs. This post covers Zod 4 schemas ( z.email() , z.uuid() , z.coerce ), Express validation middleware, error formatting and pitfalls. Prerequisites Node.js version 26 Zod 4: npm i zod Express: npm i express and npm i -D @types/express Zod 3 method forms like z.string().email() still work but are deprecated in v4. Prefer the top-level APIs below. Schemas // schemas.ts import { z } from ' zod ' ; export const createUserSchema = z . object ({ email : z . email (), name : z . string (). min ( 1 ). max ( 100 ), age : z . number (). int (). min ( 0 ). max ( 150 ). optional () }); export type CreateUserInput = z . infer < typeof createUserSchema > ; export const userIdParamSchema = z . object ({ id : z . uuid () }); export const listUsersQuerySchema = z . object ({ limit : z . coerce . number (). int (). min ( 1 ). max ( 100 ). default ( 10 ), q : z . string (). trim (). min ( 1 ). optional () }); z.coerce.number() is useful for query strings - HTTP query values arrive as strings. Prefer safeParse over parse at the edge so you control the HTTP status and response body. Format errors once Map ZodError.issues into a stable JSON body, or use Zod 4 helpers z.flattenError() / z.treeifyError() when you want field-keyed or nested shapes. // format-zod-error.ts import { ZodError } from ' zod ' ; export function formatZodError ( error : ZodError ) { return { message : ' Validation failed ' , issues : error . issues . map (( issue ) => ({ path : issue . path . join ( ' . ' ) || ' (root) ' , message : issue . message , code : issue . c

Documentation is often the last thing developers think about—until a broken link frustrates users or a README sends someone to a 404 page. I wanted a simple way to automatically verify links in Markdown documentation during CI, so I built urldn-link-check. It's an open-source GitHub Action and CLI that scans your documentation and reports issues before they're merged. Features ✅ Detect broken links (404/500) ↪️ Detect redirect chains 🔒 Detect insecure HTTP links 📏 Find overly long URLs 📄 Scan Markdown & MDX files ⚡ Fast concurrent scanning 💬 GitHub PR summaries 📊 JSON & Markdown reports Installation npm install -D urldn-link-check or npx urldn-link-check . GitHub Action uses: urldn/link-check@v1 That's it. Every push or pull request can automatically verify your documentation. Why I Built It While maintaining documentation, I noticed that broken links often go unnoticed until someone reports them. Instead of checking them manually, I wanted a lightweight tool that integrates directly into GitHub Actions and fits naturally into a CI workflow. Open Source The project is MIT licensed and contributions are welcome. ⭐ GitHub: https://github.com/urldn/link-check 📦 npm: https://www.npmjs.com/package/urldn-link-check https://www.npmjs.com/package/urldn-link-check This is the first developer tool in the URLDN ecosystem, with more open-source projects planned in the future. If you have ideas or feedback, I'd love to hear them.

It started with the dumbest problem in computing: I'm in bed, a movie is playing on my laptop across the room, and pausing it requires physically getting up . Every existing fix annoyed me in some way. Remote desktop apps are overkill and route through someone's cloud. Remote-control apps want accounts, subscriptions, or a native app install. I just wanted my phone to poke my laptop over my own Wi-Fi. So I built LapDeck : one Node.js process on the laptop, a PWA on the phone. Scan a QR code once and your phone becomes an app launcher, touchpad, keyboard, live screen viewer, and media/power remote. MIT licensed, plain JavaScript, no build step. This post is about the four problems that turned out to be more interesting than I expected. The architecture in one line Phone (PWA) ── WebSocket + MJPEG over Wi-Fi ──► Node.js agent (Windows) The agent serves the PWA, exposes a WebSocket for commands, and streams the screen as MJPEG. The protocol is deliberately dumb JSON envelopes — no protobuf, no RPC framework — so a native Android client or a CLI script can speak it in an afternoon. Windows-specific glue (volume, brightness, power, capture) is isolated in src/win/ , so a macOS/Linux port only has to reimplement that layer. Problem 1: mobile keyboards lie to you The obvious way to build a remote keyboard is to listen for keydown and forward key codes. On mobile, this collapses immediately: swipe typing, autocorrect, and IME composition don't emit per-key events. Android will happily tell you every key is keyCode 229 . The fix: stop listening to keys entirely. I keep a hidden input, and on every input event I diff the field's value against the last known state — compute the common prefix, then emit "delete N chars, type this string" to the laptop. Swipe-type a whole word and the laptop receives one clean text insertion. IME composition, autocorrect rewrites, emoji — all just become diffs. The lesson generalizes: on mobile web, treat the text field as the source of truth, n

A customer clicks the Pay button, the server sends the request to a payment provider, and the charge succeeds. The trouble begins when the response never reaches the browser because the connection drops. The frontend sees a timeout and retries the same request, while the backend treats it as a brand-new payment. One customer action has now created two valid charges. This kind of failure is easy to miss because every part of the system appears to behave correctly on its own. The browser retries because it never received a response, the API processes a valid POST request, and the payment provider accepts the instruction it was given. The defect sits between those systems, where no component has enough context to know that the second request is a repeat. The same pattern can create duplicate orders, emails, subscriptions, shipments, support tickets, or background jobs. The common advice is to retry failed requests, but that advice is incomplete. A retry is safe only when the server can distinguish a repeated business operation from a new one. For payment APIs, that usually means introducing an idempotency key, storing the original result, and protecting the write path against race conditions. The rest of this article walks through that flow using Node.js, Express, and PostgreSQL. The bug starts with a normal-looking endpoint Consider a small Express endpoint that creates a payment by calling an external provider. The code receives the request body, sends the amount and customer data to the provider, and returns the resulting payment object. Nothing about this route looks obviously unsafe during a basic code review, and the happy-path test is likely to pass without trouble. The risk appears only when the request succeeds remotely but the response is lost before the client receives it. `app.post("/payments", async (req, res, next) => { try { const payment = await paymentProvider.charge({ customerId: req.body.customerId, amount: req.body.amount, currency: req.body.currenc