标签：#node

Have you ever wondered how massive modern platforms like Netflix, PayPal, and LinkedIn handle millions of users simultaneously without crashing? The secret weapon behind much of the modern web is Node.js. Traditionally, JavaScript—the language that makes websites interactive—could only run inside a web browser like Chrome or Edge. Node.js changed the game by freeing JavaScript from the browser, allowing it to run directly on your computer. This means you can use it to build backend servers, automate boring computer tasks, or run powerful development tools. If you are intimidated by coding, don't worry. This guide will take you from zero to running your very first Node.js program on Windows, step-by-step. Prerequisites Before we begin, you only need two things: A computer running Windows 10 or 11. An active internet connection to download the installer. No prior coding experience or command-line knowledge is required! Step-by-Step Instructions Download the Node.js Installer First, we need to grab the official installation file. Open your web browser and go to the official website: nodejs.org. You will see two primary options to download. Always choose the LTS (Long Term Support) version. The LTS version is heavily tested, stable, and less likely to give you unexpected errors. Click the Windows Installer button to download the .msi file to your computer. Run the Setup Wizard Once the download finishes, navigate to your Downloads folder and double-click the file to open the setup wizard. Click Next on the welcome screen. Accept the license agreement and click Next. Leave the default installation folder as it is (C:\Program Files\nodejs) and click Next. On the "Custom Setup" screen, leave everything at its default and click Next. Important Step: You will see a checkbox that asks to "Automatically install the necessary tools." Leave this unchecked for now to keep your setup simple and fast. Click Next. Finally, click Install. If Windows asks for permission to make change

How I Built a Zero-Cost Facebook Auto-Poster Using Node.js and GitHub Actions Automating social media management can save hours of manual work. In this guide, I will show you how to build a fully automated, production-ready system that posts daily motivational quotes with images to a Facebook Page— completely for free , running on autopilot via GitHub Actions. We will also tackle a major pain point: resolving Meta's strict token expiration and permission structures by dynamically fetching a Page Access Token using a Meta Business System User, the officially recommended way for secure automation. 🛠️ Prerequisites Before diving into the code, make sure you have: A Facebook Page A Meta Developer Account A Meta Business Suite (Business Portfolio) A GitHub Account Basic knowledge of Node.js 🎯 Step 1: Configuring Meta Architecture for Secure Automation Meta has deprecated direct publish_actions for user tokens, making automated image uploads tricky. The professional way to solve this is by using a System User bound to a Business Portfolio . 1. Create a Meta App Go to the Meta for Developers dashboard. Create a new app, choose Business and pages as the category, and give it a clean name. 2. Link your Facebook Page Inside your App Dashboard, navigate to App Settings -> Advanced . Scroll down to the App Page section and select your target Facebook Page to link it. 3. Setup a System User Go to your Meta Business Settings ( business.facebook.com/settings ). Under Users , click on System Users and create an Admin System User (e.g., Ttp-penguin ). Click Assign Assets , select your Facebook Page, and turn on the Full Control (Everything) toggle. 4. Generate the Permanent Token Click Generate Token for that System User and select your app. Explicitly check these 3 essential scopes : pages_manage_posts pages_read_engagement pages_show_list Copy the generated token ( EAak2B... ). Save this safely —this token acts as our master key! 💻 Step 2: Writing the Automation Script We will wri

