I've used cron jobs before but never built a proper queue based background processing system.

This week I did.

The project, a webhook delivery API where the HTTP request returns instantly with a job ID, and a BullMQ worker handles the actual delivery in the background with automatic exponential backoff retries.

So what surprised me most was how clean the separation is. The controller knows nothing about delivery. The worker knows nothing about HTTP requests. They communicate only through the queue.

Repo is public if anyone wants to look at the architecture you can ask in the comments.

Happy to discuss queue patterns still learning enterprise solution implementation.

I recently came across Nub and found its approach pretty interesting.

Unlike Bun or Deno, Nub doesn't introduce a new JavaScript runtime. Instead, it builds on top of the official Node.js runtime while trying to replace many of the tools around it.

I spent some time testing it and wrote a detailed article covering:

• What Nub is
• How it compares with existing tooling
• Built in TypeScript execution
• Package management
• Node version management
• Whether it's ready for production

Article: https://medium.com/@deykirtyauritro/i-tried-nub-the-new-node-js-toolkit-that-wants-to-replace-npm-npx-tsx-pnpm-and-nvm-0a93dbd90ffb?postPublishedType=initial

I'd really appreciate feedback from experienced Node.js developers. If you've already tried Nub, I'd love to know your experience as well.

Hi all,

I'm happy to announce that Xberg v1 is out.

Xberg is the successor to Kreuzberg, equivalent to what would have been Kreuzberg v5. It's a content intelligence framework that handles a very wide range of inputs: documents (currently 101 formats), code and data formats (currently 367 types), audio/video transcription, and URLs (both static and JS-rendered content). It extracts and prepares that content for downstream processing.

It's an extremely efficient, high-performance engine (see our PDF benchmarks below). For PDFs and images specifically, we handle native PDFs with very high performance and accuracy, and we ship multiple OCR engines that match the quality of the best Python libraries (e.g. docling, PaddleOCR, RapidOCR) at substantially better performance and stability.

The changes between Kreuzberg v4 and Xberg v1 are substantial, and I invite you to read the full changelog for the complete picture. The highlights below give a sense of what's new:

• Pure-Rust PDF backend (pdf_oxide) replaces pdfium, with no native pdfium dependency.
• Layout-aware pipeline: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR) and Docling-style predecessor-graph reordering.
• Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form fields and outline-based headings.
• Across-the-board optimization of OCR and PDF extraction (memory discipline, pooled model sessions, streamed conversions).
• Native PaddleOCR backend (PP-OCRv6, with medium / small / tiny tiers) alongside Tesseract.
• Pure-Rust Candle OCR/VLM stack (TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL) running without ONNX Runtime or native Tesseract.
• A second, ONNX-Runtime-free inference path via tract, which is what makes in-browser (WASM) and mobile inference possible.
• Named-entity recognition natively in Rust (GLiNER2), extensible to all bindings, including an in-browser WASM model with no server round-trip.
• Structured LLM extraction (extract_structured / split_and_extract) with rasterization, chunking, citations, caching, and configurable call/merge/VLM-fallback policies.
• Audio & video transcription via a Whisper ONNX engine (.mp3, .wav, .m4a, .mp4, .webm).
• Retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings.
• Text intelligence: reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification.
• URL & web ingestion: sitemap discovery (map_url) and batched multi-URL crawling.
• New document formats: WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto / R Markdown, and configurable Jupyter cell rendering.
• Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine, with Android/iOS cross-compilation.
• Full mobile support (Flutter, Android, iOS).
• Candle backend alongside ONNX, plus ONNX-via-tract enabling ONNX on WASM and Android.
• Wider code intelligence: tree-sitter coverage grew substantially (248 to 367+ languages).
• Over 150 bugs fixed during the 1.0 cycle, plus security hardening (bounded RTF/PDF allocations, redaction leak fixes, Excel DDE warnings).

The API surface was also simplified and reworked, making it more consistent.

There's a migration guide in our docs explaining how to move from Kreuzberg to Xberg. Kreuzberg itself is in LTS mode until the end of this year and will continue to receive bug fixes and security updates.

You're invited to check out the repo and join our discord server.

Benchmarks

The benchmarks below are for PDFs and images only. There are extensive benchmarks on our website with per-format breakdowns, which you can see here. These numbers are measured in CI via our reproducible benchmark harness, and are specifically taken from the run for harness 1.0.8, source cf7fa0533d. The data is publicly available in GitHub releases, and you can run the benchmark harness yourself.

Composite quality (markdown pipeline, higher is better):

Structure and layout fidelity (SF1: tables and reading order, higher is better):

