The Node (and more) Banter

Platformatic
  • 0.0 (0)
  • Technology
  • Updated Weekly

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

    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.

  2. 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.

  3. 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.

  4. Aug 5

    Nitro Builds the Server. Who Runs the Fleet?

    Nitro gives you a clean, portable server. Whether you use it on its own or with Vite, you get consistent builds, familiar routing, and a smooth development workflow. But Nitro doesn’t explain what to do when you have several instances and a cron job, or when you need a gateway, metrics, and worker health checks. Nitro handles the server, but someone still has to manage the whole fleet. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk with Paolo Insogna, Principal Software Engineer at Platformatic, about @platformatic/nitro. This new Watt feature connects Nitro to the Watt runtime without changing your server, build, or development workflow. No matter if you use a standalone Nitro API, a Vite-plus-Nitro frontend, or an app built with Lovable, Watt takes care of operations while Nitro keeps working as usual. In this episode, we cover: ✅ How @platformatic/nitro works for both standalone Nitro apps and Vite applications that use Nitro as a plugin, and why the distinction matters for your development workflow ✅ What Watt adds without changing your app: gateway integration, HTTP metrics, HTTPS, Event Loop Utilization monitoring, and multi-worker reusePort support ✅ The duplicate scheduled task problem. Why Nitro starts a cron timer inside every instance, and what @platformatic/nitro/scheduler does to give Watt ownership of the clock ✅ How ICC takes over cluster-wide scheduling: one cron per job across the entire fleet, with run history, pause controls, and healthy-instance targeting, while your task code stays inside Nitro The takeaway? Nitro is great at building servers. It was never designed to run a fleet. One line in nitro.config is all it takes to hand the operational layer to Watt and ICC, and your routes, handlers, build output, and scheduled tasks stay exactly where they are.

  5. Jul 29

    Your Bug Fix Will Never Reach the Runs That Need It

    You spot a critical bug in production, fix it, deploy, and feel relieved. But then you notice the workflows that need the fix most, like 30-day subscription cycles, compliance timers paused for months, or approvals waiting on a signature, are still stuck on the old version. They never get the fix. That’s not a safety net. It’s a risk that never disappears. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina discuss Platformatic’s new research paper on the Workflow Upgrade Risk model, or WUR. This data-driven method replaces the usual “pin everything” approach with a measurable score. Using only the telemetry your workflow engine already saves, WUR rates each in-flight run and shows which ones can safely move to the new version, which need a human check, and which really must stay pinned. No dry runs, sandboxes, or shadow execution needed. In this episode, we cover: ✅ Why pinning by default isn’t the best choice for enterprise workflows, and what “forgone-fix exposure” really costs your organization ✅ How the WUR model uses your engine’s existing event log to create an upgrade risk score for each run, and why having zero false negatives across 64,920 verdicts is important ✅ The three-part policy that replaces the simple pin-or-deploy choice: migrate what’s proven safe, review what’s uncertain, and only pin what’s truly incompatible ✅ Why the model backs up what engineers have always thought: small, frequent deployments are safer. Plus, how WUR lets you break any release into a series of deployments, each with a clear risk limit. The takeaway? Durable workflow engines already pay the storage cost of complete execution histories. The WUR model converts that cost into an analytical asset. For any enterprise running long-lived workflows, payment processing, compliance, approvals, drip campaigns, the question is no longer "is it safe to deploy?" It is "which runs are safe to move, and which ones do we owe a fix to?" Now you can answer both before you ship.

  6. Jul 22

    Are Your AI Agents Really Production Ready?

    Eve is a well-designed open-source agent framework. It offers a clean programming model, filesystem-based instructions and tools, and durable sessions built on the Workflow SDK. However, running Eve in a real enterprise Kubernetes environment needs extra infrastructure that isn't included by default. We built that missing piece, and in this episode, we share the full story of how Watt made it possible. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina are joined by Paolo Insogna, Principal Software Engineer at Platformatic. Together, they walk through every integration point between Eve and Watt, covering everything from standalone agents to Eve embedded inside Next.js applications, from self-hosted workflow state with @platformatic/world to distributed step execution across Kubernetes pods and workers. In this episode, we cover: ✅ How @platformatic/eve connects Eve to Watt as a first-class capability, giving it lifecycle management, HTTP metrics, and a production runtime without any changes to your agent code ✅ How @platformatic/world replaces Vercel's hosted workflow infrastructure with PostgreSQL-backed state, queues, and retries that run inside your own cluster ✅ How Eve steps are distributed across Kubernetes pods and Watt workers, and how ICC manages retries when a process stops in the middle of a step ✅ The role of skew protection in durable workflow execution, why a workflow that starts on version 1 must finish on version 1, and how ICC and the Workflow Service work together to enforce that guarantee The takeaway? Eve manages the agent model. Watt and ICC take care of everything that Kubernetes and the Enterprise require, including deployment lifecycle, distributed execution, scaling, and version-safe workflow replay. The integration is deep, and this episode covers all of it.

  7. Jul 15

    Is AI Saving Open Source Or Just Using It?

    People keep saying that AI helps developers get more done. But few are asking who pays for the computing power, tokens, and time needed to keep the open-source projects behind AI running. Node.js maintainers often use their own servers, patch together free subscriptions, and struggle to get access to the latest models they need to strengthen the core infrastructure that supports the AI industry. So who ends up paying for all this? In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about their daily work with the latest models like Fable, Grok 4.5, and Codex, and what it really takes to run agents for a large open-source project. They discuss seeing 20-30% performance gains in Node.js micro-benchmarks with Fable, leaving tmux sessions running for months, and facing the tough fact that Node.js still can't access the advanced cybersecurity models it needs for protection. In this episode, we cover: ✅ How Matteo uses Fable with Claude Code's slash goal operator to deliver real performance improvements to Node.js, and where it still falls short ✅ The difference between short-context laptop agents and long-running server agents, and why your MacBook isn't the right place for the latter ✅ The open source compute problem that often gets overlooked: who pays for the tokens and machines when most maintainers are volunteers? ✅ Why Matteo can't use Fable to strengthen Node.js against security threats, and what it means that Node.js isn't included in Project Glasswing The takeaway? AI is bringing new life to open source contributions in ways that would have seemed impossible just two years ago. But it's also creating a new kind of inequality, dividing projects that have access to the latest models from those that do not. Node.js is used in almost every AI product available today. At the very least, the industry should give its maintainers the tools they need to keep it secure.

  8. Jul 8

    Your Node.js Gateway It's Doing Twice the Work

    You launch a new product. Thousands of users click the same link at the same time. The cache is cold, and your Node.js app starts generating the exact same response hundreds of times simultaneously, burning CPU, hammering your database, and slowing down for everyone. This is the thundering herd problem, and most teams only discover it the hard way. So what if your gateway could just... not do that? In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina are joined by Paolo Insogna, Principal Software Engineer at Platformatic and Node.js TSC member, to break down how request deduplication works at the gateway level and why it changes the way you think about traffic spikes in Node.js. From the leader/waiter model to distributed coordination with Valkey, Paolo walks through exactly how Platformatic Gateway stops duplicate in-flight requests from reaching your upstream services, without touching a single line of your app code. In this episode, we cover: ✅ What the thundering herd problem actually is, and why caching alone doesn't solve it ✅ How gateway request deduplication works: the leader/waiter model explained in plain terms ✅ Memory vs. Valkey: when single-instance deduplication is enough and when you need distributed coordination ✅ The metrics that prove it's working, and what to watch for when rolling it out in production The takeaway? Caching protects you from future requests. Deduplication protects you while the first response is still being generated. They solve different problems, and running without both means your app is one viral moment away from a very bad day. Paolo built this into Platformatic Gateway so you get the protection without changing your backend, and this episode shows you exactly how it works.

See All (74)

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.

Information

You Might Also Like