The Node (and more) Banter

Platformatic

The Node (and more) Banter is your weekly dose of unfiltered, unscripted conversations between Luca Maraschi and Matteo Collina. We explore the edge cases, the anti-patterns, and the things no one puts in the docs. From distributed architecture to platform pitfalls and how enterprises tackle modern development—nothing’s off-limits. It’s not just Node.js®—it’s everything around it, wrapped in sharp banter, war stories, and real-world insight. The sky’s the limit.

  1. 5d ago

    The Sandbox Was Fine. JavaScript Wasn't

    On September 15, Accomplish AI revealed Heapjack, a method that lets someone run any command from OpenAI Codex Desktop, even in its strictest read-only mode, without asking for approval. If you clone a repo and ask a question, the repo’s author could take control of your machine. The issue was reported on August 12 and fixed in eight days. The headline claims the sandbox was escaped, but Matteo and Luca, looking at it from a Node.js perspective, see a different story. The macOS sandbox actually worked. The real problem was with the JavaScript inside: OpenAI ran both its trusted code and the agent’s untrusted code in the same Node process, separated only by a vm context and a secret token. The untrusted code took a heap snapshot, found the token, and sent fake commands through the same channel as the trusted code. A context is not a sandbox. The Node documentation has made this clear, in bold, since 2017. This discussion is about why teams keep making this mistake and what a better design would look like. Matteo and Luca talk about: ✅ What the vm module is really meant for, and why new teams often confuse "context" with "sandbox" every few years ✅ The appealing but incorrect idea that V8’s sandbox could have stopped this, and what Node’s actual position is on the matter ✅ Why a token that lives next to the code it is meant to keep out is not a secret ✅ What OpenAI seems to have changed, and why people outside the company cannot confirm it ✅ Platformatic’s new secure-eval-worker shows what it looks like to run untrusted JavaScript inside Node when you take the warnings seriously. The most honest part is the README, which clearly explains where the security boundary stops. There is a lesson from nine years ago: the system that decides what is allowed should not run inside the thing it is supposed to control. Homework: Before you release an agent, read the second sentence of the vm documentation.

  2. Sep 9

    The HTTP/2 Bugs Hiding in Plain Sight

    Most develpors skip release notes. You update a library, the tests pass, you deploy, and everything seems fine. Later, someone spots that 0.025% of requests are failing; not enough to set off alarms, but too steady to ignore. This is what happens with the HTTP/2 upgrade you might not have noticed. Undici 8 and Node 26 now automatically use HTTP/2 if the server prefers it, so if your internal load balancer advertises HTTP/2, you’ve switched over without changing any code. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about the HTTP/2 bugs that showed up when real users started running into this new default. There were two bugs in Undici and one in HAProxy's Edge Ingress Controller. All of them were quiet, hard to reproduce, and shared a common cause: a GOAWAY packet that should have triggered a transparent retry was treated as an error, and a race condition in Undici's pool was closing active connections it thought were idle. In this episode, we cover: ✅ How ALPN protocol negotiation works, and why updating Undici quietly shifted internal traffic to HTTP/2 without anyone noticing ✅ The GOAWAY bug: why Undici sent a server's graceful reconnect signal back to the user as an error instead of handling it smoothly as the RFC requires ✅ The race condition in Undici's pool and client counters, and how in-flight requests were dropped when the pool closed a connection it thought was idle ✅ The HAProxy bug that made things worse, and why a protocol that has existed for years still causes problems in production infrastructure The takeaway? HTTP/2 is a powerful protocol with features like multiplexed streams, no head-of-line blocking at the application layer, and better resource use at the kernel level. But in a private Kubernetes network with low latency and no packet loss, the benefits are not as clear. If your infrastructure upgrades in the background, you need to find out what breaks before your error rate goes up.

  3. Sep 2

    Will AI Kill the Framework?

    There's a growing belief that AI-generated code is so fast and cheap that foundational, general-purpose tools are obsolete. The argument goes: why optimize for everyone when you can generate code tailored to each workload? Some claim frameworks are outdated and the future is ad-hoc and disposable. Luca and Matteo challenge this view with benchmarks, white papers, and production experience. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina argue that AI increases the need for foundational infrastructure. AI can generate code, but it doesn't account for Event-Loop Utilization. It misses why async gzip on a single-core container can create an unbounded queue and OOM-kill a process in 300 milliseconds. It does not manage version skew, worker lifecycle, or cluster-wide scheduling. The runtime handles these. As AI accelerates workload delivery, the foundational layer becomes more critical. In this episode, we cover: ✅ Why the "ad hoc is cheaper" argument fails when you examine what frameworks actually provide and what AI-generated code assumes is already managed ✅ Watt as a foundational layer: lifecycle management, ELU-based scaling, worker health, and scheduled task coordination are not features that can be generated on demand and discarded ✅ The white papers for proactive and ahead-of-time scheduling show that the hardest infrastructure problems require accumulated domain knowledge, not a new solution for each workload ✅ How the growth of AI workloads is driving the need for a new foundational layer, and why teams that invest in building it now will shape the next decade of the stack The takeaway? AI makes the case for investing in foundational infrastructure stronger than ever. As AI generates more code, it relies on a runtime that understands Node.js internals, manages the operational layer, and is resilient to production failure modes. Frameworks are not legacy thinking. They are what make AI-generated code safe to deploy.

  4. Aug 26

    Every Week the Same Spike. Every Week Your Autoscaler Is Surprised.

    Every Friday evening, your traffic goes up. Each weekday morning, your app becomes active again. Overnight, things slow down. Your autoscaler has seen this pattern many times, but tomorrow it will act like it’s new. It waits for a metric to cross a threshold, then starts adding capacity, which means you get a period of slower performance while the pods catch up. The real issue isn’t the pattern; it’s that the system keeps forgetting. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk with Ivan Tymoshenko, Staff Software Engineer at Platformatic, about the ICC Planner. This new layer sits on top of ICC's real-time scaler and looks ahead from seconds to weeks. Instead of treating every traffic spike like it’s new, the Planner learns repeating capacity patterns from ICC's ELU and heap signals, predicts pod demand by time of day, and turns those patterns into suggestions that operators can review, compare with past data, and approve. When a suggestion is accepted, capacity is ready before the expected load arrives, so you’re not always playing catch-up. In this episode, we cover: ✅ Why real-time scalers always miss the first few seconds of recurring demand, and why short-horizon algorithms can’t solve calendar-based issues ✅ How the Planner uses ELU and heap signals instead of just request counts, and why this matters for workloads that seem similar but are actually different ✅ The difference between baseline suggestions and pattern suggestions, and how the rules allow Friday-specific and everyday settings to work together without conflict ✅ Why accepted suggestions are snapshots that operators control, not live model outputs, and what this means for production safety when the model updates overnight The takeaway? Reactive scaling and scheduled scaling are usually seen as separate options, but ICC combines them into one control loop. The Planner takes care of what history can predict, while the live scaler manages the unexpected. This way, your Friday peak gets the needed capacity before the first request comes in, and you don’t have to pay for extra capacity the rest of the week.

  5. Aug 19

    Who Gets to Decide When You Can Use AI?

    Matteo works on cybersecurity for Node.js every day. AI has become essential for managing the flood of new vulnerabilities. Still, Fable blocks anything that interacts with a pointer, Anthropic's frontier models are off-limits for security research, and the US government can change the rules at any time. This leaves open source maintainers and security researchers without good options. So Matteo decided to run AI models locally. Luckily, the creator of Redis had already built just what he needed. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about Dwarf Star IV, Salvatore Sanfilippo's custom setup for running open-weight models locally. They discuss what it really takes to run a 304 billion parameter model on regular hardware. The conversation covers everything from the aggressive quantization technique that fits DeepSeek V4 Flash into 128 gigabytes, to the real challenges of self-hosted AI, like power outages, hot European summers, and NAS units overheating while you're away. It's a straightforward look at what AI sovereignty means in real life. In this episode, we cover: ✅ How Salvatore's quantization technique keeps the routing layer at high precision while pushing the experts down to two bits, and why that's what makes a 304B model fit on a MacBook Pro or a GB10 ✅ Why frontier models are effectively blocked for Node.js security work, and why that may be putting everyone at more risk, not less ✅ The freshman who found a valid, convoluted vulnerability using Kimi, and what it says about AI democratizing security research on both sides of the fence ✅ Why the spike in downloads for Keet, data retention laws, EU chat control, and companies running their own AI hardware are all the same story: infrastructure freedom is winning The takeaway? The gap between what frontier models can do and what they'll let you do is becoming a real problem for legitimate security work. Local models close that gap, but the entry cost is still high, and the capability gap is real. What's changing is that the reasons to go local are no longer just technical. They're political.

  6. Aug 12

    Should You Block the Event Loop?

    Every Node.js developer learns the same rule on day one: never block the event loop. Async is good, sync is bad, and the libuv thread pool is your friend. Then a real customer brought Luca and Matteo a compression problem that turned all of that upside down. Turns out, the rule is only half the story, and the other half can bring your app down. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina dig into one of the most counterintuitive findings they've encountered while working with a customer: that for CPU-bound operations like gzip compression, async code running on a single core doesn't just underperform; it creates an unbounded queue that can take your application down with an out-of-memory explosion. And sync, the approach everyone told you to avoid, can give you a 50 to 120 percent throughput improvement. In this episode, we cover: ✅ Why the libuv thread pool becomes a bottleneck when Node.js is deployed on a single core, and why four async threads competing for one CPU is worse than doing it synchronously ✅ The hidden DoS risk in async compression: why the main thread keeps accepting requests while the libuv queue grows out of bounds and runs you out of memory ✅ Why event loop delay alone is not enough, and why Event Loop Utilization tells you what delay misses entirely when doing CPU-bound async work ✅ The PR Matteo opened to fastify-compress based on these findings, and the numbers that came out of it The takeaway? Async is not always better. For CPU-bound operations like compression and cryptography, the overhead of thread contention on a single core can cost you more than the event loop block you were trying to avoid. The right answer depends on whether you can control back pressure from your source, and most teams haven't asked that question yet.

About

The Node (and more) Banter is your weekly dose of unfiltered, unscripted conversations between Luca Maraschi and Matteo Collina. We explore the edge cases, the anti-patterns, and the things no one puts in the docs. From distributed architecture to platform pitfalls and how enterprises tackle modern development—nothing’s off-limits. It’s not just Node.js®—it’s everything around it, wrapped in sharp banter, war stories, and real-world insight. The sky’s the limit.

You Might Also Like