标签：#node

Headline: Zod 4 is a rewrite of the TypeScript-first schema validation library, released as the stable major in 2025. Four changes hit my code directly: string formats moved to top-level functions ( z.email() instead of z.string().email() ), the four error options collapsed into one error parameter, error formatting moved to standalone helpers ( z.flattenError , z.treeifyError , z.prettifyError ), and .strict() / .passthrough() became z.strictObject() / z.looseObject() . The deprecated Zod 3 APIs still work with warnings, so I migrated incrementally. Key takeaways Zod 4 is the stable major of the TypeScript-first schema validator, released in 2025; it requires TypeScript 5.5 or newer. String formats are now top-level tree-shakeable functions — z.email() , z.uuid() , z.url() — and z.string().email() is deprecated but still works. A single error parameter replaces Zod 3's message , invalid_type_error , required_error , and errorMap . Error formatting moved to z.flattenError (form fields), z.treeifyError (nested), and z.prettifyError (human-readable string). The zod/mini build exposes the same validators through a functional, tree-shakeable API; z.infer , .parse() , and .safeParse() did not change. I reach for Zod on almost every project to validate untrusted input at the boundary — request bodies, form data, environment variables, API responses. Zod 4 changed enough of the surface that a mechanical upgrade tripped a handful of files, so I mapped exactly what moved. What actually changed in Zod 4? Zod 4 is a ground-up rewrite of the TypeScript-first schema validation library, released as the stable major in 2025. The headline is performance: the Zod team's release notes report large reductions in TypeScript compiler instantiations and faster runtime parsing, which matters most in large codebases where schema types dominate type-check time. Four API changes touched my code directly — string formats moved to top-level functions, the four error options collapsed into one,