Bonus round. Parts 1–3 covered why Node exists, what's happening inside it, and the full request journey. This part mops up the pieces that didn't fit anywhere else — the Express plumbing, error handling, and a checklist to test yourself against. Saturday, Round 4 Nephew: Uncle, one more round? I promise this is the last one for a while. Uncle: pours chai — you said that last time too. Fine, what's bugging you now? Nephew: Small things, actually. express.json() , cookie-parser , express.Router() — I use all of them, copy-pasted from old projects, but I couldn't explain any of them if you asked me directly. Uncle: That's exactly the right instinct — the things you copy-paste without understanding are always the things that break at 2 AM. Let's fix that. Part 4.1 — Two Directions Node Never Confuses Uncle: Before plumbing, one small but important idea that ties Parts 2 and 3 together. Everything Node does falls into exactly two directions . DIRECTION 1 — Incoming Events "The outside world is telling Node something happened" OS → libuv → Event Loop → Your JavaScript Examples: HTTP request arrives, TCP connection opens, WebSocket message arrives DIRECTION 2 — Outgoing Async Operations "Your JavaScript is asking Node to go do something" JavaScript → libuv → Worker Thread → OS → Disk/DB ↓ result comes back through libuv → Event Loop → your callback Examples: fs.readFile(), crypto.pbkdf2(), dns.lookup() Nephew: So an incoming HTTP request and a fs.readFile() call both eventually pass through libuv and the event loop — but they enter from completely opposite directions? Uncle: Exactly. One is the world pushing something at Node. The other is Node reaching out to go get something. Same event loop handles both, but the journey to get there is different — an HTTP request never touches the thread pool; a file read almost always does. Incoming HTTP Request: File Reading: Browser JavaScript | | OS libuv | | libuv Worker Thread | | Event Loop Operating System | | JavaScript Disk |

You've seen the alert. You've opened the PR. You've read the changelog. Then you realize: your code doesn't even call the vulnerable function. Every week. Hundreds of teams drowning in CVE notifications for packages sitting dormant in their node_modules — dependencies they pulled in years ago, bundled by a transitive library, and never actually executed. Meanwhile, the real vulnerabilities get buried. VigilOps is a free Node.js CLI that fixes this. How VigilOps Works VigilOps does three things: Scans dependencies against OSV.dev — the open vulnerability database used by GitHub, PyPI, and npm Runs static reachability analysis to filter out unreachable vulnerabilities (packages in your tree but never called by your code) Auto-opens a GitHub PR with the fix The result: you get one PR with one real vulnerability. Not a spreadsheet. Not a wall of Slack messages. A fix. Demo Here's a quick scan: npx vigilops scan examples/vigilops-demo-lodash And to see everything including suppressed (unreachable) deps: npx vigilops scan examples/vigilops-demo-express --all The --all flag shows what's in your dependency tree but not actually reachable from your code. That's what the noise looks like — and that's what VigilOps filters out. Why This Is Different Dependabot and Snyk scan your entire lockfile. They report every CVE in every package, regardless of whether your code ever touches the vulnerable surface. This creates alert fatigue that causes teams to eventually... stop reading. VigilOps inverts the model: only surface vulnerabilities in code you actually call. Dependabot: "Your project has 47 vulnerabilities" (but 40 are unreachable noise) VigilOps: "Your project has 1 reachable vulnerability. PR is ready." Quick Start npm install -g vigilops npx vigilops scan . Authenticate with GitHub: https://github.com/Vigilops/vigilops npx vigilops auth That's it. The first run will scan, analyze, and open a PR if there's a fixable reachable vulnerability. What's Included OSV.dev integrati

Quick confession: this started as "let me stop babysitting my tests and just make them stay green," and it turned into something a lot bigger. I want to be upfront about where I'm actually trying to take it. I built Claude Basecamp, and as of today it's open source. The reconciliation loop (declare "tests always green," it holds that true) is the part you'll notice first, but it's not really the point. The point is I want this to become the operating system for everything you do with Claude Code, one place that knows about every repo, every session, every routine, every connector, every skill, and every mistake it's ever made, instead of all of that living scattered across terminal windows and dead transcripts. Right now it already covers a decent chunk of that: npx claude-basecamp No install, no config. It finds the projects Claude Code already knows about and opens at http://localhost:4747 . Standing checks , the reconciliation loop. "Tests always green," "dependencies current," "the README documents every CLI flag" — say it once, Basecamp keeps it true, dispatches a fix run when it drifts, and only bugs you for the decisions that actually need a human. Reflexes. It goes back through your old transcripts, finds every time you said "no, don't do that," and turns it into a standing memory that every Claude Code session on your machine checks before touching Bash, Write, or Edit. A mistake made once doesn't get to happen a third time. Session Rescue. Resumes the actual dead session, same session ID, full context, when Claude Code dies mid-task, instead of starting over from scratch. A manager for every repo you just talk to: "keep the tests green," "track this goal," "what's the state of this repo?" Plus routines, background runs, an activity feed, stats, GitHub issue and PR hooks, notifications, webhooks, and a one-click catalog for connectors and skills. That's where it is today. What I actually want it to become is the default place you open whenever you're workin

