The Node (and more) Banter

Many teams believe autoscaling is simple: set a CPU threshold and let Kubernetes handle it. But if you get a three-minute traffic spike and your pods need two minutes to start, users feel the lag, the spike ends, and your new pods show up too late. What if your infrastructure could predict traffic instead of just reacting?In this episode, Luca Maraschi and Matteo Collina challenge the usual autoscaling approach—HPA, KEDA, ECS, and more. They explain the predictive scaling algorithm Platformatic created for their Intelligent Command Center (ICC). Matteo explains why scaling is a nonlinear problem that the industry keeps trying to solve with linear solutions, and how thinking of a distributed system like a neural network can change how scaling decisions are made.In this episode, we cover:✅ Why reactive autoscalers always use outdated data by design, and why this is a core flaw, not just a configuration issue✅ The real cost of pod boot time that often gets ignored: spawn time, warmup, and traffic rebalancing✅ Why CPU and memory are not the right metrics for Node.js, and what you should measure instead✅ How Platformatic's algorithm checks event loop utilization from outside the thread, with no interference and no extra overhead✅ The benchmark results: 99.47% success rate compared to 95% with KEDA and 90% with HPA, with P99 latency ten times better✅ The 46-page white paper they published, and why they believe it's time to stop scaling out of fearThe takeaways?Over-provisioning is not a safety net; it shows the model is broken. If your system cannot predict load, you will always have to choose between wasting money and getting worse performance. This episode, along with the white paper, argues that smarter scaling is now essential, not just a bonus.

Running AI agents in production isn't just about picking the right LLM. It's about the infrastructure decisions that make them safe, fast, and deployable at scale. Choosing between micro VMs, gVisor, Firecracker, or eBPF sounds like a systems engineering rabbit hole, until you realize the wrong choice can mean seconds of startup latency, infrastructure bloat, or an isolation model that doesn't match your actual threat surface.In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina go deep on the architecture behind Regina, Platformatic's AI agent sandbox, and explain exactly why they chose eBPF over traditional VM-based isolation. We unpack the two fundamental agent sandbox patterns, the trade-offs between logical and physical isolation, and why Node.js turned out to be a surprisingly perfect fit for systems-level eBPF work.We'll explore:✅ eBPF vs. micro VMs: startup latency, infrastructure complexity, and where the real boundary sits✅ Process-level vs. container-level isolation and why granularity changes everything for agents✅ The snowflake problem: managing stateful agents across Kubernetes pod restarts✅ How syscall and network policies are enforced at runtime, per agent process✅ Why Node.js is a natural fit for eBPF and why they built their own stack instead of using OpenCiliumThe big picture?Infrastructure shapes safety. If you're building or deploying AI agents on Kubernetes, this episode gives you the mental model for why isolation at the process level, not the container level, matters and why Node.js can hold its own as a systems language when the architecture is right.

Most teams building AI agents treat Kubernetes like it's optional. They spin up a Mac Mini, run their agent locally, and call it a day, until someone asks how to scale it, govern it, or deploy it across the enterprise. That's when the architecture falls apart. The question is: what does it actually take to run agents in production, at scale, inside the infrastructure you already have?In this episode of The Node (and more) Banter, Matteo Collina and Luca Maraschi do a full debrief on Platformatic's launch week, unpacking what they shipped, why they built it, and the hard distributed systems problems they had to solve along the way. From Regina, the open-source agent runtime built on top of Watt, to a Kubernetes-native sandbox powered by eBPF, this is the behind-the-scenes breakdown of what it takes to bring agentic infrastructure to the enterprise.In this episode, we cover:✅ What Platformatic launched. Regina, the agent sandbox, and the enterprise Kubernetes layer✅ Why agents are fundamentally stateful and why that breaks every assumption Kubernetes was built on✅ How Regina lets you define agents as a combination of Markdown and TypeScript, with state stored in SQLite and communication between agents baked in✅ The coordinator model: how Platformatic routes agent traffic inside Kubernetes without relying on a standard load balancer✅ Why we rejected the E2B remote VM model, and built a sandbox using eBPF directly inside the cluster instead✅ The governance problem nobody is talking about: who owns the agent, and how do you separate API access concerns from agent execution concerns?✅ The "ask-to-get" model. How developers can request access to URLs or disk policies without blowing up the enterprise approval process✅ Honest takes on sandbox security, adversarial escapes, and what "good enough" actually meansThe takeaway?Agents aren't a new category of software. They're stateful Node.js processes, and the hard part was never the AI model, it was everything around it: the state management, the routing, the isolation, and the governance. If you're thinking seriously about deploying agents inside your company's infrastructure, this episode gives you the full picture of what that actually requires.

Full-stack development is moving fast. TanStack Start is changing how we handle data fetching, routing, and server-client boundaries. AI tools like Claude are speeding up how we build and test these systems. But when it’s time for production, one question matters: how do you scale CPU-bound workloads like SSR without losing performance?Luca Maraschi and Matteo Collina sit down with Tanner Linsley, creator of TanStack, to dig into the core principles behind the TanStack ecosystem and what happens when those ideas hit real infrastructure. We share recent benchmarks of TanStack Start running on Watt under heavy load, showing exactly how architecture choices affect throughput, latency, and reliability.In this episode, we cover:✅ The core principles behind TanStack and why they resonate with modern developer workflows✅ What happens when TanStack Start hits production workloads, including SSR and CPU-bound bottlenecks✅ Insights from benchmarking at 1000 req/sec on Kubernetes and what they reveal about real-world performance✅ Why kernel-level load balancing and multi-worker architectures improve tail latency without adding overheadIf you’re building or leading teams on modern full-stack apps, this episode is for you. We break down how framework design, AI tools, and runtime architecture combine to power the next wave of scalable web systems.