My LLM bill kept growing, so I did what seemed obvious: I looked for a cheaper model. That helped a little, but it didn't explain why the bill was growing. The dashboard could tell me how many tokens the application used. It couldn't tell me what those tokens were doing. Were they coming from chat? Document summaries? Background classification? An agent retrying the same tool call? I was trying to optimize a total without knowing which product feature created it. The useful unit wasn't tokens per model . It was tokens per feature . Model-level totals hid the real problem A provider dashboard usually groups usage by model, API key, project, or time period. That is useful for billing, but not always for product decisions. Imagine an application with four LLM-powered features: interactive chat document summarization support-ticket classification an agent that prepares weekly reports If the bill increases by 30%, the model name doesn't explain which feature changed. Maybe chat traffic grew. Maybe summarization started sending entire documents instead of selected sections. Maybe the classifier received a much larger system prompt. Maybe the report agent retried after tool failures and generated the same plan several times. Those problems require completely different fixes. Switching every request to a cheaper model would reduce the bill, but it could also hide the engineering mistake. Tag every request with a feature I started giving every LLM call a small amount of application context: const context = { feature : " document_summary " , operation : " initial_summary " , customer_tier : " pro " }; The model provider doesn't need these fields. They belong in the application's usage record. I avoid using individual user IDs as the primary grouping dimension. For cost analysis, a product feature, workflow, or operation is normally more useful and creates fewer privacy problems. A practical record looks like this: { "timestamp" : "2026-07-22T03:12:48.201Z" , "feature" : "docu

alright let me be real with you for a second i've been building production systems for a few years now, mostly backend with node and nestjs, react and next on top, and the one thing that always drove me absolutely crazy was how performance content online just doesn't respect your time you google "how to optimize react rendering" and you get a medium article with 47 claps that shows you useMemo on a counter app you google "how to optimize node performance" and you get a 2019 blog post that tells you to use async await neither of them has real numbers, neither of them shows you how to actually FIND the problem before you start fixing things, and absolutely none of them connect the frontend and backend story together so i spent the last few months building it myself what i built it's called frontend-backend-performance-mastery and it's structured across 6 levels, each level has a frontend folder (react, next.js, typescript) and a backend folder (node, express, nestjs), and every single folder follows the exact same 3-file structure detect.md — how to find the problem, what to look for, what tools to use, before you even open devtools fix.md — the actual fix, with a before and after, when to apply it, and just as important when NOT to apply it project/ — a fully runnable code example, npm install and npm run dev and you're looking at real numbers on your screen, not a screenshot from someone's laptop from 2021 the 6 levels level 01 — fundamentals: web vitals, profiling, baselines, benchmarking with clinic.js and autocannon level 02 — rendering: ssr vs csr vs ssg, react fiber internals, hydration, response streaming, fast-json-stringify level 03 — caching: react query, swr, service workers, redis, cache-aside pattern, cdn and http headers level 04 — database and api: n+1 queries, cursor pagination that stays fast at 10 million rows, dataloader, query optimization, indexes level 05 — advanced: wasm in next.js, worker threads, piscina, bull queue, grpc, node streams, code

After five years of shipping features at Tittri, the team gave me a piece of feedback that stung a little: I was good, but I only ever built what I was asked to build. And we delivered, end to end, every week. From dashboards to multi-step workflows to third party integrations, all of it to make dense workflows understandable. Somewhere along the way I'd become all about business critical web apps, where the frontend is not just visual, it's how people execute operations reliably. But it just wasn't enough for me. So in January 2026 I stopped waiting to be asked, and pitched an AI integration into a UK-based fintech client's product, one that handles real business loans. When I finally presented the idea to the team and the client, after enough brainstorming and planning and identifying the best way for the brokers to benefit from it, expectations rose. No prior AI integration experience, no matching tutorials, real users, real data, real money. Then I had to actually build it. What is the client and why AI The client is one of the UK's pre-eminent business finance brokers and comparison services that combines advanced technology with a team of finance experts to help small and medium-sized enterprises (SMEs) and their advisors find, compare, and apply for the most appropriate and affordable funding options from across the entire market. The client's B2B product is a commercial finance brokerage SaaS, where brokers manage deals, calls, emails, documents, lenders, AIPs (Agreement In Principle), credit/KYC, corporate structures, properties...etc. The brokers use the SaaS to run the whole lifecycle of a deal, and before AI every single step of it was manual. A typical deal goes like this: An enquiry comes in by call or email, something like "my client needs £400k to buy out a GP partner". The broker gets on a discovery call that can run 30–90 minutes, writes up the notes afterwards, creates the deal, and then starts gathering everything a lender will want to see. Finan

Event-Driven Architecture (EDA) is one of the most popular approaches for building scalable distributed systems. Instead of tightly coupling services through synchronous APIs, services communicate by publishing and consuming events. It sounds perfect. Until your consumers start making API calls for every event they receive. At that point, you've reintroduced the very coupling Event-Driven Architecture was supposed to eliminate. This is where Event-Carried State Transfer (ECST) comes in. The Hidden Problem in Event-Driven Architecture Imagine an e-commerce platform. A customer places an order. The Order Service publishes an event: { "event" : "OrderCreated" , "orderId" : "ORD-10234" } Several services subscribe to this event: Inventory Service Notification Service Analytics Service Shipping Service Billing Service Everything looks asynchronous. But here's what actually happens. Order Created Event │ ▼ Inventory Service │ GET /orders/ORD-10234 │ Order Service Notification Service does the same. Analytics Service does the same. Shipping Service does the same. Suddenly, one event generates dozens of synchronous API calls. Congratulations, You've Recreated a Monolith Your architecture now looks like this: Order Service ▲ ┌───────────┼───────────┐ │ │ │ Inventory Shipping Notification │ │ │ └───────────┼───────────┘ API Requests Although events are being used, every consumer still depends on the Order Service. If the Order Service is unavailable: Notifications fail Inventory updates fail Analytics stop processing Shipping cannot continue The event broker isn't the bottleneck anymore. The originating service is. Event-Carried State Transfer Solves This Instead of publishing only an identifier, publish the data consumers actually need. Instead of this: { "event" : "OrderCreated" , "orderId" : "ORD-10234" } Publish: { "event" : "OrderCreated" , "orderId" : "ORD-10234" , "customerId" : "USR-1001" , "customerName" : "John Doe" , "totalAmount" : 249.99 , "currency" : "USD" , "i

Error handling has a quiet problem. You catch an error deep in a call stack, wrap it in something...

I've been working in software for more than 15 years. This is the first piece I've decided to write about the job. I picked this topic because it was a small, real problem that cost me time more than once, until I finally stopped and fixed it properly. Quick disclaimer: this isn't distributed tracing or multi-service observability. It's a targeted fix for one specific problem: correlating logs within a single Step Function execution. If your scenario is different, the problem takes a different shape. What matters here is the reasoning, not the recipe. Quick context for anyone who doesn't work with serverless: AWS Step Functions is an orchestration service. You design a workflow as a state machine (JSON), and each state usually triggers an AWS Lambda (a function that runs on demand, no server to manage). In my case, a request kicks off a state machine execution that passes through several Lambdas in sequence: some do validation, others call external services, and one waits on a callback response before moving on. The fix turned out to be simpler than it sounds: a field Step Functions already offered for free, and I just wasn't using it. A request was processed 120 days ago. The customer calls: "Did you receive my request? I never heard back." You open the AWS Console. The Step Functions execution is already gone. Execution history only sticks around for 90 days, and even within that window, finding one specific execution among thousands is already a hassle. That leaves CloudWatch, with logs from every Lambda in the pipeline. You have one piece of data: the case ID. But every Lambda logged its own way: no standard, no correlation between them. To reconstruct what happened, you have to open each function's logs in the order the workflow probably ran, and piece it together by hand. It wasn't the error itself that hurt. It was the time lost just organizing the logs before you could actually start investigating. The Chaos The pipeline wasn't huge, but it wasn't trivial ei

My upload CLI looked restart-safe until I tested two failures together: the process crashed at 63%, and the signed resume URL expired before restart. The checkpoint needs identity, not credentials: { "file" : "release.tar.gz" , "fingerprint" : "sha256:..." , "uploadId" : "up_123" , "localOffset" : 66060288 , "updatedAt" : "2026-07-19T12:00:00Z" } Do not persist the signed URL. On restart, exchange the durable upload ID for fresh authorization, query the server offset, then reconcile: const remote = await headUpload ( freshUrl ); if ( remote > file . size ) throw new Error ( " invalid remote offset " ); if ( remote !== checkpoint . localOffset ) { await saveCheckpoint ({ ... checkpoint , localOffset : remote }); } await sendFrom ( file , remote , freshUrl ); The server offset wins because a crash can occur after bytes are accepted but before the local checkpoint is renamed. Save checkpoints through write-to-temp plus atomic rename so a partial JSON file cannot destroy recovery. My fixture matrix includes: Failure Expected behavior crash after remote commit rewind/advance to remote offset expired URL refresh without creating a second upload changed local file stop on fingerprint mismatch missing remote upload ask before starting over checkpoint write interrupted retain previous valid checkpoint The tus resumable upload protocol specifies offset discovery and conflict handling that are useful even if the service uses a smaller custom protocol. The key idea is explicit reconciliation, not assuming client memory is authoritative. I also shipped upload status , upload forget , and an exportable checkpoint directory. Recovery is a user-facing feature; if users cannot inspect or remove state, “resumable” becomes hidden lock-in.

How machine learning supports aircraft maintenance using operational data. Key Takeaways Predictive maintenance estimates component health before failure. Data quality determines model performance. Explainable models support maintenance decisions. Human review remains part of every maintenance action. Model performance requires continuous validation. Introduction Aircraft produce large volumes of operational data. Machine learning converts this data into maintenance support inspection planning and fault detection. What Is Predictive Maintenance? Predictive maintenance estimates the condition of aircraft components using historical and real-time data. The goal is to identify early signs of degradation before a failure affects operations. Traditional maintenance often follows fixed inspection intervals. Data-driven maintenance adds condition-based recommendations using operational evidence. Data Sources Model quality depends on reliable data. Common sources include: Engine sensor readings Flight data recorder information Maintenance records Aircraft utilization history Environmental conditions Component replacement history Incomplete or inaccurate data reduces prediction accuracy. Machine Learning Workflow A typical workflow includes: Collect operational and maintenance data. Remove errors and missing values. Create features from sensor measurements. Train the prediction model. Validate performance using unseen data. Monitor prediction accuracy after deployment. Retrain the model as new data becomes available. Model Selection Different problems require different algorithms. Common choices include: Random Forest XGBoost LightGBM Support Vector Machine Long Short-Term Memory (LSTM) Transformer-based time-series models Model selection depends on the prediction task, dataset size, and operational requirements. Engineering Challenges Data Quality Sensor failures, missing records, and inconsistent maintenance logs reduce model reliability. Class Imbalance Aircraft failures

Most LLM failures are easy to describe and surprisingly hard to reproduce. A user reports that the model returned an empty answer. A tool call disappeared halfway through a stream. One provider rejected a request that worked everywhere else. Then I open the logs and find something like this: LLM request failed: 400 Bad Request Technically true. Operationally useless. The missing piece is usually the exact request shape: model, parameters, message roles, tool definitions, timeout behavior, and the raw provider response. I wanted something smaller than a full observability platform, so I built a request recorder around fetch . It stores enough information to inspect or replay a failed call without logging the API key. What the recorder captures For each request, I want: a unique request ID timestamp and duration URL and model sanitized request body HTTP status raw response body network or timeout errors I deliberately do not record the Authorization header. Prompt content is also redacted by default. Full payload capture must be enabled explicitly because storing production prompts can create a much worse problem than the bug being investigated. The recorder This example runs on Node.js 18 or newer and has no external dependencies. Create recorded-fetch.mjs : import { randomUUID } from " node:crypto " ; import { mkdir , writeFile } from " node:fs/promises " ; import path from " node:path " ; function sanitize ( value , captureContent ) { if ( Array . isArray ( value )) { return value . map (( item ) => sanitize ( item , captureContent )); } if ( ! value || typeof value !== " object " ) { return value ; } const result = {}; for ( const [ key , child ] of Object . entries ( value )) { const normalizedKey = key . toLowerCase (); if ( normalizedKey . includes ( " api_key " ) || normalizedKey . includes ( " apikey " ) || normalizedKey . includes ( " authorization " ) ) { result [ key ] = " [REDACTED] " ; continue ; } if ( ! captureContent && ( normalizedKey === " content "

Every TypeORM project I've worked on grows the same few dangerous lines. I got tired of catching them by hand, so I wrote a linter that does it for me. I was reviewing a pull request a while back and nearly scrolled past this line: await manager . query ( `SELECT * FROM users WHERE id = ${ req . params . id } ` ); Looks fine at a glance. It's a SQL injection hole. The id comes off the request and lands directly in the query string. The thing that bugged me is that I only caught it because I happened to be reading carefully on that line, that day. Review catches this sort of thing a lot of the time. "A lot of the time" is how these end up in production. It's usually not only injection either. The same projects tend to collect a few other habits: synchronize: true in a data source config. It rewrites your schema on startup and can drop a column on the next deploy. A QueryBuilder delete() or update() that hits .execute() with no .where() . Forget that one line and you've changed every row in the table. Three or four writes in one function, none in a transaction, so if the second throws you're left with half-written data. On multi-tenant apps, a query that forgets the tenant filter. That's how one customer sees another customer's data. None of these really need a person to catch them. They're mechanical. A linter can do it on every commit. So I built one. eslint-plugin-typeorm-enterprise npm install --save-dev eslint eslint-plugin-typeorm-enterprise // eslint.config.js const typeormEnterprise = require ( ' eslint-plugin-typeorm-enterprise ' ); module . exports = [ typeormEnterprise . configs . recommended ]; Now those patterns are lint errors. Ten rules today, split into configs ( recommended , strict , performance , multiTenant ): raw SQL, interpolated and concatenated SQL, unsafe QueryBuilder deletes, EntityManager raw queries, writes outside a transaction, tenant scoping, and a nudge to stop counting rows when you only need to know one exists. Two things I was picky

A hospital-network client wanted our system to output patient data in actual FHIR format - the standard interoperability format healthcare systems use to talk to each other - instead of whatever shape we felt like inventing. Made total sense from their side, their EHR software only accepts FHIR resources, not our custom JSON. From my side, it meant I now had to get an LLM to produce a Patient resource that was FHIR R4 compliant, field for field. I opened the FHIR R4 spec page for Patient to see what I was dealing with. Closed the tab about four minutes later. It's not one flat object - names have their own nested structure with use / family / given arrays, telecom is a list of typed contact points, addresses have their own multi-field shape, and half the fields have specific allowed value sets straight out of a separate FHIR terminology spec. This was not going to be a quick z.object({...}) . Two days into hand-writing it, and I wasn't even done I started anyway, because what else was I going to do: const PatientSchema = z . object ({ resourceType : z . literal ( " Patient " ), identifier : z . array ( z . object ({ system : z . string (), value : z . string (), }) ), name : z . array ( z . object ({ use : z . enum ([ " official " , " usual " , " nickname " , " maiden " ]), family : z . string (), given : z . array ( z . string ()), }) ), telecom : z . array ( z . object ({ system : z . enum ([ " phone " , " email " , " fax " ]), value : z . string (), use : z . enum ([ " home " , " work " , " mobile " ]). optional (), }) ), gender : z . enum ([ " male " , " female " , " other " , " unknown " ]), birthDate : z . string (), address : z . array ( z . object ({ use : z . enum ([ " home " , " work " , " temp " ]). optional (), line : z . array ( z . string ()), city : z . string (), state : z . string (), postalCode : z . string (), country : z . string (), }) ), // ...and I still hadn't gotten to maritalStatus, communication, // contact, generalPractitioner, managingOr

LIA is a hyperlocal employability platform I'm building for an isolated coastal district in Brazil — think fixed retail jobs, gigs, and a reputation layer, all matched by proximity instead of routed through a national job board. This post is about the implementation: the actual folder structure, the real RegisterUserUseCase, and the Argon2id decision — pulled straight from the repository, not reconstructed from memory. The Clean Architecture folder structure LIA's backend is organized in four layers, and the direction of dependency is non-negotiable: outer layers depend on inner layers, never the other way around. backend/src/ ├── domain/ │ ├── entities/ │ └── repositories/ # interfaces only ├── application/ │ ├── dto/ │ └── use-cases/ ├── infrastructure/ │ ├── database/ │ └── repositories/ # Prisma implementations ├── presentation/ │ ├── controllers/ │ └── routes/ └── shared/ └── errors/ Let's walk through the registration feature end to end, following that exact order. Domain — the entity and the repository contract The User entity is a plain interface. No decorators, no ORM annotations, no framework leaking in: typescript// domain/entities/user.ts export interface User { id: string; name: string; email: string; password: string; createdAt: Date; updatedAt: Date; } The repository is defined as a contract, not an implementation. The domain doesn't know — and doesn't care — whether it's backed by PostgreSQL, an in-memory map, or something else entirely: typescript// domain/repositories/user.repository.ts import { RegisterUserDTO } from '../../application/dto/register-user.dto.js'; export interface UserRepository { create(data: RegisterUserDTO): Promise<{ id: string; name: string; email: string; createdAt: Date; updatedAt: Date; }>; findByEmail(email: string): Promise<{ id: string; name: string; email: string; password: string; createdAt: Date; updatedAt: Date; } | null>; } Notice create() never returns the password hash. That's not an accident — it's the same "strip

Your AI Agent Needs Tracing, Not Just Logs You've probably already called an LLM from a Node.js backend. That part's easy — every provider ships a solid SDK. The part that actually trips people up is what happens after : turning that one API call into an agent that reasons, uses tools, loops a few times, and still behaves once real users are hitting it. Here's a small, honest pattern for that — plus the one thing most tutorials skip: making the loop debuggable. Why Node.js is doing this job Node has quietly become the default home for the application layer around AI. It's become the preferred middle layer for deploying modern AI agents, wrapping heavier model inference behind fast Node APIs. Python still owns training and the heavy orchestration frameworks — Node owns the gateway, the auth, the streaming UI, and the business logic wrapped around all of it. On the SDK side, things consolidated fast: OpenAI's Node SDK holds roughly a third of weekly npm downloads across the major JS AI SDKs, and Anthropic's TypeScript SDK has grown nearly tenfold in a year. And despite all the framework noise, most production teams just use the Claude or OpenAI SDK directly — reaching for LangChain.js or Mastra only once multi-agent coordination actually earns its keep. The loop: reason, act, repeat Almost every "agent" in 2026 runs on the same loop: reason about the task, act through a tool call, look at what came back, reason again — repeat until done. That's it. The engineering is in the guardrails around it, not the loop itself. // agent.js import Anthropic from " @anthropic-ai/sdk " ; const anthropic = new Anthropic (); // reads ANTHROPIC_API_KEY from env const tools = [ { name : " get_order_status " , description : " Look up the status of a customer order by order ID. " , input_schema : { type : " object " , properties : { orderId : { type : " string " } }, required : [ " orderId " ], }, }, ]; async function getOrderStatus ({ orderId }) { // stand-in for a real DB/service call r

Welcome back to The Everyday Backend Engineer: Practical Design Patterns . In our last post, we made our core algorithms interchangeable using the Strategy Pattern. Today, we close out our design patterns roadmap with arguably the most native pattern in the entire Node.js ecosystem: The Observer Pattern . Let’s look at how to master event-driven decoupling to trigger secondary workflows seamlessly without bloat. 🔴 The Problem: Direct Inline Side-Effects Imagine you are writing a video processing engine or a simple order fulfillment system. When a specific event happens—such as an order being finalized—multiple unrelated departments want a piece of the action: The Notification Service needs to send an SMS and Email receipt. The Logistics Service needs to generate a warehouse fulfillment ticket. The Analytics Service needs to update marketing tracking boards. If you don't decouple these events, your primary execution service ends up managing a giant web of secondary micro-services: // ❌ Bad Practice: The primary service is drowning in secondary dependencies const EmailService = require ( ' ../services/email ' ); const WarehouseService = require ( ' ../services/warehouse ' ); const AnalyticsTracker = require ( ' ../services/analytics ' ); class OrderProcessor { async finalizeOrder ( order ) { console . log ( " Saving primary order to the database... " ); // Core business logic ends here // The codebase smell: Procedural cascading dependencies await EmailService . sendReceipt ( order . userEmail ); await WarehouseService . createShipment ( order . id ); await AnalyticsTracker . trackSale ( order . totalAmount ); } } module . exports = OrderProcessor ; Why does this slow your system down? Your core OrderProcessor is now structurally dependent on three separate systems. If the AnalyticsTracker throws a network timeout error or if the warehouse API changes its interface, your core transaction fails or hangs. Furthermore, adding a fourth side-effect (like an auditing logger

Hackathons are intense. You've got a brilliant idea, a tight deadline, and often, limited sleep. The last thing you want is to spend half your precious time wrestling with database boilerplate, ORM setup, or SQL query syntax. This guide will walk you through building a functional Node.js backend for your hackathon project, focusing on speed and minimal friction, so you can spend more time on your core idea. The Hackathon Backend Challenge Typically, setting up a database and its interaction layer involves several steps: Schema Definition: Deciding on tables/collections, fields, types, and relationships. ORM/Driver Setup: Installing and configuring your database driver or ORM (e.g., Mongoose, Sequelize). Model Creation: Translating your schema into code, often with verbose syntax. Query Writing: Crafting SELECT , INSERT , UPDATE , DELETE statements or ORM methods for every data operation. Debugging: Fixing typos, schema mismatches, and complex join logic. This process, while fundamental, eats up valuable time that could be spent on features, UI, or even sleep. For a hackathon, you need to iterate rapidly, and database interactions should be the least of your worries. Strategy 1: Embrace Simplicity For many hackathon projects, you don't need highly optimized, production-grade queries from day one. You need functional queries that work quickly. Focus on getting data in and out reliably. Strategy 2: Natural Language for Data Modeling Instead of writing verbose schema definitions, think about how you'd describe your data to a non-technical person. For example, if you're building a task management app, you might say: "We need a collection of tasks. Each task has a title, a description, a due date, and a status (like 'pending' or 'completed'). Each task belongs to one user." This natural language description contains all the essential information for a data model, including relationships and field types. Strategy 3: Expressive Querying Similarly, when you need to fetch dat

Imagine you're loading a dashboard. Four widgets, four APIs, fire them all at once: const [ users , revenue , alerts , activity ] = await Promise . all ([ fetchUsers (), fetchRevenue (), fetchAlerts (), fetchActivity (), ]); The alerts API is occasionally slow and sometimes returns a 500. When it does, your entire dashboard fails. Not one broken widget — four broken widgets. Promise.all rejects on the first failure and takes the other three successful results with it into the void. You reached for the right primitive for concurrency, but the wrong one for this use case. The four methods and what they actually do JavaScript gives you four ways to run promises concurrently. They differ in one thing: what happens when a promise fails or resolves first. Method Resolves when Rejects when Promise.all All succeed Any one fails Promise.allSettled All finish (success or failure) Never Promise.any Any one succeeds All fail Promise.race Any one finishes Any one fails first The instinct to reach for Promise.all is understandable — it returns all the values in a single array and feels like the obvious way to "do these things at the same time." But concurrency and failure handling are two separate questions. Promise.all answers both at once, and the answer to the second one is often wrong for the situation you're in. 🎮 Try it yourself ▶️ Open the interactive playground → Runs right in your browser — poke at it and watch the concept react live. Promise.allSettled — partial success Promise.allSettled waits for every promise to settle — resolve or reject — and returns a result array describing what happened to each one: const results = await Promise . allSettled ([ fetchUsers (), fetchRevenue (), fetchAlerts (), fetchActivity (), ]); for ( const result of results ) { if ( result . status === ' fulfilled ' ) { console . log ( ' got data: ' , result . value ); } else { console . error ( ' failed: ' , result . reason ); } } Each element has a status of 'fulfilled' (with a value ) or 'r

Episode 1 established the mindset: failure is normal, not a sign of bad engineering. Episode 2 gets specific — you can't detect or handle a failure you can't even name. Saturday, Round 2 👦 Nephew: Uncle, last time you convinced me failure is basically guaranteed. Fine, I accept it. So what actually fails ? 👨‍🦳 Uncle: You tell me. Start listing things that could go wrong in your app right now. 👦 Nephew: Uh... the server could crash. The database could go down. My code could have a bug. 👨‍🦳 Uncle: Keep going. 👦 Nephew: The network? Someone could deploy the wrong thing? Payment gateway dies mid-checkout? 👨‍🦳 Uncle: You just named six of the seven categories without trying. You already know this. You've just never sorted it. 1. Hardware Failure 2. Software Failure 3. Network Failure 4. Database Failure 5. Third-Party Failure 6. Human Error 7. Resource Exhaustion 👦 Nephew: Then why do we need the list at all, if I already know it instinctively? 👨‍🦳 Uncle: Because "instinctively" isn't fast enough at 2 AM. Let's trace each one properly. Part 1 — Hardware Failure 👦 Nephew: This one's obvious anyway — I deploy to AWS. The cloud hides hardware failure from me. 👨‍🦳 Uncle: Does it? 👦 Nephew: ...doesn't it? That's the whole point of paying for EC2 instead of buying a server. 👨‍🦳 Uncle: Let's trace it. Your app sits on an EC2 instance. What's underneath the instance? 👦 Nephew: Virtual machine stuff, I guess? 👨‍🦳 Uncle: And underneath that ? 👦 Nephew: ...an actual physical machine somewhere. In a data center. 👨‍🦳 Uncle: There it is. Your app | "Virtual" server (EC2/Droplet) | ACTUAL physical hardware somewhere in a data center | Still capable of failing — just less visible to you 👦 Nephew: So it's not hidden. It's just one layer further away than I thought. 👨‍🦳 Uncle: Exactly. AWS absorbs a lot of it — that's part of what you're paying for — but disks still fail, instances still get abruptly terminated, whole availability zones still go down. That's Hardware Failure . Hardware Fa

Why async matters for video I've been running useKnockout - a background removal API that processes images in ~200ms - for a few months. Images are fast enough to handle synchronously: POST a file, wait 200ms, get a PNG back. Video is different. Even a 5-second clip at 30fps is 150 frames. At 200ms per frame, that's 30 seconds of processing. You can't hold an HTTP connection open for 30 seconds and call it a good API. So today I shipped POST /video/remove - async video background removal that returns a job ID immediately, processes in the background, and gives you ProRes 4444 (RGB+alpha) when it's done. What shipped As of v0.11.0 (July 10, 2026): POST /video/remove - upload a video, get a job ID back GET /jobs/{job_id} - poll for status, download the result when ready ProRes 4444 output - RGB with full alpha channel, ready to drop into Premiere/Final Cut/DaVinci Node SDK videoRemove() and getJob() in v0.7.0 Python SDK video_remove() and get_job() in v0.7.0 Billing is a dedicated video.seconds meter at $0.10/sec (different from the per-image rate), with a 15-second cap to keep costs predictable. How to use it (Node SDK) import { useKnockout } from ' useknockout-node ' ; import fs from ' fs ' ; const client = useKnockout ({ apiKey : process . env . KNOCKOUT_API_KEY }); // Submit the video const job = await client . videoRemove ({ file : fs . createReadStream ( ' ./input.mp4 ' ) }); console . log ( ' Job ID: ' , job . id ); // Poll until done let status = await client . getJob ( job . id ); while ( status . status === ' processing ' ) { await new Promise ( resolve => setTimeout ( resolve , 2000 )); status = await client . getJob ( job . id ); } if ( status . status === ' completed ' ) { // Download the ProRes 4444 result const video = await fetch ( status . result_url ); const buffer = await video . arrayBuffer (); fs . writeFileSync ( ' ./output.mov ' , Buffer . from ( buffer )); } The job object includes duration_seconds (billed amount), status ( processing / complet

If you've ever tried to duplicate a Keycloak realm on the same server — say, to spin up a myrealm-dev realm alongside your existing myrealm — you've probably hit this wall: Export the realm from the Admin Console ( Realm settings → Action → Partial export , with clients and groups/roles included). Rename it in a text editor, or in the import dialog's "realm name" field. Import it back into the same Keycloak instance. Watch it fail with: ERROR: duplicate key value violates unique constraint "constraint_a" Detail: Key (id)=(51e1a26d-c24f-4454-9a34-708f1fc14917) already exists. Why this happens A realm export isn't just configuration — it's a snapshot of database rows. Every role, client, user, protocol mapper, component, and authentication flow in the export carries the same internal UUID it has in the live database. Renaming the realm field changes what the realm is called , but it does nothing to the dozens (often hundreds) of UUIDs referenced throughout the file. Import that JSON into the instance it came from, and Keycloak tries to insert rows whose primary keys already exist. Every single one collides. This is a known limitation, tracked upstream as keycloak/keycloak#24770 . Keycloak's exporter was never designed to produce an import-anywhere-including-here artifact — it assumes you're moving the realm to a different instance (dev → staging → prod), where the UUID space is independent. The manual fix (and why it doesn't scale) In principle you can fix this by hand: open the export JSON, find every UUID, and replace it with a fresh one, while keeping track of which old UUID maps to which new UUID so that references between objects (a role's containerId , a client's serviceAccountClientId , a flow's execution list) still point at the right thing after the rewrite. For a small realm with a handful of clients this is tedious but doable in an editor with careful find-and-replace. For a realm with custom roles, several clients, an identity provider, and a full set of a