Kubernetes changed infrastructure forever with one idea: you declare desired state, and the system continuously reconciles reality to match it. I wanted that for my codebase, so I built Claude Basecamp and I'm open-sourcing it today. If you're running Claude Code across more than one repo, I'd genuinely love for you to try it, break it, and help me build it out. Try it in one command npx claude-basecamp No install, no database, no config. It discovers the projects Claude Code already knows about and opens at http://localhost:4747 . Runs on macOS, Linux, and Windows. What it does Standing checks, the reconciliation loop. Declare what must always be true, and Basecamp holds it: tests always green -> runs your suite on a cadence; failures dispatch a fix run that commits dependencies current -> npm outdated; safe updates applied, majors escalated to you issue backlog triaged -> gh-powered labeling and stale-closing anything in plain English -> "the README documents every CLI flag" checked read-only, fixed on drift Checks run against deterministic local facts (your real test suite, real npm outdated) wherever possible, zero tokens spent checking. Drift launches a bounded, budgeted, approval-gated convergence run. Repeated failure escalates to a decision card on Home instead of retrying forever. Reflexes, an immune system for your AI. Basecamp mines every transcript for the moments you pushed back (interruptions, "no, don't", permission denials) and turns each into an antibody. Once armed, every Claude Code session on your machine consults that memory before every Bash/Write/Edit action, so a mistake made twice gets blocked machine-wide before it happens a third time. Session Rescue. Notices when a Claude Code session died mid-task and lets you resume the actual dead session, same session ID, full context, as a background run that finishes the job and commits. A persistent manager for every repo. Each project gets an agent with full Claude Code tools plus control over Bas

Last week I open sourced FableCut , a Premiere-style video editor that runs in the browser and that AI agents can operate. It hit the front page of Hacker News ( thread ), and the questions there made me realize the interesting part isn't the editor. It's one design decision: the project file is the interface. The usual way, and why I flipped it Most AI video tools hide the edit behind an API. You call addClip() , applyFilter() , and the tool owns the state. If you want a human to touch the result, you build a whole collaboration layer. FableCut does the opposite. The entire timeline lives in one JSON document, project.json : media, clips, tracks, keyframes, transitions, markers. The editor UI reads it. The export renders it. And anything that can write JSON can edit video: Claude Code through MCP, a Python script, jq , or you with a text editor. { "id" : "c_title" , "kind" : "text" , "track" : "V3" , "start" : 0 , "duration" : 2.2 , "props" : { "text" : "HANDMADE" , "font" : "Bebas Neue" , "glow" : 45 , "textAnim" : "letter-pop" } } That clip is a glowing kinetic caption. There is no API call that creates it. Writing it into the file IS creating it. SSE as a doorbell, not a data channel The first question on HN was "what's the benefit of SSE here?" Fair question, because the SSE channel does almost nothing, and that's the point. The server watches the project file with fs.watch , debounces 150ms, and pushes the literal string change to the browser. No payload. The browser re-fetches the project and re-renders. The whole mechanism is about 15 lines on a bare node:http server. Why not WebSockets? Because the data only flows one way. Everything that writes (the UI, an agent, a shell script) goes through REST or the filesystem. The browser only ever needs to hear "something changed, go look." An event with no payload can't arrive out of order, and a missed event costs nothing because the next fetch has the latest state anyway. The revision counter, or: how a human and