Most developers let their AI assistant guess how to write Node.js. No context, no constraints, no history, just vibes and generic output. The result is code that ignores the event loop, skips proper error handling, and looks nothing like how senior engineers actually build. The question is: can you actually teach your AI to code like you?In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina dive into the emerging AI toolchain for Node.js development, from Agent Skills to coding agents like OpenClaw and Pi. Matteo shares his own personal skills repository (mcollina/skills), a collection of battle-tested Node.js, Fastify, and TypeScript best practices that any AI coding assistant can load and apply out of the box.In this episode, we cover:✅ What Agent Skills are and why the open standard changes how AI-assisted development works✅ Why Matteo got frustrated with AI slop and built his own skills repo — and what's inside it✅ How to install and use mcollina/skills with Claude Code, GitHub Copilot, OpenAI Codex, and more✅ What OpenClaw and Pi are, and how they fit into the Node.js AI toolchain✅ The practical question: what should a JavaScript developer actually install today to code with AI effectively?✅ The difference between prompting from scratch every time vs. encoding your expertise once and reusing it everywhereThe takeaway? AI-assisted development isn't just about which model you use, it's about the context you give it. Skills are how you stop training your AI from zero on every project and start shipping faster, with fewer corrections. If you're building with Node.js and you're not using skills yet, this episode will change how you set up your workflow.

Workflows look easy… until they corrupt your data.Durable workflows in Node.js promise retries, persistence, and long-running execution. On platforms like Vercel, everything just works. But the moment you move to Kubernetes, a hidden problem appears: version mismatch. A small code change can replay the wrong steps, mix results, and silently break your system. The question: how do you run durable workflows safely in production?Luca Maraschi and Matteo Collina dive into workflow orchestration in Node.js and the real challenges behind deterministic execution. From Workflow DevKit to Platformatic World, they break down how version-safe workflows work on Kubernetes, ensuring every run is pinned to the exact code version that created it, even across deployments, retries, and long-running jobs.In this episode, we cover:✅ Why durable workflows break on Kubernetes and not on Vercel✅ How deterministic replay works and why it can corrupt data✅ The hidden problem of versioning in long-running workflows✅ How Platformatic World enables version-safe orchestration✅ Why queue routing is critical for workflow correctness✅ What zero-config workflows look like in real production systemsIf you're building with Node.js, Kubernetes, or event-driven architectures, this episode is for you. Durable workflows are powerful, but without version safety, they’re a risk. This is what it actually takes to run them in production.

Node.js delivers high-performance I/O, moving data fast between network and disk. But today’s cloud-native, serverless, and AI-driven workloads hit a wall: the filesystem isn’t virtual. That means you can’t import in-memory modules, sandbox tenants, or bundle assets into a single executable without bloating binaries. The question: how do we unlock these capabilities?Luca Maraschi and Matteo Collina dive into Node.js Virtual File System (VFS): from @platformatic/vfs in userland to the upcoming node:vfs in core. VFS enables in-memory testing, sandboxed multi-tenancy, AI agents, and code-generation pipelines, features that standard fs simply can’t deliver.In this episode, we cover:✅ The limitations developers face without a virtual filesystem and why traditional workarounds fall short✅ How VFS plugs into Node.js fs and module loader to enable dynamic modules for AI and runtime code✅ VFS architecture: providers, mounts, overlays, and seamless import/require integration✅ Real-world use cases: single executables, isolated tests, AI agents, plugins, and codegen workflows✅ Why VFS belongs in core Node.js, and what sets core apart from userland.If you need flexibility, isolation, or advanced runtime power in Node.js, this is for you. Virtualizing the filesystem is a game-changer for developers, enterprise teams, and AI platforms.

AI applications are shifting from experiments toward real-world systems. As teams move to production, common challenges come up, such as managing low latency, handling concurrent requests, and integrating with different data sources and APIs. But beyond the models and prompts, there’s an important infrastructure question: Which runtime can handle AI workloads at scale and still be easy for developers to use?In this episode of “The Node (and more) Banter,” Luca Maraschi and Matteo Collina talk about why Node.js has become a key instrument for modern AI applications. Whether it’s managing LLM APIs, streaming responses, or building real-time agent systems and scalable AI backends, Node.js is at the heart of many production AI platforms.We’ll discuss why Node.js’s event-driven design works so well for AI workloads, how developer productivity speeds up AI development, and what enterprise teams should think about when building reliable AI services.Here’s what we’ll cover:✅ Why most AI applications are about orchestration, not simply building models✅ How Node.js manages streaming, concurrency, and real-time AI responses✅ The role JavaScript plays in connecting models, APIs, and user interfaces✅ Why developer speed matters in the fast-changing world of AI✅ What enterprise teams need to think about when running AI workloads in productionIf you’re building or leading teams working on AI-powered products, this conversation will show why Node.js is becoming a key part of today’s AI stack.

Every deployment is a gamble. A user mid-session hits a new backend. A renamed field breaks a form. A shared TypeScript interface diverges between client and server, and suddenly your support queue is full, and three teams are in a bridge call trying to figure out who broke what. This is version skew, and it's been quietly slowing down engineering teams on Kubernetes for years.In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina introduce Skew Protection in Platformatic's Intelligent Command Center (ICC), bringing the deployment safety that frontend teams love about Vercel, directly into your existing Kubernetes setup. No migrations. Use the tools you're already using for your CI/CD pipeline. Just safer, faster shipping.We'll explore:✅ Why version skew is a developer velocity problem disguised as a reliability problem✅ How broken deployments silently erode user trust, and what it costs enterprises at scale✅ How ICC pins users to their session version using cookie-based, version-aware routing✅ The Active → Draining → Expired lifecycle that makes zero-downtime deploys predictable✅ Why immutable per-version Deployments change how teams think about risk✅ How Prometheus traffic monitoring automates cleanup. No manual rollback babysitting✅ What this means for teams running Next.js, Remix, or monorepos on KubernetesThe big picture?Fear of breaking changes leads to bigger, rarer deployments, and that's where velocity goes to die. ICC's skew protection gives enterprise dev teams the confidence to ship smaller, ship faster, and stop making users pay the price for infrastructure gaps. Kubernetes just got a lot less scary.