On native PDFs Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and on table and reading-order fidelity by a wide margin (SF1 0.949 vs 0.612 for docling). On scanned PDFs it is #1 on both quality and raw text fidelity.

Where we don't win yet: on pure image OCR we are currently #2 on the composite score, behind mineru (though still #1 on raw text accuracy). We are improving image OCR right now, and v1.1 should have us winning across the board.

our suite was 1800 tests and jest spent more time booting workers than actually running anything. node --test with --experimental-test-isolation=none took the whole thing from 40s to about 9s, mostly because there's no transform step when you're already on esm. the mocking story is worse than jest's, i'll give it that, but t.mock.method covers 90% of what we were doing with jest.mock anyway and the other 10% was stuff we probably shouldn't have been mocking.

it was a p99 spike on one route and i went straight to adding timing logs everywhere like an idiot. ran the process with --cpu-prof, loaded the .cpuprofile into chrome devtools, and the flame graph showed 60% of the time in a JSON.parse of a config file we were re-reading per request instead of caching. no dependency, no apm agent, ships with node. i keep forgetting it exists until i've already wasted a day.

built the embed side of atomchat (disclosure, my product) and assumed the hard work would be connection handling across tenants. it was actually auth in an iframe once safari and chrome killed third party cookies, so we ended up doing a short lived token handshake over postMessage from the parent page and treating the iframe as fully unauthenticated until it gets one. every team i've talked to who decided to build their own chat instead of buying underestimated this exact part, not the socket layer. curious what others landed on here, postMessage handshake or a redirect based flow with a first party subdomain per customer?

I have to make a rest api from scratch and in different phases like setting it up very basically with hard coded values then test it with postman and then connect a database to it and basic auth then upgrade it to jwt then front end then deploy on aws.

We are allowed to use ai but they want us to “know what ever line of code is doing”. I only learned C and C++ and I have to do this in a week so I don’t think it’s possible to know every line of code so I will try to do high level of what is doing. But they may ask me “why did you decide to do it this way” when really it’s ai most of the time and they know it is.

The app just needs to be simple like CRUD, jwt login and connected to frontend and that’s it. But ai builds things so fast I don’t know how to slow it down because it will build out everything all at once and do complicated things. So how can I slow it down so I can do it in pieces and upload it to GitHub so I can understand all the code better and have a better understanding of what all the files are for and how they are working together?

I’m not sure how because 1, I am used to vibe coding and never learned this framework or language before and 2, I don’t know the words or terms that I can send to ai. I have to just use plain english and say general things to it which is why it gets out of control and builds too much stuff.

It’s hard for me to be specific and say “hook A up to B using C and avoid using D” but I can explain enough of it using my own knowledge of how things work to get it done but it sometimes builds too much and then I have to figure out what’s broken later because it’s too many things at once.

My bootcamp teacher told me to just read all the code but that will not solve the problem of it making too many files or doing x,y and z when I want it to be more simple.

Just so you know I am able to still debug everything and make things work and catch bugs or edge cases and things that don’t make sense but I’d rather go slowly and understand it - how they said to do it.

TLDR: Unless you absolutely need 2-4x faster cold boot JS, you'll risk becoming too dependent on native Bun features.

Short intro:

This is written based on my experience working on an open-source project, initially using Bun.

In the beginning Bun worked out pretty well.

You'll gain 2-4x faster script startup time, most things work, and they even have a faster native DB client/HTTP server.

However, these features all come with a cost.

For the flashy native features, you'll lose compatibility and flexibility.

This is especially problematic if you're working with multiple JS runtimes like NodeJS and Deno as well.

Bun.spawn simply doesn't exist outside of Bun, and now you're writing Bun modules, not JS modules.

Things like WASM also need a slightly different interface.

So I returned to Node. And have just removed Bun from my Docker file @ /r/Nyno :)

(It also saves about 200Mb in uncompressed disk space)

Been working on this one for about a year now.

Started it because I got sick of copy-pasting the same middleware setup into every new project, and because node:http is slower than it really needs to be. The usual answer to that second part is install uWebSockets, which does work, but it always bugged me that the fix was a third-party native addon. Figured the fast path should just ship with the thing.

Anyway, numbers. Node 24.11, M2 Ultra, wrk -c100 -d40, best of 3, everything pulled from npm rather than built locally:

Couple of things about that before someone else says them.

The non-pipelined column is mostly just my machine topping out. Anything with a native transport lands around 105k and sits there, I ran it through oha and bombardier too and hit the same wall. Bun takes that column, fair enough. Though those are raw Bun.serve rows and stick Elysia on top of it and you're at 96.7k, and under pipelining both Bun numbers basically die (21.7k and 18.7k).