This post contains Railway referral links. If you sign up through one I get a bit of credit. I build Old Light , a real-time strategy game that runs in the browser. Claim stars, grow an economy, send fleets, all while other players and NPC empires do the same. The second a build finishes or a fleet lands, the server pushes it to every connected client over a WebSocket. That last part, a long-lived server holding an open socket, rules out most of the usual hosts. Here's what it ruled in. Why not Vercel or Netlify Serverless shines when your backend is stateless functions. It's the wrong shape the moment you need a socket that stays open: socket.io wants one process that lives for the whole session, and serverless boots per request and then freezes. You can bolt on a managed WebSocket service, but that's a second system to run and pay for. Railway runs your service as a normal long-lived process, so socket.io just connects. Fly.io does this too with more knobs to turn. I wanted to ship, so Railway won. Monorepo, two services Old Light is an npm workspaces monorepo: a shared types package, an Express plus TypeORM plus socket.io API, and a Vite web app served by a small Express server. On Railway that's two services on the same repo, each with its own root directory and build command, shared built first. They deploy as separate origins, so the web app reads the API's URL from VITE_API_URL . Vite bakes that in at build time, so it's a build variable, not a runtime one. Postgres is a plugin that injects DATABASE_URL , and production runs migrations rather than synchronize . WebSockets need nothing special until you run more than one instance, at which point you'd add a Redis socket.io adapter. I haven't left a single box yet. A healthcheck that stops version skew Two services don't go live at the same instant. Push a commit that touches both, the web finishes first, and for a minute your new frontend is calling API routes that don't exist yet. It 404s, then heals itself o

While researching API changes I noticed something — Google Maps removed DirectionsService on May 1 2026 with no soft fallback. Calls just throw runtime errors after the deadline. Most developers won't know until something breaks. So I built DepRadar — paste your package.json, it checks your exact stack against known deprecations and shows only the ones affecting you, with severity, sunset dates, and migration links. Currently tracks 13 real deprecations across: Google Maps (DirectionsService, DistanceMatrixService removed) OpenAI (Realtime API Beta sunset) AWS SDK v2 (maintenance mode) Microsoft Actionable Messages (retired) moment.js, request package And more Free → depradar.netlify.app Open source → github.com/Ahmed889-code/depradar What deprecations am I missing from your stack?

We have all been there. You are staring at your screen late at night, trying to optimize a bundle size, or debugging an enterprise pipeline that has been failing for three hours straight. The mainstream development community constantly tells us to only install packages that are high performance, audited for security, and strictly necessary for production. But where is the fun in a perfectly clean node_modules folder? Sometimes, the ultimate way to level up your engineering workflow is to inject some absolute chaos into your dependencies. Why spend hours writing robust logic when you can install a library that brings pure irony to your terminal? Let us dive into ten packages that might look completely useless on the surface but are actually the most important modules you will ever encounter in your developer journey. 1. emoji-poop This NPM package lets you use the poop emoji in your output. The emoji is well required in most of the websites as the real fun begins when the site crashes and you can use this poop emoji to showcase the errors with an emoji. This will help the clients get a bit calm after seeing the emoji and the errors. Think about it from a psychological perspective: traditional red stack traces cause immediate client panic, but a well-placed graphical poop emoji introduces a masterclass in modern error mitigation. javascript // npm i emoji-poop const emoji = require('emoji-poop'); console.log(emoji) // 💩 2. thanos-js Who doesn't love Marvel, and Thanos being the strongest villain in the MCU? This package lets you delete files in Thanos fashion. Once you install and run it, it deletes 50% of your files, reducing your stress and giving you less codebase to work with. Yes, it deletes the files for those who are confused about what this package does. It uses fs.unlinkSync to delete the files. Deleting random files from .git would be absolutely evil, and Thanos would love to do it. Exactly half of the files are deleted. Each file is given a chance at random