AI adoption is accelerating across enterprises, powering automation and smarter decisions. But without auditability, AI quickly turns into a black box. Hard to trust, and difficult to govern. Transparent, traceable AI is not optional. It’s how you build trust, reduce risk, and meet real-world compliance needs.On this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina break down how to build AI apps that are fast, scalable, and crucially auditable while taking advantage of Platformatic OpenSource. We go deep into real strategies: designing for traceability, logging every decision, and making AI explainable from the ground up.We will explore:✅ How to structure Node.js-based AI applications for auditability and compliance✅ Best practices for logging, tracking, and versioning AI models✅ How Platformatic tools simplify building traceable APIs and data flows✅ Balancing performance, scalability, and transparency in AI applications✅ Why auditability is critical for enterprise adoption of AI✅ What this means for the future of trustworthy AI systemsThe takeaway?Auditability isn’t a box to tick. It’s a real need for developers and operators. If you’re building AI for regulated industries, at scale, or for multi-tenant platforms, you need traceability built in. This episode shows how auditable design drives trust, cuts risk, and speeds up adoption across your teams.

Node.js performance discussions usually revolve around CPU and latency. Memory often receives less attention. But memory footprint directly affects cost, scalability, cold starts, and container density. Cutting memory usage in half fundamentally changes how efficiently you can run Node.js in production.In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina are joined by James Snell, Principal System Engineer at Cloudflare, core contributor to Node.js, and member of the Node.js Technical Steering Committee. Together, they unpack how we reduced Node.js memory consumption by 50 percent and what this reveals about V8 internals, runtime behaviour, and modern deployment environments. This conversation goes beyond surface-level tuning. It explores how JavaScript engine design decisions influence real-world infrastructure costs and architectural choices.We will explore:✅ How V8 manages memory and where Node.js applications typically waste it✅ What pointer compression is and why it has such a dramatic impact✅ The tradeoffs between memory layout, performance, and compatibility✅ How memory footprint influences Kubernetes density and serverless efficiency✅ Why these optimizations matter for large scale and edge deployments✅ What this means for the future of Node.js runtime evolutionThe takeaway?Memory is not just a technical detail. It is a strategic lever. If you are running Node.js in containers, serverless platforms, edge environments, or high-density clusters, this episode explains how reducing memory usage can unlock meaningful efficiency gains across your entire stack.

Performance in enterprise systems isn’t just about fast code. It’s about making the right architectural choices. Surprisingly, caching is still often skipped, leaving applications slower, more expensive, and harder to scale.In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina dig into why caching is so often overlooked, when it actually delivers value, and how enterprises can adopt it effectively without adding complexity.We’ll explore:✅ The main reasons companies avoid caching, and whether those reasons hold up✅ How caching impacts scalability, cost, and system reliability✅ Different caching strategies and when to apply them✅ Pitfalls to avoid when introducing caching into existing systemsThe big picture?Caching isn’t just a technical tweak. It’s a strategic lever. Done right, it drives performance, efficiency, and scalability, giving enterprises a competitive edge in high-demand systems.

Running HTTP requests and consuming messages from queues or brokers in the same Node.js process may seem convenient—but it often leads to unpredictable latency, resource contention, and fragile systems.In this episode of The Node (& More) Banter, Luca Maraschi & Matteo Collina explore how Platformatic Watt enables entirely new patterns for modern Node.js architectures, from sagas to actors.We’ll dive into:✅ Why mixing HTTP and queue workloads can hurt reliability and throughput✅ How Watt allows you to isolate workloads while fully leveraging Node.js’ event loop and threads✅ New architectural patterns Watt makes possible for sagas, actors, and event-driven systems✅ How predictable, multi-threaded execution simplifies coordination in complex distributed workflows✅ Lessons from real-world systems on separating concerns without complicating your codeIf you’re building Node.js services that orchestrate multiple message flows or implement durable workflows, this episode explains how Watt unlocks patterns that were previously impossible—enabling stable, scalable, and maintainable systems.

Node.js performance in production isn’t about a single number — it’s about understanding the signals that drive scaling, stability, and cost. Event Loop Utilization (ELU) sounds simple, but once you add Kafka consumers, Kubernetes autoscaling, streams, and worker threads, things get complicated fast.In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina dig into Node.js metrics through the lens of real-world, event-driven systems. We focus on how ELU behaves in Kafka-heavy workloads, how it correlates with CPU, memory, and I/O, and why choosing the right metrics matters when you’re running Node.js on Kubernetes — especially with architectures like Watt.We’ll explore:✅ What Event Loop Utilization really measures — and why it’s a better signal than CPU alone✅ How ELU behaves for Kafka consumers and stream-based workloads✅ The relationship between ELU, memory pressure, and I/O saturation✅ Why Kubernetes autoscalers struggle with Node.js — and where ELU fits in✅ When worker threads help, and how to reason about ELU across workers✅ How Kafka client design impacts event loop health and throughput✅ Why Watt’s architecture aligns naturally with metric-driven scaling in K8sThe big picture?Metrics shape architecture. If you run Node.js with Kafka on Kubernetes, this episode helps you understand which signals actually reflect load, how to avoid misleading autoscaling decisions, and why Watt was designed around these realities from day one.

Recently, GraphQL has been under the spotlight, especially in the enterprise context. There’s been a lot of debate about whether it truly solves pressing problems or introduces more complexity than it’s worth.In this episode of The Node (& More) Banter, we go point by point and challenge these assertions. GraphQL isn’t perfect, but many of these criticisms miss the bigger picture, and in real enterprise setups, it still brings massive value.Join Luca Maraschi and Matteo Collina as they break down:✅ Why overfetching isn’t fully solved by BFFs✅ How GraphQL can simplify complex multi-service data flows✅ Why caching and normalized data strategies can actually reduce engineering overhead✅ Observability patterns that work in real-world GraphQL deployments✅ How GraphQL improves frontend autonomy without bloating backend complexityBy the end of this episode, you’ll understand why GraphQL is far from “niche” and why its tradeoffs can be worth it — if you know how to wield it properly.