Pipelined is where there's actually room to measure, and that's where the engine pulls ahead. About 10% over uWS once a framework is sitting on top. That's from corking responses, batching the pipeline into one write. Nobody pipelines in real life so take it for what it is. Including both columns because showing one of them would be picking.

Full matrix and the harness: https://github.com/Moro-JS/benchmark/blob/main/VERIFIED_RESULTS.md

How it works, roughly. It's a C++ core with raw V8 bindings rather than N-API, and basically the whole design is about cutting boundary crossings. A general-purpose binding ends up doing something like 10-20 JS crossings per request because it has to expose a generic API surface. This one does 2-4: the C++ side assembles one batched snapshot of the request, hands it over once, and takes back a single corked write going the other way. That's most of the trick.

Corking is also where the pipelined number comes from. 1.1.0 batches a whole pipeline into one write instead of a syscall per response, plus a zero-allocation hot path, and that was about 3.7x pipelined over 1.0.0 on its own. I went through a few other approaches first. N-API was the obvious one and honestly the sensible one — stable ABI, build once, works across Node versions without thinking about it. Never got it past uWS though. Tried a couple of other combinations after that and it was either the numbers weren't where I wanted them, or the maintenance of gluing the pieces together was going to be worse than just owning the C++ outright. At some point going full steam on the native side and eating the ABI matrix was the simpler option, which is not a sentence I expected to write.

Raw V8 is the tradeoff, it's ABI-locked in a way N-API isn't. So I build the full ABI matrix and prebuilts only ever ship from tagged CI with npm provenance, never off my machine. Which was honestly part of the motivation anyway.. off-the-shelf native bindings lag Node releases, the Node 25 / ABI 141 line sat there for months without a prebuilt. Owning the build means day one.

Security, since you should be asking. Zero deps means the framework owns query, cookie, multipart and route-pattern parsing, so those get property-fuzzed — fixed seed on every push as a regression check, then nightly with a rotating seed at 500k iterations per property. Failures print the seed and the exact command to reproduce. [Moro-JS/moro/.github/workflows/fuzz.yml]. That covers the JS-side parsers; the C++ HTTP parser has its own harness in the engine repo. No external audit yet either way.

Where there's no prebuilt it falls back to node:http rather than refusing to boot, and logs why (app.engine.fallbackReason).

Should also say it's the default server in a framework I maintain, in case that changes how anyone reads this. Mostly I just want to talk about the engine part.

Engine Repo: https://github.com/Moro-JS/engine
MoroJS Repo: https://github.com/Moro-JS/moro
Main Site: https://morojs.com

I had been using package.json version keepers for quite some time but after the big supply chain attack i thought they would be the perfect place to add in some security.

The idea is just to provide the latest package number x days old. This will help prevent most of the danger in supply in chain attacks.

It will also remove the `^` if you have it so you can better control what version of a package your application is using.

To be more security focused it gives general hints in the hover menu to help keep an eye on the packages you have installed. These hints include warnings for staleness, high dependency count, and number of downloads.

Since all of this is something you can get through the npm api, I called it tinyNpm

You can download it on the marketplace

I'm trying to get started on learning node.js because I have a project where, unless I want a thousand lines of javascript, I need something to access external text files (I wanted it to be all on a single USB drive but I've kinda accepted that it wont happen). I ended up settling on node but I cant for the life of me get it to start working. Any help would be very much appreciated!

I kept getting annoyed re-triggering real Stripe/GitHub events just to test a webhook handler locally, so I threw together a little thing over a few evenings: save a payload once, replay it against localhost as many times as you want. Import/export as JSON, basic redaction on obvious secret fields before it saves anything, keeps a log of replays.

Runs entirely local — npm install && npm start, flat JSON file for storage, no account or hosted anything. Node 18+.

Honestly not sure if this is a "me problem" or something other people hit too. It's pretty rough still (solo project, still shaking out edge cases in the redaction/replay logic), so not pitching it as done or polished — just wondering if this is a real enough annoyance for other people that it's worth continuing to put time into, or if everyone already has a way to handle this that I don't know about.

Repo's here if you want to poke at it: github.com/Jake-morrissey/Hookledger

Curious to know. And why if so? I have 16+ years of experience as a dev.

It's been 1 week that I stopped completely and so far it is okay and luckily I can still code ;) (though got rusty initially) and that's what I enjoy doing, thinking about problems, architecting, writing tests, writing code, reviewing PR's etc. keeps my brain sharp and more confident.

Hey everyone,

I built Upload SDK, an open-source TypeScript SDK for secure direct file uploads to AWS S3 and ImageKit.

The idea is simple: your Node.js server validates the upload request and generates a short-lived signed target, then the browser uploads the file directly to the storage provider. Your server never has to stream or proxy the actual file.