TL;DR We're adding live streaming to a SaaS dashboard: a backend endpoint that creates a stream, OBS as the broadcaster over RTMPS, LL-HLS playback with hls.js, and a webhook handler that keeps the UI honest. Working "go live" flow in an afternoon. 📦 Code: github.com/USER/repo (replace before publishing) Webinars, coaching sessions, company town halls: sooner or later your product gets the "can users go live?" ticket. The hard parts (ingest servers, transcoding, CDN delivery) are exactly the parts you should not build. We'll use FastPix as the managed layer here; the same flow works nearly line-for-line on Mux, Cloudflare Stream, or api.video. What we're building: A backend endpoint that creates a live stream and returns a stream key An OBS setup broadcasters can follow in two minutes A viewer page playing LL-HLS with hls.js A webhook handler that flips the webinar between scheduled → live → ended 1. Create the stream server-side 🛠️ You need API credentials (Access Token ID + Secret Key). FastPix uses Basic auth on the server API. Node 20.x, plain fetch , no SDK required (though official Node.js/Python/Go/Ruby/PHP/Java/C# SDKs exist if you prefer). // server/routes/streams.js import { Router } from " express " ; const router = Router (); const AUTH = " Basic " + Buffer . from ( ` ${ process . env . FP_TOKEN_ID } : ${ process . env . FP_SECRET } ` ). toString ( " base64 " ); router . post ( " /webinars/:id/stream " , async ( req , res ) => { const r = await fetch ( " https://api.fastpix.io/v1/live/streams " , { method : " POST " , headers : { " Content-Type " : " application/json " , Authorization : AUTH }, body : JSON . stringify ({ playbackSettings : { accessPolicy : " public " }, }), }); if ( ! r . ok ) return res . status ( 502 ). json ({ error : " stream create failed " }); const stream = await r . json (); // persist against your webinar row: // streamId, streamKey (SECRET!), playbackId await db . webinar . update ( req . params . id , { streamId : stream . str

Request lifecycle: một HTTP request đi qua đâu, và vì sao "quên gọi next()" làm request treo cho tới khi socket timeout Một request tới một Express hay Fastify server không phải là "gọi handler rồi trả về response". Nó là một chuỗi các bước theo thứ tự cố định: parse HTTP, chạy qua middleware/hook, match route, gọi handler, serialize, gửi response, đóng. Nếu bất kỳ bước nào không chuyển tiếp — Express không gọi next() , Fastify hook không reply.send() hay không return — request treo cho tới khi client hoặc server timeout đóng socket. Đây là loại lỗi không ném exception, không xuất hiện trong error log, chỉ hiện ra qua p99 latency phình lên và số socket ở trạng thái ESTABLISHED tăng dần. Hiểu chính xác lifecycle này là điều kiện tiên quyết để debug những request "biến mất" và để đặt middleware đúng thứ tự. Cơ chế hoạt động Bước dưới cùng giống nhau ở cả hai framework: Node core http.Server nhận TCP connection, parse HTTP request line + headers, phát event request với hai object IncomingMessage (req) và ServerResponse (res). Điểm khác nhau là những gì framework làm giữa lúc nhận request và lúc response ra khỏi socket. Express dựng một chuỗi middleware qua Router . Mỗi lần app.use(fn) hay app.get(path, fn) được gọi, Express bọc fn vào một Layer với path regex (thông qua path-to-regexp ) rồi push vào một stack. Khi request đến, Router.handle duyệt stack tuần tự: với mỗi layer, nếu path match, gọi fn(req, res, next) . next() là closure trỏ vào layer kế tiếp; chỉ khi nó được gọi thì layer sau mới chạy. Error handler được nhận diện bằng arity — hàm 4 tham số (err, req, res, next) — và chỉ được duyệt tới khi next(err) được gọi: import express from ' express ' const app = express () app . use ( express . json ({ limit : ' 1mb ' })) // 1. parse body app . use (( req , _res , next ) => { // 2. request id req . id = crypto . randomUUID () next () }) app . use (( req , _res , next ) => { // 3. auth const token = req . headers . authorization if ( ! token ) return next ( new Erro