JavaScript applications have long relied on a simple assumption: when recursion goes too far, the runtime throws a catchable error and the server survives. But under the hood, that assumption was never guaranteed — and with async context tracking enabled, it completely breaks.In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina dive into a recently disclosed Node.js bug that turned deep recursion into an unrecoverable process crash. A subtle interaction between stack exhaustion and async_hooks caused Node.js to exit immediately — bypassing try/catch, uncaughtException, and any chance of graceful recovery. The result: a denial-of-service risk silently affecting React Server Components, Next.js, and nearly every APM tool in production.We’ll cover:✅ Why stack overflows were never a reliable safety mechanism — even before this bug✅ How AsyncLocalStorage and async_hooks put fatal error handling on the call stack✅ Why React Server Components, Next.js request context, and APM tools were all affected✅ How a single deeply nested request could crash an entire Node.js process✅ What the fix actually changes — and why it’s a mitigation, not a full solution✅ What teams should do now: upgrades, input limits, and safer architectural patterns✅ What we tried and didn't workThis wasn’t a React bug. It wasn’t an APM bug. And it wasn’t even really a Node.js security bug. It was a reminder that recovering from resource exhaustion is not a contract, and that modern Node.js architectures increasingly depend on behaviour the runtime never promised.If you run React, Next.js, or any Node.js service with async context or observability enabled, this episode explains what broke, why it mattered, and how to avoid building availability on assumptions that won’t always hold.

Markdown in Git sounds like the simplest possible way to manage content. No CMS. No dashboards. No abstractions. Just files, version control, and AI agents that can grep the codebase. But once content needs to scale — across pages, teams, products, and automation — that simplicity starts to crack. Asset management sneaks back in. Permissions reappear. Content models emerge. Queries get rebuilt. And before long, you’re running a backend again.In this episode of The Node (& More) Banter, Luca Maraschi & Matteo Collina unpack the debate sparked by “You should never build a CMS” — and explain why deleting the CMS doesn’t delete the problem, it just moves it into code.We’ll cover:✅ Why “content = page” breaks down as soon as content needs to be reused, queried, or governed✅ How markdown + git quietly recreates CMS features — just without calling them that✅ Why git workflows work for code but fall apart for real content collaboration✅ Why AI agents need structured, queryable content — not grep and string matching✅ How the JAMstack model collapses once content becomes dynamic, shared, and automated✅ Why runtime-first architectures (and Node) are unavoidable in modern content systemsThe takeaway?You can delete the CMS UI — but you can’t delete the runtime. The JAMstack era is ending, and what replaces it is content infrastructure built for APIs, agents, and systems that need to reason, not just render.

The latest vulnerabilities in React Server Functions and the React Flight Protocol highlight just how fragile modern serialization can be. When insecure prototype access escalates into remote code execution, it’s not just a bug — it’s a wake-up call for anyone building with server-driven React.In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina break down the newly disclosed React/Next.js RCE vulnerabilities and what they reveal about the complexity hidden inside today’s server-side React architectures. No blame, no sensationalism — just a clear explanation of what happened and why it matters.We’ll also touch on why this issue sent shockwaves across the industry. A single, strange-looking payload — now circulating widely — became the centerpiece of an exploit that blended JavaScript’s dynamic nature with a missing safety check in React Flight. Security researchers described it as a “CTF-level puzzle,” a reminder that powerful patterns like promise streaming, prototype inheritance, and dynamic evaluation come with sharp edges.We’ll cover:✅ How React Server Functions and the Flight Protocol work — and why their serialization model is so complex.✅ What made reference resolution and prototype access dangerous enough to enable RCE.✅ Why server-driven React expands the attack surface when deserializing client input.✅ How the patch fixes the root issue — and what this means for future React security.✅ What teams should rethink today, from parsing to global state to architectural boundaries.Security incidents aren’t just CVEs — they’re blueprints for better engineering. If you run React Server Components, Next.js Server Actions, or any system that deserializes user input, this episode will help you understand the vulnerability, the fix, and the broader lessons for the ecosystem.

Running Node.js in serverless environments should be simple: deploy a function, let AWS scale it, and forget about infrastructure. But when you introduce multi-concurrency, shared worker threads, global state risks, and CPU-bound workloads — it’s not that simple.In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina break down one of the biggest announcements from AWS re:Invent: the new Node.js runtime for Lambda Managed Instances. AWS is officially validating what Platformatic has been saying for months — Node.js is entering a multi-concurrency era, and most applications are not ready for it.We’re not only deep-diving into what this means for AWS in general, but also exploring how these changes reflect on modern enterprise web workloads, going beyond the headlines to explain why AWS had to move in this direction and what it means for building, scaling, and operating Node.js applications in 2025.We'll cover:✅ What AWS’s new model changes — worker threads per vCPU, async/await concurrency, and 64 parallel requests per environment.✅ How multi-concurrency exposes Node.js weaknesses — shared global state, unsafe DB clients, event-loop contention, and filesystem conflicts.✅ Why these problems show up everywhere — not just in Lambda, but also in Kubernetes, EC2, Fargate, and on-prem deployments.✅ How Platformatic anticipated this shift — and why Watt’s architecture (multi-worker isolation, kernel load balancing, no shared state) aligns with where AWS is steering the ecosystem.✅ The performance implications — how concurrency amplifies latency spikes and failure cascades, and why architecture matters more than raw CPU.AWS’s announcement isn’t just a runtime update — it’s a public acknowledgement that the old “one request, one event loop” model of Node.js is gone. If you’re running Node.js today, whether serverless or self-hosted, this episode explains what’s changing under the hood, why it matters for performance, and how to stay ahead of it.

Running Next.js in Kubernetes should be simple: containerize, replicate, autoscale. But under real traffic — thousands of requests per second, CPU-bound workloads, unpredictable spikes — it’s not that simple.In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina unpack our latest benchmark showing Next.js running 93% faster with Watt compared to PM2 and traditional single-CPU pods. We go beyond charts to explain why the results happen, from Node.js event-loop behavior to Kubernetes load distribution and the Linux kernel’s SO_REUSEPORT.We'll cover:✅ How our benchmark harness works, simulating 1,000 requests per second to produce reliable, comparable results.✅ The architectural differences between single-CPU pods, PM2 clusters, and kernel-balanced Watt pods.✅ How latency, throughput, and failure rates interact — and the business impact of slow or failed requests.✅ Why Watt’s approach eliminates bottlenecks and maintains near-perfect success under heavy load.Benchmarks aren’t just numbers — they reveal how Node.js behaves under pressure. If you run Next.js or CPU-heavy Node.js in Kubernetes, this episode shows what’s slowing you down, why it happens, and how to fix it.