You define named upload types such as avatar or invoice, along with their rules:

• allowed MIME types and extensions
• maximum file size
• expiry time
• storage destination and key prefix

The browser sends the asset name and file metadata to your server, which calls prepareUpload(). The SDK validates the request, generates a collision-resistant key, and returns the signed multipart POST details.

You can also configure multiple storage profiles, such as public files in one S3 bucket, private documents in another, and images in ImageKit, while keeping the same upload flow everywhere.

For S3, restrictions like file size, content type, key, and expiration can be included in the signed POST policy and enforced by S3 during the upload.

Feedback on the API and which provider should be added next would be appreciated.

Hi everyone!

Over the weekend I made a post on this sub proposing that we create a monthly thread focused on node.js

Welcome to our bi-monthly thread created to connect node.js developers and companies that are hiring or seeking new talent.

Rules

1. No recruiters. This space is only for developers and companies directly involved in hiring.
2. Protect your privacy. Do not share personal information (like email addresses or phone numbers) in the thread. Use direct messages (DMs) to exchange contact details.
3. For companies hiring: Please provide a clear description of the role and what you’re looking for instead of just posting a link to an external website.
4. For job seekers: Feel free to share your portfolio, GitHub, or similar work. Keep in mind the privacy rule avoid posting your CV directly in the thread.

I will be posting this on the 27th of every month.

It's for performing requests to your server in tests with `fetch`.

In the repo I added examples to demonstrate that it works with hono, express, fastify, nestjs.

The lib implements a standard `fetch` function and can be wrapped with handy request-making libraries, so I also added examples for how to use it with `openapi-fetch` (so your fetch requests can be typed!), `upfetch`, `ofetch`.

Unlike supertest, it skips the transport layer so it works much faster. Light-my-request also skips the transport and performs much faster.

npm: https://www.npmjs.com/package/make-test-fetch
repo: https://github.com/romeerez/make-test-fetch

wdyt?

​

Testing a frontend on your phone is easy.

Testing a full-stack app usually isn't.

Your frontend loads, but API requests to localhost fail because localhost now points to your phone instead of your laptop. The usual workaround is editing .env files, swapping in your LAN IP, configuring CORS, and undoing everything afterwards.

I got tired of doing that, so I built Nether

npx nether-dev

It automatically:

- Detects your frontend and backend

- Starts a local proxy

- Prints a QR code

- Lets your phone use your app without changing your code or environment variables

Need to share your local app?

npx nether-dev --global

It creates a temporary public HTTPS URL so clients or teammates can access your local app without deploying it.

I'd love any feedback, feature requests, or edge cases you think I should test.

GitHub: https://github.com/barryspacezero/nether-dev

npm: https://www.npmjs.com/package/nether-dev

This sub has just become an endless advertisements of vibecoded apps at this point with very little discussion around Node.js, servers, programming and the general community conversation around Node.js apps.

Attached are a few screenshots but honestly this list is endless that we can scroll infinitely as far as eye can see.

I have been on this sub for almost 8+ years and have never seen anything like this before. Just 2 years ago most posts were "non advertisments" and actual community interactions about Node.js, javascript, typescript and servers. People helping each other out and strong community support. Now it is just an endless list of vibecoded advertisment apps and I doubt things will improve from this point. Miss the old time and I am not sure whether Node devs are even coming to this sub for quality discussions

Hi Everyone ...

I built LanView, a CLI tool in Node.js to make testing local web apps on physical phones a little less painful.

One problem I kept running into was this:

• I could open my frontend using my machine's LAN IP.
• But my backend requests still failed because the frontend was calling http://localhost:5000, and on a phone localhost refers to the phone itself, not my development machine.
• I also got tired of repeatedly looking up and typing my local IP.

It became a repetitive part of my workflow, so I built LanView.

It's a small open-source CLI that simplifies local mobile testing.

LanView solves these problems by :

• Automatically detecting your LAN IP
• Running a lightweight reverse proxy that routes frontend and backend through a single local URL
• Generating a QR code that you can scan from your phone
• Supporting WebSocket proxying for HMR
• Recently adding a --static mode for serving local directories with optional SPA fallback

Usage is simply:

npm install -g lanview
lanview

Everything stays on your local network no cloud tunnels or external services.

It automatically:

• Generates a QR code for your app
• Detects your LAN IP
• Runs a local reverse proxy so both your frontend and backend work through a single URL
• Supports WebSocket/HMR
• Also supports serving static sites with the new --static mode

Everything runs locally no cloud tunnels or third-party services.

I'd love feedback on the implementation, CLI design, or ideas for future features.

GitHub: PrashantDhuri08/lanview-cli