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 complexity

By 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 work

This 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 systems

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