Last week, we talked about the complexity of running Next.js at enterprise scale. This week, we’re going under the hood — into the rendering engine itself.In this episode of The Node (& More) Banter, Luca Maraschi & Matteo Collina break down how Next.js’s server-side rendering model actually behaves inside Node.js — and why certain rendering patterns can silently overwhelm your event loop.We’ll explore:✅ How SSR, RSC, streaming, and data-fetching all compete for the same event loop✅ Why heavy render passes can starve I/O and cause tail latencies under load✅ The real performance cost of React Server Components running inside Node.js✅ Why some Next.js APIs behave like CPU workloads (even when they “feel” async)✅ How cache misses, waterfalls, and rendering concurrency amplify Node.js pressure✅ Techniques large-scale teams use to avoid event-loop saturation in production✅ What observability actually looks like when your server is doing complex renderingIf you’ve ever wondered why your Next.js app feels fast locally but bogs down under real traffic, this episode uncovers the part no framework abstracts away: rendering is work — and work competes for the event loop.

Next.js started as the easiest way to build React apps. But once you cross into enterprise scale — millions of users, regional deployments, complex caching, and security constraints — things get… complicated.In this episode of The Node (& More) Banter, Luca Maraschi & Matteo Collina dive deep into the real challenges of running Next.js in enterprise environments — and what it actually takes to make it fast, reliable, and maintainable when “just deploy it” doesn’t cut it anymore.We'll cover:✅ The hidden complexity of distributed rendering and Incremental Static Regeneration (ISR), and the new use cache directive in Next.js 16✅ Why cold starts and unpredictable latencies still plague large Next.js apps✅ How to regain control of caching, routing, and observability when platforms abstract them away✅ What’s changing with Next.js 16’s runtime flexibility — and how to self-host effectively✅ Strategies for balancing developer experience with performance and compliance✅ How Watt Runtime helps large teams bring back control — without losing simplicityThe takeaway?Next.js is powerful — but not magical. Running it in enterprise requires the same rigor as any large-scale distributed system.

From React Compiler 1.0 introducing automatic memoization (no more useMemo debates), to React Native deleting its legacy architecture and running directly on C++, to the entire React project moving under the Linux Foundation — the ecosystem is undergoing its biggest transformation since Hooks.In this episode of The Node (& More) Banter, Luca Maraschi & Matteo Collina unpack what these shifts mean for developers today — and what’s coming next.We’ll cover:✅ How React Compiler makes your apps faster without changing a line of code✅ Why React Native’s new architecture is a complete rebuild, not a refactor✅ What the Linux Foundation move means for React’s long-term future✅ Hidden gems in React 19.2 that change how we think about effects and visibility✅ Why 2025 marks the start of React’s “post-optimization” eraIf you’ve been waiting for the next big React moment — this is it. Compiler-level intelligence, native performance, and community governance are setting the stage for the framework’s boldest decade yet.

Every Node.js developer has, at some point, built a “distributed system” that turned into a distributed headache. You start with Kafka and a few services, and before long, you’re juggling retries, compensations, and correlation IDs like it’s 3 AM in production.In this episode of The Node (& More) Banter, Luca Maraschi & Matteo Collina break down the workflow orchestration wars — from traditional message queues to modern “durable execution” frameworks like Temporal and Vercel’s new “use workflow” directive.We’ll explore:✅ Why every complex Node.js system eventually reimplements a workflow engine✅ The pain points of Kafka-style event choreography (and how we got here)✅ How Temporal brings “workflow as code” to JavaScript✅ Why Vercel’s “use workflow” might make durability a language-level concept✅ When to choose Kafka, Temporal, or “use workflow” — and how to mix themIf you’ve ever asked yourself, “Why is this microservice talking to that one?”, this episode will help you see how the next generation of workflow tools is making distributed logic finally… durable.

Every Node.js developer has tuned into "𝐓𝐡𝐞 𝐍𝐨𝐝𝐞 (& 𝐌𝐨𝐫𝐞) 𝐁𝐚𝐧𝐭𝐞𝐫" to learn, laugh, and uncover the stories shaping how we build software — and this time, we’re doing something different.In this Special Episode, we highlight Luca Maraschi & Matteo Collina's most impactful moments from across the season — from scaling Node.js operations to mastering HTTP caching, surviving npm attacks, and redefining how developers build type-safe integrations.Across these highlights, you rediscover the insights, debates, and discoveries that shaped our year — and the future of modern Node.js development.We covered:✅ Smarter Node.js operations — from reactive to predictive✅ The hidden costs (and myths) of running Node on Kubernetes✅ How type-safe APIs are changing integrations forever✅ Lessons from the latest npm supply-chain attacks✅ Why caching is still one of the most powerful tools in your stack✅ And more moments that made us stop, think, and laugh along the wayWhether you’ve been with us from the start or just discovered Banter, this special episode brings the best of the conversation together — 50 minutes of the smartest, funniest, and most insightful moments from The Node (& More) Banter.

Every Node.js developer has chased down a slow endpoint or a CPU hotspot — but what about memory leaks silently draining your app’s performance (and your cloud budget)?In this episode of The Node (& More) Banter, Luca Maraschi & Matteo Collina dive into one of the most exciting updates to the Platformatic ecosystem: heap profiling support in @platformatic/flame and Watt Runtime. With heap profiling now built right in, developers can finally see where memory is going, why it’s not being freed, and how to fix it — all alongside CPU profiling.We’ll cover:✅ Why memory leaks are so hard to catch (and how flamegraphs make them visible)✅ How heap and CPU profiling work together for a full performance picture✅ What’s new in @platformatic/flame and Watt’s profiling tools✅ Real-world scenarios where heap profiling exposes hidden inefficiencies✅ Best practices for using these tools in development and productionIf you’ve ever wondered why your app slows down over time or crashes under load, this episode will help you uncover the hidden story of your memory usage — and how to take back control.