The Problem When building BotForge, our AI no-code chatbot platform, we needed a retrieval system that could handle messy, real-world user queries — typos, partial phrases, semantically similar-but-differently-worded questions. A naive vector search alone wasn't good enough. It's powerful but brittle to out-of-vocabulary terms and exact keyword lookups. The Solution: Four-Tier Parallel Retrieval We ran four retrieval strategies simultaneously using Promise.all\ , then merged results with a weighted scoring function. \ javascript const [semanticResults, textResults, regexResults, fuzzyResults] = await Promise.all([ semanticSearch(query, embeddings), // weight 1.8x mongoFullTextSearch(query), // weight 1.5x regexKeywordSearch(query), // weight 1.0x fuzzyPerWordMatch(query), // weight 0.6x ]) \ \ Tier 1: Semantic Search (1.8× weight) Using Gemini gemini-embedding-2\ to produce 3072-dimensional vectors , we compute cosine similarity against stored document embeddings. This catches meaning — "how do I reset my login?" matches "account recovery options" even with no shared words. Tier 2: MongoDB Full-Text Search (1.5× weight) A native MongoDB Atlas text index for fast, exact keyword hits. Great for technical terms, product names, and precise phrases. Tier 3: Regex Keyword Matching (1.0× weight) Each significant word in the query is compiled to a case-insensitive regex. Catches partial matches and hyphenated variants. Tier 4: Fuzzy Per-Word Matching (0.6× weight) Levenshtein distance matching per query word — handles typos and misspellings like "configuraton" → "configuration". Weighted Score Merging Each result carries a base score from its retrieval strategy. We deduplicate by chunk ID, sum scores across strategies, and sort descending: \ javascript function mergeResults(tiers, weights) { const scoreMap = new Map() tiers.forEach((results, i) => { results.forEach(({ id, score, chunk }) => { const weighted = score * weights[i] scoreMap.set(id, { chunk, total: (scoreMap.get

Node.js 26 has been released, featuring the Temporal API enabled by default, an updated V8 engine to version 14.6, and the Undici HTTP client upgraded to 8.0. The release also removes deprecated legacy APIs. Developers should note migration points related to NODE_MODULE_VERSION changes. Node.js 26 is current for six months before entering long-term support. By Daniel Curtis

I had a /image endpoint capped at 3 requests per minute. Simple express-rate-limit, keyed by IP,...

"Not recommended for beginners." That's what the task sheet said about Level 3 of the Oasis Infobyte Web Development & Design internship. Naturally, that's the one I picked. The Task Level 3 has exactly one task — build a full-stack Pizza Delivery Application. Not a landing page, not a CRUD demo. A real platform: user authentication with email verification, a custom pizza builder, live payments, inventory management, an admin system, and real-time order tracking. The Stack React + Vite + Tailwind on the frontend, Node.js + Express on the backend, MongoDB Atlas for the database, Socket.IO for real-time updates, Razorpay for payments. Deployed across Vercel (frontend) and Railway (backend). What I Built The user journey: register → verify email (Nodemailer) → log in (JWT) → build a pizza in 4 steps (base, sauce, cheese, veggies) with dynamic pricing → pay through Razorpay's checkout → track the order live on a progress bar. The admin side: a separate authenticated dashboard managing a 20-item inventory with low-stock indicators and inline editing, plus order status management. When an admin updates an order's status, the customer's screen updates instantly — no refresh — via Socket.IO rooms per order. Behind the scenes: stock auto-decrements on every successful payment, a node-cron job emails hourly low-stock alerts, and Razorpay payments are verified server-side with HMAC-SHA256 signatures — never trusting the client. What Actually Taught Me Things The features were the syllabus. The debugging was the education. MongoDB Atlas DNS failures — my local machine couldn't resolve mongodb+srv:// connection strings because a VPN was interfering with DNS SRV lookups. Solution: the legacy non-SRV connection string format. Lesson: know what your connection string actually does. Railway's SMTP block — my deployed backend couldn't send verification emails because Railway's free tier blocks outbound SMTP ports entirely. No code fixes this — it's a platform-level restriction. I doc

In-process cron ( node-cron , @nestjs/schedule , OS crontab) runs inside one Node process. That is fine for a single instance, but it does not survive restarts gracefully, deduplicate across replicas, or share infrastructure with your other background jobs. BullMQ stores queues and schedulers in Redis . Job Schedulers (BullMQ 5.16+) are the recommended way to enqueue recurring work on a cron pattern or fixed interval. The same workers that process one-off jobs also process scheduled ones, with retries, backoff, and concurrency you already get from BullMQ. This post covers Job Schedulers in plain Node.js, operations and pitfalls, a NestJS setup with @nestjs/bullmq , and a runnable demo with a fast cron heartbeat and a daily cleanup cron. Prerequisites Node.js version 26 Redis at redis://localhost:6379 (included in the demo docker-compose.yml , or use Postgres and Redis containers with Docker Compose ) npm i bullmq For the NestJS section: npm i @nestjs/bullmq bullmq BullMQ 2.0+ does not require a separate QueueScheduler instance. Use the Job Scheduler API ( upsertJobScheduler ), not the deprecated repeat option on queue.add() . Mental model Piece Role Queue Holds jobs waiting to run Worker Executes jobs Job Scheduler Factory that enqueues jobs on a schedule Scheduled job A job instance produced by a scheduler A scheduler id is stable across deploys. Calling upsertJobScheduler with the same id updates the schedule in place instead of creating duplicates. Queue and worker Share one Redis connection config between the queue and the worker: import { Queue , Worker } from ' bullmq ' ; const connection = { host : ' localhost ' , port : 6379 }; const queue = new Queue ( ' reports ' , { connection }); const worker = new Worker ( ' reports ' , async ( job ) => { console . log ( `[ ${ job . name } ]` , new Date (). toISOString (), job . data ); }, { connection }, ); worker . on ( ' failed ' , ( job , error ) => { console . error ( job ?. name , error . message ); }); Start the

Welcome to this comprehensive comparative guide on API testing! This article is designed to showcase...

Back when we introduced MCP support , we ended on a teaser: Phase 3 would tackle Sampling —letting servers request completions from the host instead of only exposing tools and resources to it. NodeLLM 1.17 delivers on that, and pairs it with a second, unrelated but overdue improvement: precise control over how tool calls execute, now available consistently in both core and the ORM persistence layer. 🔄 MCP Sampling: Closing the Loop Sampling inverts the usual MCP direction. Instead of the client asking the server for tools, the server asks the client to run an LLM completion on its behalf. This lets an MCP server offer LLM-powered capabilities—summarization, classification, drafting—without needing its own API key or provider integration. createLLMSamplingHandler answers those requests using a real NodeLLM instance, so a server's tool ends up powered by whatever model you configure client-side: import { createLLM } from " @node-llm/core " ; import { MCP , createLLMSamplingHandler } from " @node-llm/mcp " ; const llm = createLLM ({ provider : " openai " }); const mcp = await MCP . connect ( { command : " node " , args : [ " ./sampling-server.mjs " ] }, { sampling : createLLMSamplingHandler ( llm , " gpt-4o-mini " ) } ); const tools = await mcp . discoverTools (); // The server only advertises sampling-backed tools once it sees // the client declared sampling support during the handshake. If you need full control over how a sampling request is answered—routing by model hint, injecting your own guardrails—pass a plain handler function instead of { llm, model } . It receives the raw sampling/createMessage params and returns a CreateMessageResult , so you decide exactly how (or whether) to answer. ⚡ Concurrent Tool Execution When a model returns several independent tool calls in the same turn, NodeLLM has always executed them one at a time. That's safe by default, but wastes time when the calls don't depend on each other—three weather lookups for three different cities, s

I reopened an old project and found a working authentication implementation. What I could not find was the reason it looked that way. The commits showed the final code, but not: Why one approach had been chosen Which fixes had already failed What the coding agent warned me about Which tasks had been postponed The answers were scattered across a ChatGPT thread, a Codex session, and a terminal that no longer existed. There was another layer to it. I don't stick to one agent. I move between Codex, Claude Code, Cursor, and plain ChatGPT threads — sometimes because one tool genuinely fits the task better, more often because I simply run out of credits on one and switch to another mid-task. Every time that happened, the new agent started from zero. It had no idea what the previous one had already tried, decided, or ruled out. I either re-explained everything from memory, or let the new agent guess and re-discover things the old one already knew. This is not only a documentation problem. It is a structural problem in AI-assisted development. We use several tools to produce one project, but every tool keeps a separate, temporary memory. That experience became ContextVault. First: what is ContextVault? ContextVault is an open-source, local-first memory layer for AI work. It preserves useful context from browser LLM conversations, terminals, and coding-agent sessions, then makes that context searchable and reusable in later sessions. Think of the distinction this way: Git: what changed in the code? ContextVault: why did we change it, what failed, and what should happen next? The trigger for building it was specifically the agent-switching problem: whenever one agent ran out of credits or hit a limit, I needed the next one to pick up exactly where the last one left off, instead of restarting the investigation. ContextVault has three user-facing surfaces: Browser Capture — a Chrome extension that stores supported LLM conversations locally and exports Markdown or ZIP. Vault Term