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 rendering

If 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 simplicity

The 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” era

If 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 them

If 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 way

Whether 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 production

If 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 Platformatic

If 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 defences

If 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 cloud

If 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 operations

If 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 maintainability

If 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 updates

If 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 cost

Before 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 devs

If 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 all

If 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 Slack

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