Python and Node.js are often treated as separate worlds—data science and AI in one, APIs and web services in the other. But what if you could run them together, seamlessly, in the same process?In this episode of The Node (& More) Banter, Luca Maraschi & Matteo Collina dive into our latest release: @platformatic/python—a new way to bring Python ASGI apps directly into your Node.js workloads.We’ll cover: ✅ How @platformatic/python bridges Node.js and Python without costly proxies✅ Why this matters for AI, data science, and gradual Python → Node migrations✅ The Rust-powered foundation making cross-language HTTP blazing fast✅ Real-world use cases: ML inference endpoints, automation tasks, and more✅ What’s next for multi-runtime services in PlatformaticIf you’ve ever wished you could tap into Python’s ecosystem without leaving Node.js, this conversation will show you how the two can finally play nice together.

The npm ecosystem just faced another major supply-chain attack—and it’s a wake-up call for every team building on open source.In this episode, we’re joined by Feross Aboukhadijeh, Founder & CEO of Socket, to unpack what happened, how these attacks work, and what developers and enterprises can do to defend against them.We’ll cover:✅ How attackers infiltrate npm packages✅ The ripple effects across the Node.js ecosystem✅ Why traditional security tools often miss the real threats✅ Practical steps to secure your dependencies✅ How open source maintainers and enterprises can collaborate on better defencesIf your applications depend on npm (and they almost certainly do), this is a conversation you can’t afford to miss.

Kubernetes is often sold as the one-size-fits-all platform for scaling applications. But when it comes to Node.js, the reality looks very different: sluggish autoscaling, bloated cloud bills, and resource models that don’t align with Node’s event-driven nature.In this episode of The Node (& More) Banter, we cut through the hype and explore why Kubernetes isn’t always the perfect fit for Node.js workloads—and what teams can do about it.We’ll dig into:✅ Why autoscaling lag hurts bursty Node.js traffic✅ How CPU/memory limits clash with Node’s async model✅ The hidden costs of “elastic” scaling in Kubernetes✅ Why treating Node.js like Java leads to waste and inefficiency✅ Smarter strategies for scaling Node.js effectively in the cloudIf you’ve ever wondered why your Kubernetes setup feels slow, expensive, or unpredictable with Node.js, this conversation will help you rethink the defaults—and save both performance and money.

For enterprises, Node.js apps bring both agility and complexity. Over-provisioned clusters, slow autoscaling, and disconnected metrics can silently drive up costs and risk outages.The future lies in predictive operations: runtime-aware scaling, unified observability, and cache intelligence—all working together to keep systems fast and efficient.In this episode, we’ll explore how modern Node.js operations help enterprises:✅ Cut infrastructure costs by up to 30% with smarter scaling✅ Prevent outages before they happen with Event Loop–aware monitoring✅ Gain full-stack visibility—from Kubernetes to caching efficiency✅ Shift from firefighting to proactive operationsIf you care about performance, cost, and operational clarity, this is the conversation you don’t want to miss.

APIs are the backbone of modern applications—but how often do they break because of mismatched payloads or vague documentation? That’s where type safety comes in. Type-safe clients don’t just save you from runtime errors; they make development faster, safer, and way less stressful.In this episode, we explore why type-safe client generation matters, how it works under the hood, and why it’s becoming essential for teams building complex systems in Node.js and beyond. From automated TypeScript definitions to schema-driven code generation, this is the roadmap to more predictable and maintainable integrations.We’ll cover:✅ What “type-safe client generation” actually means✅ How it eliminates guesswork and reduces integration bugs✅ The role of OpenAPI and JSON Schema in generating trusted clients✅ Real-world examples of broken integrations—and how type safety prevents them✅ How type safety improves onboarding and long-term maintainabilityIf you’ve ever wrestled with unclear API docs, runtime surprises, or the dreaded undefined is not a function, this episode is your guide to making API integration reliable—without slowing down your team.

Sticking to an outdated Node.js version might feel safe—but under the hood, it can be a ticking time bomb. From unpatched security flaws to missed performance boosts, the tradeoffs aren’t always obvious until it’s too late.In this episode, we’re joined by Erick Wendel to explore the hidden risks, technical debt, and missed opportunities that come from running on old Node.js releases—and why so many teams delay the upgrade in the first place.We’ll dig into:✅ How outdated versions silently impact performance and reliability✅ The real security risks lurking in older releases✅ Compatibility issues with modern libraries and tooling✅ The gains you’re leaving on the table by not upgrading✅ Practical strategies for safe, low-friction migrations✅ The cultural, organizational, and technical reasons why teams resist updatesIf your Node.js stack hasn’t been updated in a while—or you’re weighing the risks of upgrading—this conversation will give you the clarity (and the push) you need.

You can’t fix what you can’t see—and when it comes to performance issues in Node.js, flamegraphs are one of the most powerful tools you have. But what are they, really? And how do you actually use them?In this episode, we break down everything you need to know about flamegraphs—from the theory behind them to their implementation in Node.js. Whether you’re chasing event loop delays, CPU hotspots, or blocking I/O, flamegraphs reveal what your app is really doing under the hood.We’ll cover:✅ What flamegraphs are and how they visualize stack traces over time✅ How they’re implemented in Node.js (using V8 and async hooks under the hood)✅ How to generate and capture them in dev and production✅ How to read them: interpreting stack height, width, and call depth✅ Real examples of uncovering performance bottlenecks✅ How we’ve built automated flamegraph capture into Platformatic WattIf you’ve ever struggled with unexplained latency, inconsistent P99s, or just want to understand your Node.js app at a deeper level—this episode is your crash course in seeing the invisible.

When it comes to speeding up API calls, many developers jump straight into custom caching layers—rediscovering problems that HTTP solved decades ago.In this episode, we dig into why HTTP caching is still one of the most underused superpowers in web performance.You’ll learn:✅ How standard HTTP cache headers (Cache-Control, ETag, Vary) can do the heavy lifting✅ Why revalidation beats blind refetching✅ Common mistakes that lead teams to build fragile, homegrown caching hacks✅ How proper HTTP caching strategies improve scalability, latency, and costBefore you spin up another custom cache, make sure you’re using the protocol that was built for the job.

