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. 6 days ago

    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.

  2. 22 Jul

    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.

  3. 15 Jul

    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.

  4. 8 Jul

    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.

  5. 1 Jul

    How Do You Build Skew Protection? Let's unpack it

    "Zero downtime" doesn’t mean there’s no risk. When you release new code, some users still have the old version open in their browser, using outdated JS bundles and React state, without realizing anything has changed. Teams usually find out when a checkout fails or a form resets in the middle of a session. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina break down the version skew problem from scratch. They explain what really happens during a deployment, why forcing a reload isn’t an option, and how to keep several app versions running at once without causing issues for users. They walk through the solution live, covering cookies, ingress routing, Kubernetes replica sets, and show the control plane they built to manage it all. We will cover: ✅ Why version skew happens with every deployment and isn’t just a bug you can fix ✅ How old JS bundles and mismatched React state can quietly break live user sessions ✅ Why making users reload the page doesn’t solve the problem, and how it can hurt your e-commerce business ✅ How cookies and ingress controllers help send users to the right app version without causing problems✅ How the control plane architecture manages replica set registration, routing, and smooth shutdowns in Kubernetes The takeaway? Version skew isn’t a sign your deployment failed. It’s just part of how deployments work. The best teams don’t try to avoid it; they build systems that let different versions run together. A control plane won’t make things simple, but it does put the complexity in a place you can manage.

  6. 24 Jun

    Why Shipping Fast Breaks Your Users (and How to Stop It)

    You deploy several times a day. Your team moves quickly, and your lead time is short. But each deployment can quietly disrupt users already on your site. There are no big warnings, just someone clicking around, suddenly running into errors because the app in their browser and your updated server are out of sync. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about version skew: what it is, why it naturally happens when you ship isomorphic JavaScript apps, and why most teams don’t set up skew protection until it causes problems in production. Here’s what we discuss in this episode: ✅ What isomorphic JavaScript actually means, and how running the same code on both the server and client leads to the skew problem ✅ Why version skew is different from API versioning, and how treating it like an API issue leaves you vulnerable when a user loads an old bundle, but the server has already changed ✅ Why shipping faster increases the chance for things to break, and how skew protection helps reduce that risk ✅ Why slowing down isn’t the solution: what Accelerate’s data shows about deploy frequency, lead time, and how small batches actually lower risk The takeaway? Shipping fast isn’t a problem; it’s the goal, and the data supports this. But fast deploys and isomorphic apps always lead to version skew, which stays hidden until a real user with an old bundle gets a 404 on something you removed earlier. Skew protection lets you keep deploying all day without quietly breaking users who arrived before lunch.

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