At a glance, setImmediate() seems like just another async tool in Node.js—but misuse it, and you could end up with unresponsive apps, delayed executions, or even missed events.In this episode, we break down why setImmediate() is often misunderstood, where it actually fits into the event loop, and the hidden performance and logic traps it can introduce in real-world applications.We’ll dig into:✅ How setImmediate() really works (vs setTimeout and process.nextTick)✅ Common pitfalls that can silently break your logic✅ Real-world debugging stories from misused timing functions✅ Safer patterns for deferring work in production✅ Why understanding the event loop is still essential for Node.js devsIf you’ve ever added a setImmediate() and hoped for the best, this episode is for you.

From background tasks to cross-request tracing, many developers rely on async context to glue state across their code. But under the hood? It’s fragile, unpredictable, and often a performance landmine.In this episode, we’re joined by Bryan English to dive into the lesser-known tradeoffs of async context management in Node.js—and how to build observability without breaking your app or your brain.We’ll dig into:✅ What async context really is (and what it isn’t)✅ Why it breaks in production, especially under load✅ The performance overhead of AsyncLocalStorage✅ Real-world patterns for context propagation that don’t implode✅ Lessons from building observability tools on top of it allIf you've ever struggled to trace a request, debug a memory leak, or just wondered why your context vanished mid-flight—this one’s for you.

AI tools are everywhere—but sharing context, conversations, and outcomes across a team? That’s still a mess. From copy-pasting chat logs to syncing prompts over Slack, most teams are stitching together brittle workflows that don’t scale.In this episode, we dive into our latest release of AI-Warp, which brings stateful interactions and resumable connections to the table. We’ll walk through how we used it to build a Slack bot that lets our team pick up, share, and continue AI conversations—without losing context or flow.We’ll dig into:✅ Why most AI tools break down in team settings✅ What it takes to make LLM interactions persistent and shareable✅ How resumability changes the way teams collaborate around AI✅ The real-world challenges we faced stitching AI-Warp into SlackIf your team is using AI but stuck treating it like a solo tool, this episode will show what’s possible when conversations—and context—can persist and evolve.

As enterprises race to integrate AI into their systems, a quiet shift is underway: the rise of the Model Context Protocol (MCP) as the de facto interface between models, services, and infrastructure. MCP isn’t just another wire format—it’s a way to give structure, semantics, and shared context to how systems communicate in the AI era.In this episode, we're joined by Alex Olivier, Co-founder & CPO of Cerbos, to explore how MCP is reshaping how teams think about interoperability, policy, and context-aware behavior. We also go behind the scenes on our effort to bring MCP to Fastify—what we’ve learned about runtime integration, developer experience, and where the protocol is heading next.We’ll dig into:✅ Why MCP is gaining traction as the new “API” for model-aware systems✅ The hidden complexity of securing and governing context-rich protocols✅ How Fastify is evolving to support MCP natively✅What it means to prioritize DX in a protocol-first worldIf you’re building systems that talk to models—or models that talk to systems—this is the protocol shift you can’t ignore.

In the quest for consistency, platform teams often turn to templating—starter kits, golden paths, boilerplate generators. The goal? Faster onboarding, safer deployments, fewer surprises. The result? A growing zoo of subtly different snowflakes, broken assumptions, and yet another internal tool no one really wants to maintain.In this episode, we dig into the dark side of templating culture—why efforts to standardize often backfire, and how the dream of "just use the template" slowly erodes into chaos.We’ll explore:Why starter kits rarely stay aligned with realityHow templating introduces a false sense of determinismThe tension between flexibility and driftWhat happens when every team “tweaks just one thing”Whether runtime-aware platforms offer a more durable alternativeIf you've ever cloned the internal boilerplate, spent hours unpicking someone else's one-line deviation, or tried to refactor the "official" template repo that no one owns anymore—this one’s for you.

Sidecars were meant to isolate concerns and standardize infrastructure. Instead, many teams end up managing a growing fleet of proxies, daemons, and coordination glue that quietly slows everything down.In this episode, we uncover the sidecar trap—how a well-intentioned pattern can balloon into operational drag, and what happens when the architecture starts optimizing for the infrastructure, not the app. Roberto Bianchi, Staff Engineer at Spendesk, joins us to share what his team learned as they experimented moving away from a sidecar-heavy setup—and how Watt can help simplifying operations and boost performance.We’ll dig into:✅ Why sidecars often become bottlenecks at scale✅ The hidden tax on observability, networking, and deploy times✅ How Spendesk re-imagined their stack using Watt✅ What changes when infrastructure becomes app-nativeIf you're deep in the weeds of service mesh, observability agents, or just tired of debugging YAML for yet another sidecar—you’ll want to hear this one

Composable architectures have focused heavily on APIs, services, and build-time integrations—but what about composition at runtime?In this episode, we explore the often-ignored layer of modern systems: how code actually runs, cooperates, and scales after deployment. We unpack the shift from static, pre-built delivery pipelines to runtime-aware platforms that dynamically orchestrate logic across languages, processes, and systems.Topics include:✅ Why runtime composition matters more as stacks become more distributed✅ Running multiple runtimes (Node, PHP, WASM) together, intentionally✅ How orchestration at the execution layer beats orchestration over the network✅ The limits of dev-centric frameworks when operations are an afterthoughtIf you’ve ever questioned why your “modular” system still feels fragile in production, this conversation connects the missing dots.

Internal platforms were supposed to streamline development. Instead, many teams find themselves maintaining internal systems more complex than the apps they support.In this episode, we explore the platform trap—how well-meaning abstractions can evolve into burdens, and what separates effective internal platforms from over-engineered detours.We’ll dig into:✅ When “platform” becomes a second product✅ How internal tools silently shape team structure and velocity✅ The fine line between empowering developers and creating lock-in✅ The rise of runtime-aware platforms and why they might offer a better pathIf you’re building developer platforms, or stuck maintaining one that no one really loves, this is your episode.

In today’s composable world, teams face a critical decision: make the pieces work together—or build the platform themselves. On paper, the flexibility is liberating. In reality, it comes with trade-offs that hit engineering velocity, cost, and maintainability.In this episode, we break down the models behind modern digital platforms:✅ The true cost of "just integrating" SaaS and headless tools✅ When PaaS simplifies operations—and when it limits you✅ Why on-prem isn't dead, especially for control and cost at scale✅ The illusion of no-code glue and the burden it shifts to developersWe’ll also explore how “build” doesn’t have to mean from scratch—and how smart reuse, automation, and runtime-level composition are changing the equation.Whether you're scaling a commerce platform or rethinking your content stack, this episode gives you a clear lens on one of the most misunderstood choices in modern architecture.

Modern architectures promise flexibility—mix the best services, swap parts anytime, go faster. But somewhere between headless CMSs, personalization engines, CDNs, and frontend frameworks... things start to drag.In this episode, we unpack the hidden cost of assembling your tech stack like LEGO:✅ Why delivering content at scale gets harder with every new service✅ The tension between personalization and performance✅ How frontend frameworks aren’t solving orchestration, just shifting the pain✅ Where caching helps—and where it makes things worseWe’ll also reflect on what the MACH movement (Microservices, API-first, Cloud-native, Headless) got right—and where it left teams with more integration work than innovation.If you’re building the modern web and wondering why it feels like a treadmill instead of a rocket… this episode is for you.

In this episode, we take a hard look at the Backend-for-Frontend (BFF) pattern: why it was introduced, where it actually helps, and where it starts to fall apart in real-world microservices architectures.We explore the core problems BFFs were meant to solve—API orchestration, frontend-specific shaping, security boundaries—but also the unintended costs: duplication of business logic, latency introduced by over-network composition, and fragile coupling to backend services.We’ll also dive into practical solutions:✅When to use a BFF and when to consolidate✅How caching can save or sink your BFF✅Design tips for reducing orchestration overhead✅Emerging approaches like multi-runtime co-location (Node + PHP, serverless + monoliths) that challenge the need for standalone BFFs entirelyIf you're scaling a frontend-heavy app or drowning in edge-layer glue code, this one’s for you.

PHP once ruled the web—and for good reason. Its simplicity and ubiquity made it the go-to runtime for millions of developers. But in today’s cloud-native world, Node.js has taken center stage for event-driven performance and modern tooling.At Platformatic, we’re not picking sides—we’re bridging them.In this episode, we dive into why PHP and Node.js aren’t rivals but the perfect pair for modern backend architecture. We talk about:✅ Why PHP still powers critical workloads across the internet✅ How we enabled PHP to run inside worker threads in Node.js with WATT✅ The power of inter-process communication (IPC) in simplifying legacy integration✅ And why this fusion is key to consolidating fragmented microservices into efficient, maintainable systemsIf you're wrestling with legacy PHP services or scaling Node.js in a complex architecture, this one's for you.

The boundary between physical and digital is dissolving. With OpenAI reportedly partnering with Jony Ive to build next-gen AI-powered hardware, a new era of intelligent IoT devices is taking shape—one where APIs need to do more than just respond. They need to understand, predict, and adapt.In this episode, we explore what it takes to modernize traditional APIs for this future. We break down:✅ The shift from request-response to long-lived, state-aware connections.✅ Why protocols like MQTT are foundational for real-time, resilient device communication.✅ The architecture implications of resumable sessions, edge inferencing, and handling connection volatility.✅ And how to embed AI-readiness into your system design—before the wave hits.Whether you're a backend engineer, API architect, or just curious how the web of devices is becoming the nervous system of AI, this episode is for you.

In this episode, we dive into two powerful architectural patterns that are often misunderstood: Command Query Responsibility Segregation (CQRS) and Event Sourcing. We unpack how CQRS can bring clarity and performance to complex systems by decoupling reads from writes, and how Event Sourcing allows you to track every state change as a series of immutable events.But it’s not all sunshine and scalability — we also discuss when these patterns introduce more complexity than value. You’ll learn:✅The core principles of CQRS and Event Sourcing✅Real-world use cases where they shine (think audit logs, complex workflows, and high-scale systems)✅Situations where they add unnecessary overhead (like simple CRUD apps)✅How to design a system around eventual consistency✅Common pitfalls and best practices from the trenchesWhether you’re building a fintech platform, a distributed e-commerce system, or just exploring architectural patterns, this episode gives you the clarity to decide: Is CQRS and Event Sourcing the right fit — or a solution looking for a problem?

In this episode, we unpack the communication layer of microservices—arguably the most complex and critical part of distributed systems. We start with a clear introduction to Apache Kafka—what it is, how it works, and why it's become a cornerstone for decoupled, scalable systems. Then, we shift into real-world strategies for using Kafka to build reliable, event-driven Node.js services that can scale with confidence.What you’ll learn:✅A developer-friendly introduction to Apache Kafka✅Why communication between microservices is the #1 source of complexity✅How to design services that communicate through events, not tight coupling✅The pros and cons of REST, gRPC, and Kafka—and when to use each✅Strategic patterns like event sourcing, pub/sub, and log compaction✅Best practices for using Kafka with Node.js✅Why @platformatic/kafka is designed for performance, safety, and DX✅How Platformatic Watt enables multi-threaded, high-performance microservices ready for Kafka at scaleWhether you're building greenfield services or refactoring a legacy mess, this episode will help you design smarter communication patterns that scale.

The OpenAPI Specification has become the standard for describing RESTful APIs — but its true power is often underutilized. In this deep dive, we’ll unpack what the spec can do, how to leverage it for automation, and how it fits into modern API-first development workflows.In this Episode, we’ll cover: ✅ What the OpenAPI Specification actually defines ✅ How to generate clients, servers, and docs from OpenAPI ✅ Best practices for writing and maintaining specs✅ Using OpenAPI in CI/CD pipelines✅ Versioning and collaboration workflows with OpenAPI