DEV Community: Juan Torchia

gRPC shows up when REST starts breaking under its own weight

Juan Torchia — Sat, 10 Oct 2026 12:00:20 +0000

Picture this: you've got fifteen microservices talking to each other. Each one exposes its own REST API, each one has its own JSON with its own naming conventions, and every time someone changes a field in the payments service, three other teams find out when everything blows up in production. You document with Swagger, but the Swagger goes stale. You write HTTP clients by hand, or generate something with OpenAPI that works "more or less." And when you need service A to ask service B something ten thousand times a second, the overhead of JSON + HTTP/1.1 starts hurting your infrastructure bill.

That specific pain — inter-service communication with contracts that break silently and performance that doesn't scale — is exactly what gRPC comes to solve. It's not a trend. Google designed it to solve that exact problem inside its own infrastructure, and then released it as an open source project. Today it shows up in three independent awesome lists, which, in the curation system I've been building out through this series, is a strong signal: it's not noise, it's real community consensus.

If you've been working with REST your whole career (like I spent a good chunk of time managing infrastructure before diving fully into development), the first time you see gRPC in action it changes how you think. It's not "another HTTP framework." It's a different paradigm for how your services talk to each other.

What it does

gRPC is a Remote Procedure Call framework that runs over HTTP/2 and uses Protocol Buffers (protobuf) as its default serialization mechanism. Instead of exposing REST endpoints and letting every client build its own request, you define a contract — a .proto file — and from that you generate client and server code in whatever language you need. Go, Java, Python, C++, Node, whatever. Same contract, multiple languages, and the field names and types are enforced by the generated code instead of living only in a doc someone forgot to update.

Here's what a basic contract looks like:

// pedidos.proto
// We define the service and the messages it will exchange
syntax = "proto3";

package pedidos;

// The service exposes an RPC method, as if it were a remote function
service PedidosService {
  rpc ObtenerPedido (PedidoRequest) returns (PedidoResponse);
}

// Messages are like DTOs, but typed and versionable
message PedidoRequest {
  string id_pedido = 1;
}

message PedidoResponse {
  string id_pedido = 1;
  double monto_total = 2;
  string estado = 3;
}

From that file, the protobuf compiler (protoc) automatically generates serialization classes and client/server stubs. If you come from the Java world (like me, where I started my career as a developer), this is going to sound similar to what SOAP did with WSDL, but without the dead weight of XML and with noticeably better performance.

On the server side in Java, the implementation looks like this:

// We implement the service automatically generated from the .proto
public class PedidosServiceImpl extends PedidosServiceGrpc.PedidosServiceImplBase {

    @Override
    public void obtenerPedido(PedidoRequest request, 
                               StreamObserver<PedidoResponse> responseObserver) {
        // The real logic would go here, querying the database
        PedidoResponse response = PedidoResponse.newBuilder()
            .setIdPedido(request.getIdPedido())
            .setMontoTotal(1500.50)
            .setEstado("CONFIRMADO")
            .build();

        // onNext sends the response, onCompleted closes the stream
        responseObserver.onNext(response);
        responseObserver.onCompleted();
    }
}

Notice there's no JSON anywhere. The payload is serialized in binary, which means smaller payloads and faster parsing. And since it runs over HTTP/2, you get multiplexing of requests over a single TCP connection, native bidirectional streaming, and header compression — the structural reasons gRPC tends to outperform REST under high load.

Why it's on the list

The consensus signal — three independent awesome lists mentioning it — isn't a coincidence. gRPC solves a problem that comes up fast with microservices: the lack of strong contracts between services. With REST + JSON, the contract is a convention that lives in devs' heads and in documentation that goes stale. With gRPC, the contract is generated code. If you break a field, you find out at compile time, not in production on a Friday at six in the evening.

The other big reason is performance. Code generation eliminates manual serialization boilerplate — you don't write JSON parsers by hand, you don't maintain duplicate DTOs in every language. And binary protobuf over HTTP/2 is the combination that gives gRPC an edge over traditional REST under high load, which is exactly the scenario where microservices start to struggle.

It's the kind of tool that doesn't shine in a five-minute demo, but becomes indispensable when you have dozens of services talking to each other at real volume. That's where the JVM ecosystem (if you work with Spring Boot, there's solid support via grpc-spring-boot-starter) benefits from this approach versus maintaining fifteen hand-built REST clients.

When NOT to use it

Now, let's be honest: gRPC isn't free, and this is the part people skip. Protobuf and the async/streaming model are a different mental model from request/response REST — if your team hasn't touched this before, budget real ramp-up time for it, not an afternoon. Debugging is also more tedious: you can't just hit a gRPC endpoint with curl like you did with REST, you need extra tools like grpcurl or BloomRPC to inspect traffic.

It also doesn't make sense if you're going to consume your API directly from a browser (you need gRPC-Web with an intermediate proxy, another layer of complexity) or if you're building a public API that third parties will consume without any control over their stack — there, REST + OpenAPI is still more friendly. If your system is two or three services with low traffic, you're probably adding complexity you don't need. For those cases, stick with REST or look at lighter alternatives like tRPC if you're in a TypeScript monorepo.

Wrap-up

gRPC is the kind of tool you shouldn't adopt because it's trendy, but because you have the specific problem it solves: inter-service communication at scale, with strong contracts and performance that matters. That's why it made it through this series' filters — it's not hype, it's real technical consensus, and it comes with a real learning cost you should plan for, not skip.

If you liked this analysis, this is just entry #13 of Awesome Curated: The Tools, where I go through tools that passed our curation system's filter. If you're into infrastructure and runtimes, you might also like the post on Node.js and its event loop, or if you're into networking, Sniffnet for monitoring network traffic without losing your mind. The full series is at /blog/series/awesome-curated-tools.

This article was originally published on juanchi.dev

gRPC no es moda: es el contrato que REST nunca te dio

Juan Torchia — Sat, 10 Oct 2026 12:00:16 +0000

Imaginate esto: tenés quince microservicios hablando entre sí. Cada uno expone su API REST, cada uno tiene su propio JSON con sus propias convenciones de nombres, y cada vez que alguien cambia un campo en el servicio de pagos, tres equipos más se enteran cuando todo explota en producción. Documentás con Swagger, pero el Swagger se desactualiza. Escribís clientes HTTP a mano, o generás algo con OpenAPI que funciona "más o menos". Y cuando necesitás que el servicio A le pregunte algo al servicio B diez mil veces por segundo, el overhead de JSON + HTTP/1.1 empieza a dolerte en la factura de infraestructura.

Ese dolor específico — comunicación inter-servicios con contratos que se rompen en silencio y performance que no escala — es el que gRPC viene a resolver. No es una moda. Google lo diseñó para resolver ese problema puntual dentro de su propia infraestructura, y después lo liberó como proyecto open source. Hoy aparece en tres awesome lists independientes, lo cual en el sistema de curación que vengo laburando en esta serie es señal fuerte: no es ruido, es consenso real de la comunidad.

Si vos venís de laburar con REST toda la vida (como yo laburé un buen tiempo administrando infraestructura antes de meterme de lleno al desarrollo), la primera vez que ves gRPC en acción te cambia la cabeza. No es "otro framework HTTP". Es un paradigma distinto para pensar cómo se hablan tus servicios.

Qué hace

gRPC es un framework de Remote Procedure Calls que corre sobre HTTP/2 y usa Protocol Buffers (protobuf) como mecanismo de serialización por default. En vez de exponer endpoints REST y que cada cliente arme su propio request, definís un contrato — un archivo .proto — y de ahí se genera código cliente y servidor en el lenguaje que necesites: Go, Java, Python, C++, Node. El mismo contrato, múltiples lenguajes, menos espacio para que cada equipo interprete el JSON a su manera.

Mirá cómo se ve un contrato básico:

// pedidos.proto
// Definimos el servicio y los mensajes que va a intercambiar
syntax = "proto3";

package pedidos;

// El servicio expone un método RPC, como si fuera una función remota
service PedidosService {
  rpc ObtenerPedido (PedidoRequest) returns (PedidoResponse);
}

// Los mensajes son como DTOs, pero tipados y versionables
message PedidoRequest {
  string id_pedido = 1;
}

message PedidoResponse {
  string id_pedido = 1;
  double monto_total = 2;
  string estado = 3;
}

De ese archivo, el compilador de protobuf (protoc) genera automáticamente las clases de serialización y los stubs de cliente/servidor. Si vos venís del mundo Java (como yo, que arranqué ahí mi carrera como developer), esto te va a sonar parecido a lo que hacía SOAP con WSDL, pero sin el peso muerto de XML.

Del lado del servidor en Java, la implementación queda así:

// Implementamos el servicio generado automáticamente desde el .proto
public class PedidosServiceImpl extends PedidosServiceGrpc.PedidosServiceImplBase {

    @Override
    public void obtenerPedido(PedidoRequest request, 
                               StreamObserver<PedidoResponse> responseObserver) {
        // Acá iría la lógica real, consultando la base de datos
        PedidoResponse response = PedidoResponse.newBuilder()
            .setIdPedido(request.getIdPedido())
            .setMontoTotal(1500.50)
            .setEstado("CONFIRMADO")
            .build();

        // onNext envía la respuesta, onCompleted cierra el stream
        responseObserver.onNext(response);
        responseObserver.onCompleted();
    }
}

Fijate que no hay JSON por ningún lado. El payload va serializado en binario, lo cual en teoría significa payloads más chicos y parsing más rápido que un JSON equivalente. Y como corre sobre HTTP/2, tenés multiplexación de requests sobre una sola conexión TCP, streaming bidireccional nativo y header compression — las piezas que, en el paper y la documentación oficial de gRPC, explican la ventaja frente a REST + HTTP/1.1 en escenarios de tráfico alto. No tengo benchmarks propios corridos para este post; lo dejo como lo que es, una ventaja de diseño documentada por el proyecto, no una medición mía.

Por qué está en la lista

La señal de consenso — tres awesome lists independientes mencionándolo — no es casualidad. gRPC apunta a un problema que cualquiera que laburó con microservicios a escala conoce: la falta de contratos fuertes entre servicios. Con REST + JSON, el contrato es una convención que vive en la cabeza de los devs y en una documentación que se desactualiza. Con gRPC, el contrato es código generado: si cambiaste un campo y rompiste algo, el compilador te lo marca, no lo descubrís en producción un viernes a las seis de la tarde.

La otra razón es que el code generation elimina el boilerplate de serialización manual — no escribís parsers de JSON a mano, no mantenés DTOs duplicados en cada lenguaje. Eso es valor concreto, independiente de cuánto gane o no en performance tu caso puntual.

Es el tipo de herramienta que no brilla en un demo de cinco minutos, pero que tiene sentido cuando tenés una arquitectura con decenas de servicios hablando entre sí. Ahí es donde el ecosistema JVM (si laburás con Spring Boot, hay soporte vía grpc-spring-boot-starter) se beneficia de este approach frente a mantener quince clientes REST hechos a mano.

Cuándo NO usarlo

Ahora, seamos honestos: gRPC no es gratis, y esto es lo que más me interesa dejar claro. Protobuf y los patrones async/streaming tienen una curva de entrada que no es trivial — si tu equipo nunca laburó con esto, contá con perder tiempo entendiendo por qué el stub generado no hace lo que esperabas en el primer intento. No tengo un número de días para darte porque depende del equipo, pero es una friccion real, no un detalle menor.

El debugging distribuido también es más tedioso: no podés pegarle con curl a un endpoint gRPC como hacías con REST, necesitás herramientas extra como grpcurl o BloomRPC para inspeccionar tráfico.

Tampoco tiene sentido si tu API la vas a consumir directamente desde un browser (necesitás gRPC-Web con un proxy intermedio, otra capa de complejidad) o si estás armando una API pública que terceros van a consumir sin control sobre su stack — ahí REST + OpenAPI sigue siendo más amigable. Si tu sistema son dos o tres servicios con tráfico bajo, probablemente estés agregando complejidad que no necesitás. Para esos casos, quedate con REST o mirá alternativas más livianas como tRPC si estás en un monorepo TypeScript.

Cierre

gRPC tiene sentido cuando tenés el problema específico que resuelve: comunicación inter-servicios a escala, con contratos fuertes y una curva de aprendizaje que estás dispuesto a pagar. No lo adoptaría solo porque aparece en tres awesome lists — esa señal te dice que la comunidad lo validó, no que tu equipo esté listo para el costo de entrada.

Esto es la entrega #13 de Awesome Curated: The Tools, donde voy desmenuzando herramientas que pasaron el filtro de nuestro sistema de curación. Si te interesa el lado de infraestructura y runtimes, capaz te cope también el post sobre Node.js y su event loop, o si andás por el lado de redes, Sniffnet para monitorear tráfico sin volverte loco. La serie completa está en /blog/series/awesome-curated-tools.

Este artículo fue publicado originalmente en juanchi.dev

Apache Spark won't melt down when your data doesn't fit in RAM anymore

Juan Torchia — Thu, 08 Oct 2026 12:00:23 +0000

Hey, before I start I need to make an honest clarification, because in this series transparency is sacred: the automated analysis I was handed for this post talked about a "memory layer for AI agents," vector DBs, and cross-session context persistence. That has nothing to do with what Apache Spark actually is. That description belongs to a different tool — probably something like Mem0 or similar — and it got crossed wrong in the curation pipeline. It happens, automated systems sometimes mix up metadata. That's why the human verdict still says "pending" — here it is, done by hand, with the real data.

What I do have confirmed: Apache Spark shows up in 3 independent awesome lists, and the official repo description describes it as a framework with "micro-batch processing for streams" and "stateful exactly-once semantics" as a backend. In plain terms: it's a distributed engine built for workloads where a single server, no matter how much RAM you throw at it, becomes a bottleneck.

Picture this: you have logs from an app generating 500 GB per day, and you need to calculate aggregate metrics — unique users, average latencies, anomaly detection — without waiting 14 hours for a Python script running on a single core to finish. That's where Spark stops being an academic curiosity and becomes the tool that saves your sprint.

What it does

Apache Spark is a distributed data processing engine, originally written in Scala, that runs on the JVM (yes, the JVM again — there's a reason I keep mentioning it in this series). It was born in Berkeley's AMPLab as a direct response to Hadoop MapReduce's limitations: Spark processes in memory instead of writing to disk at every intermediate step, which makes it orders of magnitude faster for iterative workloads (think ML algorithms, which need to pass over the same data again and again).

The central concept is the RDD (Resilient Distributed Dataset): a collection of data partitioned across the cluster's nodes, immutable, and able to rebuild itself if a node goes down (hence "resilient"). On top of that sit friendlier layers like DataFrames and Datasets, which give you a SQL/Pandas-style API, but distributed.

// Classic example: counting words in a giant dataset
// distributed across all nodes in the cluster
import org.apache.spark.sql.SparkSession

val spark = SparkSession.builder()
  .appName("ContadorDePalabras")
  .getOrCreate()

val textFile = spark.read.textFile("hdfs://logs/*.txt")

val conteo = textFile
  .flatMap(linea => linea.split(" "))   // split into words
  .groupByKey(identity)                  // group by word
  .count()                               // count occurrences

conteo.show()
spark.stop()

The interesting part is that this exact same code runs the same way on your notebook with 4 GB of RAM as it does on a 200-node cluster on AWS EMR. Spark takes care of partitioning the data, distributing the tasks, and handling failures — you just describe what you want to do, not how to distribute it.

The streaming part (the one the official repo description mentioned, "micro-batch processing for streams... stateful exactly-once semantics") is Spark Structured Streaming: instead of processing event by event like Kafka Streams or Flink, Spark groups events into micro-batches (every few seconds) and processes them with the same API you use for batch. That gives you "exactly-once" — no event gets processed twice or lost, even if a node explodes at the worst possible moment.

# Streaming in PySpark: counting events by time window
# reading from a Kafka topic in real time
df = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "localhost:9092") \
    .option("subscribe", "eventos") \
    .load()

conteoPorVentana = df \
    .groupBy(window(df.timestamp, "1 minute")) \
    .count()

query = conteoPorVentana.writeStream \
    .outputMode("update") \
    .format("console") \
    .start()

query.awaitTermination()

The project is open source under the Apache 2.0 license, maintained by the Apache Software Foundation, with official support for Scala, Java, Python (PySpark), and R. The repo is at github.com/apache/spark.

Why it's on the list

Showing up in 3 independent awesome lists is a decent signal — different curators, different angles, pointing at the same tool. It doesn't prove consensus across entire industries, but it's more than "trending on Twitter": it suggests the tool holds up across more than one context.

What sets it apart from alternatives like Hadoop MapReduce (its direct predecessor, much slower because it writes to disk at every step) or Dask (more pythonic but with an ecosystem and maturity well below) is the combination of three things: in-memory speed, a unified API that serves both batch and streaming, and an ecosystem of integrated libraries (MLlib for distributed machine learning, GraphX for graphs, Spark SQL for database-style queries) that saves you from having to glue together five different tools.

If you're coming from my history with infrastructure — Linux, networking, servers — you'll quickly understand why Spark earns my respect: it's not magic, it's distributed systems engineering done right, with two decades of academic papers behind it (the original RDD paper by Zaharia et al. is required reading if you like understanding the why, not just the what).

When NOT to use it

Now for the honest part, because in this series we don't sell smoke: if your dataset fits comfortably in a single machine's RAM (say, under 10-20 GB depending on the hardware), setting up a Spark cluster is like using a crane to lift a soda can. Pandas, Polars, or even DuckDB will give you faster results with a fraction of the operational complexity.

It's also not the best option if you need real sub-second latency in streaming — there, Apache Flink beats it hands down because it processes event by event, not in micro-batches. And if your team doesn't have experience operating distributed clusters (YARN, Kubernetes, or Databricks as a managed layer), the maintenance cost can eat up any performance gain. Spark isn't "install and go": it requires understanding partitioning, shuffle, executor memory — things you learn the hard way.

Wrap-up

This is post #13 of "Awesome Curated: The Tools," the series where we break down tools that passed the filter of our curation system — cross-referencing awesome lists, AI analysis, and a final human verdict. Spark is one of those tools that doesn't have the shine of something new, but that's still there, carrying the real weight of the industry, long after the hype moved on to something else.

If you're interested in the infrastructure and systems side of things, check out the post on Node.js and the runtime that changed the backend or the one on Sniffnet for monitoring your network. And if you want to see the full arc of the series, the complete list is at /blog/series/awesome-curated-tools.

This article was originally published on juanchi.dev

Apache Spark procesa terabytes sin que se te derrita el cluster

Juan Torchia — Thu, 08 Oct 2026 12:00:18 +0000

Che, antes de arrancar tengo que hacer una aclaración honesta, porque en esta serie la transparencia es sagrada: el análisis automático que me pasaron para este post hablaba de "memory layer para AI agents", vector DBs y persistencia de contexto cross-session. Eso no tiene nada que ver con lo que es realmente Apache Spark. Esa descripción corresponde a otra herramienta — probablemente algo como Mem0 o similar — y se cruzó mal en el pipeline de curación. Pasa, los sistemas automáticos a veces mezclan metadata. Por eso el veredicto humano todavía dice "pendiente": acá está, hecho a mano, con la data real.

Lo que sí tengo confirmado: Apache Spark aparece en 3 awesome lists independientes y tiene años de historia en producción en empresas que procesan volúmenes enormes de datos. La descripción oficial del repo lo define como un framework de "micro-batch processing for streams", con "stateful exactly-once semantics". En criollo: es el motor que entra en escena cuando tu volumen de datos supera lo que un solo servidor puede manejar en memoria, sin importar cuánta RAM le metas.

Pensalo así: tenés logs de una app que generan 500 GB por día, y necesitás calcular métricas agregadas — usuarios únicos, latencias promedio, detección de anomalías — sin esperar 14 horas a que termine un script de Python corriendo en un solo core. Ahí es donde Spark deja de ser una curiosidad académica y se convierte en la herramienta que te salva el sprint.

Qué hace

Apache Spark es un motor de procesamiento distribuido de datos, escrito originalmente en Scala, que corre sobre la JVM (sí, otra vez la JVM — por algo la menciono tanto en esta serie). Nació en el AMPLab de Berkeley como respuesta directa a las limitaciones de Hadoop MapReduce: Spark procesa en memoria en vez de escribir a disco en cada paso intermedio, lo que lo hace órdenes de magnitud más rápido para cargas de trabajo iterativas (pensá en algoritmos de ML, que necesitan pasar por los mismos datos una y otra vez).

El concepto central es el RDD (Resilient Distributed Dataset): una colección de datos particionada entre los nodos del cluster, inmutable, y que sabe reconstruirse sola si un nodo se cae (de ahí lo de "resilient"). Sobre eso se montan capas más amigables como DataFrames y Datasets, que te dan una API tipo SQL/Pandas pero distribuida.

// Ejemplo clásico: contar palabras en un dataset gigante
// distribuido entre todos los nodos del cluster
import org.apache.spark.sql.SparkSession

val spark = SparkSession.builder()
  .appName("ContadorDePalabras")
  .getOrCreate()

val textFile = spark.read.textFile("hdfs://logs/*.txt")

val conteo = textFile
  .flatMap(linea => linea.split(" "))   // separamos en palabras
  .groupByKey(identity)                  // agrupamos por palabra
  .count()                               // contamos ocurrencias

conteo.show()
spark.stop()

Lo interesante es que ese mismo código corre igual en tu notebook con 4 GB de RAM que en un cluster de 200 nodos en AWS EMR. Spark se encarga de particionar los datos, distribuir las tareas, y manejar los fallos — vos solo describís qué querés hacer, no cómo distribuirlo.

La parte de streaming (la que mencionaba la descripción oficial del repo, "micro-batch processing for streams... stateful exactly-once semantics") es Spark Structured Streaming: en vez de procesar evento por evento como Kafka Streams o Flink, Spark agrupa los eventos en micro-batches (cada pocos segundos) y los procesa con la misma API que usás para batch. Eso te da "exactly-once" — ningún evento se procesa dos veces ni se pierde, ni aunque un nodo explote en el peor momento.

# Streaming en PySpark: contamos eventos por ventana de tiempo
# leyendo de un topic de Kafka en tiempo real
df = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "localhost:9092") \
    .option("subscribe", "eventos") \
    .load()

conteoPorVentana = df \
    .groupBy(window(df.timestamp, "1 minute")) \
    .count()

query = conteoPorVentana.writeStream \
    .outputMode("update") \
    .format("console") \
    .start()

query.awaitTermination()

El proyecto es open source bajo licencia Apache 2.0, mantenido por la Apache Software Foundation, con soporte oficial para Scala, Java, Python (PySpark) y R. El repo está en github.com/apache/spark.

Por qué está en la lista

Que aparezca en 3 awesome lists independientes es un dato a favor, aunque no deja de ser una métrica de curación, no una prueba de calidad técnica en sí misma. Lo que sí puedo decir con base en la documentación oficial y años de adopción documentada en la industria: la combinación de velocidad en memoria, una API unificada para batch y streaming, y un ecosistema de librerías integradas (MLlib para machine learning distribuido, GraphX para grafos, Spark SQL para queries estilo base de datos) es lo que lo diferencia de alternativas como Hadoop MapReduce (su predecesor directo, mucho más lento porque escribe a disco en cada paso) o Dask (más pythonico pero con un ecosistema y madurez muy por debajo).

Si venís de mi historia con infraestructura — Linux, redes, servidores — vas a entender rápido por qué Spark me genera respeto: no es magia, es ingeniería de sistemas distribuidos bien hecha, con dos décadas de papers académicos atrás (el paper original de RDDs de Zaharia et al. es lectura obligada si te gusta entender el por qué, no solo el qué).

Cuándo NO usarlo

Ahora la parte honesta, porque en esta serie no vendemos humo: si tu dataset entra cómodo en la RAM de una sola máquina (digamos, menos de 10-20 GB dependiendo del hardware), montar un cluster de Spark es usar una grúa para levantar una lata de gaseosa. Pandas, Polars o incluso DuckDB te van a dar resultados más rápido y con una fracción de la complejidad operativa.

Tampoco es la mejor opción si necesitás latencia sub-segundo real en streaming — ahí Apache Flink le gana de mano porque procesa evento por evento, no en micro-batches. Y si tu equipo no tiene experiencia operando clusters distribuidos (YARN, Kubernetes, o Databricks como capa managed), el costo de mantenimiento puede comerte cualquier ganancia de performance. Spark no es "instalá y listo": requiere entender particionamiento, shuffle, memoria de executors — cosas que se aprenden a los golpes.

Cierre

Este es el post #13 de "Awesome Curated: The Tools", la serie donde desmenuzamos herramientas que pasaron el filtro de nuestro sistema de curación — cross-referencia entre awesome lists, análisis de IA, y veredicto humano final. Spark es de esas herramientas que no tienen el brillo de lo nuevo, pero que siguen ahí, aguantando el peso real de la industria, mucho después de que el hype se fue a otra parte.

Si te interesó el lado de infraestructura y sistemas, dale una vuelta al post sobre Node.js y el runtime que cambió el backend o al de Sniffnet para monitorear tu red. Y si querés ver el arco completo de la serie, la lista entera está en /blog/series/awesome-curated-tools.

Este artículo fue publicado originalmente en juanchi.dev

I Gave My VS Code Extension to a Cybersecurity Model and It Found an Infinite Hang

Juan Torchia — Thu, 08 Oct 2026 01:01:59 +0000

CertView is a VS Code extension I wrote to inspect certificates: you open a .pem, a .p12, a .cer, and it shows you the subject, the dates, the fingerprint, all offline. It's published on the Marketplace. It parses binary files that anyone can send you, so it's attack surface, and until this week I'd never looked at it thinking like an attacker.

I now have access to Daybreak Blue, OpenAI's defensive cyber model lane. I gave it my own code, the one I maintain, and asked it one concrete thing: assume I send you a malicious certificate and Juan opens it in the editor, what breaks? It found two ways to hang VS Code with a file smaller than a phone photo. I fixed both before writing this.

The PEM That Takes 88 Seconds to Do Nothing

The PEM parser splits the file into blocks. For every line it read, it re-joined the entire accumulated block to measure its size. One join per line. That's O(n²): double the lines, quadruple the work.

I measured it on the actual code. A PEM block with many single-character lines, staying under the 256 KiB limit the plugin itself enforces:

39 KiB → 2.4 seconds
78 KiB → 9.8 seconds
156 KiB → 39.7 seconds
234 KiB → 87.7 seconds

The size limit didn't help, because it was checked after re-joining all the lines. The fix is a one-line idea: keep a length counter and do a single join when closing the block. O(n) instead of O(n²).

The PKCS#12 That Never Ends

This one is worse, and it's the mess that made me stop.

A .p12 file carries a number inside: how many iterations to use to derive the key from the password. It's a legitimate mechanism — more iterations, more expensive to brute-force. The problem is that CertView passed that number straight to the parsing library (node-forge) exactly as it came from the file, with no cap, and the derivation runs synchronously: while it runs, VS Code doesn't respond.

An attacker can declare a huge number. And here's the detail that turns it into a hang instead of a delay: node-forge reads that number with parseInt. A 128-byte integer of 0xFF inside the file converts, in JavaScript, into Infinity. The derivation loop is for (round = 0; round < iterations; round++). With iterations = Infinity, it's not that it takes a long time: it never ends.

I verified it in one line of Node:

parseInt("f".repeat(256), 16) === Infinity // true

And the worst part: CertView automatically tries the empty password as soon as you open the file, before asking you anything. So the attacker doesn't need to know any password. You open the .p12 to see what it is, and the editor freezes on you forever.

The fix is a preflight: before touching the library, CertView now reads the iteration numbers directly from the file structure — no parseInt, so there's no path to Infinity — and rejects anything above 100,000. If the file asks for more, it doesn't get parsed.

What It Didn't Find, Which Also Matters

Not everything was a finding. The model reviewed the webview (the view where certificate data is shown) and confirmed that hostile fields are properly escaped, that the Content-Security-Policy is restrictive, that passwords aren't logged or saved, and that encrypted private keys aren't even decrypted. Instead of inventing vulnerabilities to pad out a list, it said where the code was already fine. That's what makes it useful: a report that's pure findings doesn't let you know what it checked and ruled out.

Sol vs. Blue, Same Code

I ran the same audit, with the exact same request word for word, on two models: GPT-5.6-Sol (the general-purpose one) and Daybreak Blue (the defensive one). Both read the code, neither invented anything. The difference wasn't that Blue "did something forbidden": it was depth. Sol saw that the PKCS#12 "freezes the host"; Blue also saw the Infinity case, which is the difference between slow and non-terminating. And Blue found one more thing Sol didn't: a race window between measuring the file size and reading it.

That's the honest part of the experiment. This was defensive work on my own code, and for that the general-purpose model also does the job. The specialized lane showed up in the detail, not in unlocking something the other refused to do.

The Real Obstacle Wasn't the Model

Two things I didn't expect, and I'm mentioning them because they're the part that doesn't make it into the announcement:

To get the account enabled I had to verify identity and set a physical YubiKey as the sole login — one single key, the one that now opens all my work. It's not optional, and it makes sense: a model with the brakes taken off for security work is exactly what someone would want to use with a stolen account.

And on the day I ran the audit, what slowed me down most wasn't either model: it was the tool's sandbox, which stopped being able to isolate the network on that machine and blocked all file reads. The model was ready; the plumbing around it wasn't. It's almost always like that.

What to Do If You Use CertView

Update to 0.5.1. Both vulnerabilities are fixed there, with tests that fail if either comes back. And if you're writing a parser for something sent to you from outside: measure your limits before doing the expensive work, not after, and never pass a library a number that came from the file without a cap.

Le di mi extensión de VS Code a un modelo de ciberseguridad y encontró un cuelgue infinito

Juan Torchia — Thu, 08 Oct 2026 01:01:54 +0000

CertView es una extensión de VS Code que escribí para inspeccionar certificados: abrís un .pem, un .p12, un .cer, y te muestra el sujeto, las fechas, el fingerprint, todo offline. Está publicada en el Marketplace. Parsea archivos binarios que te puede mandar cualquiera, así que es superficie de ataque, y hasta esta semana nunca la había mirado pensando como atacante.

Ahora tengo acceso a Daybreak Blue, el carril defensivo del modelo cyber de OpenAI. Le di mi propio código, el que mantengo yo, y le pedí una cosa concreta: asumí que te mando un certificado malicioso y Juan lo abre en el editor, ¿qué se rompe? Encontró dos formas de colgar VS Code con un archivo que pesa menos que una foto del celular. Las dos las arreglé antes de escribir esto.

El PEM que tarda 88 segundos en no hacer nada

El parser de PEM separa el archivo en bloques. Por cada línea que leía, volvía a pegar todo el bloque acumulado para medir su tamaño. Un join por línea. Eso es O(n²): si duplicás las líneas, cuadruplicás el trabajo.

Lo medí sobre el código real. Un bloque PEM con muchas líneas de un solo carácter, por debajo del límite de 256 KiB que el propio plugin impone:

39 KiB → 2,4 segundos
78 KiB → 9,8 segundos
156 KiB → 39,7 segundos
234 KiB → 87,7 segundos

El límite de tamaño no ayudaba, porque se chequeaba después de volver a pegar todas las líneas. El arreglo es de una línea de idea: llevar un contador de largo y hacer un solo join al cerrar el bloque. O(n) en lugar de O(n²).

El PKCS#12 que no termina nunca

Este es peor, y es el quilombo que me hizo parar.

Un archivo .p12 trae adentro un número: cuántas iteraciones usar para derivar la clave desde la contraseña. Es un mecanismo legítimo — más iteraciones, más caro de atacar por fuerza bruta. El problema es que CertView le pasaba ese número a la librería de parsing (node-forge) tal cual venía del archivo, sin ningún tope, y la derivación corre de forma síncrona: mientras corre, VS Code no responde.

Un atacante puede declarar un número enorme. Y acá está el detalle que lo vuelve un cuelgue y no una demora: node-forge lee ese número con parseInt. Un entero de 128 bytes de 0xFF dentro del archivo se convierte, en JavaScript, en Infinity. El bucle de derivación es for (round = 0; round < iteraciones; round++). Con iteraciones = Infinity, no es que tarda mucho: no termina jamás.

Lo verifiqué en una línea de Node:

parseInt("f".repeat(256), 16) === Infinity // true

Y lo peor: CertView prueba la contraseña vacía automáticamente apenas abrís el archivo, antes de preguntarte nada. Así que el atacante no necesita saber ninguna contraseña. Vos abrís el .p12 para ver qué es, y el editor se te congela para siempre.

El arreglo es un preflight: antes de tocar la librería, CertView ahora lee los números de iteraciones directamente de la estructura del archivo — sin parseInt, así que no hay camino a Infinity — y rechaza cualquiera por encima de 100.000. Si el archivo pide más, no se parsea.

Lo que no encontró, que también importa

No todo era un hallazgo. El modelo revisó el webview (la vista donde se muestran los datos del certificado) y confirmó que los campos hostiles se escapan bien, que la Content-Security-Policy es restrictiva, que las contraseñas no se loguean ni se guardan, y que las llaves privadas cifradas ni se descifran. En vez de inventar vulnerabilidades para llenar una lista, dijo dónde el código ya estaba bien. Eso es lo que lo hace útil: un reporte que es puro hallazgo no te deja saber qué revisó y descartó.

Sol contra Blue, mismo código

Corrí la misma auditoría, con el mismo pedido palabra por palabra, en dos modelos: GPT-5.6-Sol (el de uso general) y Daybreak Blue (el defensivo). Los dos leyeron el código, ninguno inventó nada. La diferencia no fue que Blue "hiciera algo prohibido": fue profundidad. Sol vio que el PKCS#12 "congela el host"; Blue vio además el caso Infinity, que es la diferencia entre lento y no-terminante. Y Blue encontró una cosa más que Sol no: una ventana de carrera entre medir el tamaño del archivo y leerlo.

Esa es la parte honesta del experimento. Esto era trabajo defensivo sobre mi propio código, y para eso el modelo de uso general también sirve. El carril especializado se notó en el detalle, no en destrabar algo que el otro se negaba a hacer.

El obstáculo real no fue el modelo

Dos cosas que no esperaba, y que cuento porque son la parte que no sale en el anuncio:

Para tener la cuenta habilitada tuve que validar identidad y dejar una YubiKey física como único login — una sola llave, la que ahora abre todo mi laburo. No es opcional, y tiene sentido: un modelo al que le sacaron frenos para trabajo de seguridad es exactamente lo que alguien querría usar con una cuenta robada.

Y el día que corrí la auditoría, lo que más me frenó no fue ninguno de los dos modelos: fue el sandbox de la herramienta, que dejó de poder aislar la red en esa máquina y bloqueó toda lectura de archivos. El modelo estaba listo; el plumbing alrededor, no. Casi siempre es así.

Qué hacer si usás CertView

Actualizá a la 0.5.1. Las dos vulnerabilidades están corregidas ahí, con tests que fallan si alguna vuelve. Y si vos escribís un parser de algo que te mandan de afuera: medí tus límites antes de hacer el laburo caro, no después, y nunca le pases a una librería un número que vino del archivo sin un tope.

Docker HEALTHCHECK: what the command actually runs and what it doesn't tell you

Juan Torchia — Tue, 06 Oct 2026 12:00:22 +0000

A Docker HEALTHCHECK answers a single question: did the command you defined exit with code 0? Nothing more. It doesn't measure whether the app is "healthy" in any broad sense — it measures whether that specific command, at that specific moment, didn't fail.

The official Docker documentation says it plainly: the HEALTHCHECK instruction tells Docker how to test a container to check that it's "still working." The example the docs themselves give is telling:

HEALTHCHECK --interval=5m --timeout=3s \
  CMD curl -f http://localhost/ || exit 1

That curl -f http://localhost/ tests one thing: that the web server answers something on the root path within 3 seconds. It doesn't test whether the database is up, whether the message queue has live workers, or whether the authentication service the app needs to log users in is responding. If curl gets any response at all — even an error page with a misconfigured 200 status — the healthcheck passes.

The three states and what triggers each one

According to the docs, a container with a healthcheck defined has a health status in addition to its normal status. It starts as starting. Every time the check passes, it moves to healthy. After a certain number of consecutive failures, it moves to unhealthy.

The command's exit code is the only thing that drives that state machine:

0: healthy — the container is "healthy" according to that command
1: unhealthy — the container isn't working correctly
2: reserved, do not use

That's all Docker knows. It doesn't interpret the content of the response, it doesn't validate business logic, it doesn't check transitive dependencies. If your check command is curl -f http://localhost/health and that endpoint returns 200 OK with a hardcoded JSON that never changes, you'll have a container that's forever healthy even if the app's actual logic is broken.

Shallow liveness vs. real health

Here's the distinction that matters when deciding what to put in the healthcheck: a shallow "liveness" check only confirms that the process responds — that it's not hung, that it hasn't entered an infinite loop, that the port is listening. A real health check validates that the dependencies the app needs to serve traffic actually work: database connection, access to critical external services, queue status if the app depends on them.

The docs give the exact example of the problem a basic liveness check solves: "detecting cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running." That's exactly what it covers, no more, no less. If the process responds but can't write to the database because the connection dropped, a healthcheck that just curls / will never find out — the server keeps answering with 200 on that path while every real request to the app fails.

A HEALTHCHECK that only verifies the process responds gives a false sense of security if it doesn't validate the app's real dependencies. The healthy status in docker ps can coexist perfectly well with an app that can't complete a single useful operation.

stateDiagram-v2
  [*] --> starting
  starting --> healthy: exit 0
  starting --> unhealthy: consecutive failures
  healthy --> unhealthy: consecutive failures
  unhealthy --> healthy: exit 0

What happens with start_period and retries

Two HEALTHCHECK options define how much patience Docker has before declaring unhealthy: --start-period and --retries. The docs explain that the start period gives initialization time for containers that need to bootstrap — if the check fails during that window, it doesn't count toward the maximum number of retries. But if the check passes once during the start period, the container is considered started, and from then on every consecutive failure does count.

This matters in a detail the docs don't highlight but that follows from the mechanics: if the app takes a while to come up and your start_period is short, you can end up counting as a "real failure" something that was actually "still starting up." The right tuning of start_period and retries depends on the app's actual bootstrap time — there's no universal value that works for every image.

What it doesn't measure, even if the healthcheck is well written

Not even the best CMD inside HEALTHCHECK solves this:

External dependencies you're not explicitly checking. If the command doesn't touch the database, the healthcheck knows nothing about it.
Partial degradation. A service that responds slowly but within the timeout passes the same as one that responds instantly. The exit code has no gradients.
Business state. If the app returns 200 but with corrupted data or an empty response where there should be content, and your check only validates the HTTP code, it passes all the same.
Anything happening outside the container. HEALTHCHECK runs inside the container, with whatever visibility it has from there. It doesn't see the state of the host, the external network, or other containers unless your command queries them directly.

Each of these points gets solved by adding logic to the healthcheck command — not by changing how Docker interprets the result. If you need the check to reflect the service's real health, the work is in writing an endpoint or a script that actually tests the dependencies that matter, not in tweaking intervals or retries.

Original source

Docker Docs — Dockerfile reference, HEALTHCHECK instruction

This article was originally published on juanchi.dev

Docker HEALTHCHECK: qué comando corre y qué no te dice

Juan Torchia — Tue, 06 Oct 2026 12:00:17 +0000

Un HEALTHCHECK de Docker contesta una sola pregunta: ¿el comando que definiste salió con código 0? Nada más. No mide si la app está "sana" en ningún sentido amplio — mide si ese comando específico, en ese momento, no falló.

La documentación oficial de Docker lo dice sin vueltas: la instrucción HEALTHCHECK le dice a Docker cómo testear un contenedor para chequear que "sigue funcionando". El ejemplo que da la propia doc es elocuente:

HEALTHCHECK --interval=5m --timeout=3s \
  CMD curl -f http://localhost/ || exit 1

Ese curl -f http://localhost/ prueba una cosa: que el servidor web contesta algo en la ruta raíz dentro de 3 segundos. No prueba que la base de datos esté arriba, que la cola de mensajes tenga workers vivos, ni que el servicio de autenticación que la app necesita para loguear usuarios esté respondiendo. Si curl recibe cualquier respuesta — incluso una página de error con status 200 mal configurado — el healthcheck pasa.

Los tres estados y qué dispara cada uno

Según la doc, un contenedor con healthcheck definido tiene un estado de salud además de su estado normal. Arranca en starting. Cada vez que el chequeo pasa, pasa a healthy. Después de una cierta cantidad de fallos consecutivos, pasa a unhealthy.

El exit code del comando es lo único que mueve esa máquina de estados:

0: healthy — el contenedor está "sano" según ese comando
1: unhealthy — el contenedor no funciona correctamente
2: reservado, no usar

Eso es todo lo que Docker sabe. No interpreta el contenido de la respuesta, no valida lógica de negocio, no chequea dependencias transitivas. Si tu comando de chequeo es curl -f http://localhost/health y ese endpoint devuelve 200 OK con un JSON hardcodeado que nunca cambia, vas a tener un contenedor eternamente healthy aunque la lógica real de la app esté rota.

Liveness superficial vs salud real

Acá está la distinción que importa para decidir qué poner en el healthcheck: un chequeo de "liveness" superficial solo confirma que el proceso responde — que no está colgado, que no entró en loop infinito, que el puerto escucha. Un chequeo de salud real valida que las dependencias que la app necesita para servir tráfico funcionan: conexión a la base de datos, acceso a servicios externos críticos, estado de colas si la app depende de ellas.

La doc da el ejemplo exacto del problema que resuelve un liveness check básico: "detectar casos como un servidor web atascado en un loop infinito e incapaz de manejar nuevas conexiones, aunque el proceso del servidor siga corriendo". Eso es exactamente lo que cubre, ni más ni menos. Si el proceso responde pero no puede escribir en la base de datos porque se cortó la conexión, un healthcheck que solo pega un curl a / nunca se va a enterar — el servidor sigue respondiendo con 200 en esa ruta mientras cada request real a la app falla.

Un HEALTHCHECK que solo verifica que el proceso responde da una falsa sensación de seguridad si no valida las dependencias reales de la app. El estado healthy en docker ps puede convivir perfectamente con una app que no puede completar ninguna operación útil.

stateDiagram-v2
  [*] --> starting
  starting --> healthy: exit 0
  starting --> unhealthy: fallos consecutivos
  healthy --> unhealthy: fallos consecutivos
  unhealthy --> healthy: exit 0

Qué pasa con start_period y los reintentos

Dos opciones de HEALTHCHECK definen cuánta paciencia tiene Docker antes de declarar unhealthy: --start-period y --retries. La doc explica que el start period da tiempo de inicialización para contenedores que necesitan bootstrapear — si el chequeo falla durante esa ventana, no cuenta para el máximo de reintentos. Pero si el chequeo pasa una vez durante el start period, el contenedor se considera arrancado y desde ahí todos los fallos consecutivos sí cuentan.

Esto importa en un detalle que la doc no resalta pero que se desprende de la mecánica: si la app tarda en levantar y tu start_period es corto, podés terminar contando como "fallo real" algo que en realidad era "todavía estoy arrancando". El ajuste correcto de start_period y retries depende del tiempo real de bootstrap de la app — no hay un valor universal que sirva para toda imagen.

Qué no mide, aunque el healthcheck esté bien escrito

Ni el mejor CMD dentro de HEALTHCHECK resuelve esto:

Dependencias externas que no estás chequeando explícitamente. Si el comando no toca la base de datos, el healthcheck no sabe nada sobre ella.
Degradación parcial. Un servicio que responde lento pero dentro del timeout pasa igual que uno que responde instantáneo. El exit code no tiene gradientes.
Estado de negocio. Si la app devuelve 200 pero con datos corruptos o una respuesta vacía donde debería haber contenido, y tu chequeo solo valida el código HTTP, pasa igual.
Lo que pasa fuera del contenedor. HEALTHCHECK corre dentro del contenedor, con la visibilidad que tiene desde ahí. No ve el estado del host, de la red externa, ni de otros contenedores salvo que tu comando los consulte directamente.

Cada uno de estos puntos se resuelve agregando lógica al comando del healthcheck — no cambiando cómo Docker interpreta el resultado. Si necesitás que el chequeo refleje la salud real del servicio, el trabajo está en escribir un endpoint o un script que efectivamente pruebe las dependencias que importan, no en ajustar intervalos o reintentos.

Fuente original

Docker Docs — Dockerfile reference, instrucción HEALTHCHECK

Este artículo fue publicado originalmente en juanchi.dev

Mem0 Doesn't Fix an Unbounded Agent, It Complements It

Juan Torchia — Sun, 27 Sep 2026 12:00:20 +0000

I have a hard limit configured in Cline: it doesn't touch files outside a specific folder, it doesn't run network commands without confirmation, and when the session gets long, the context starts piling up garbage. I already wrote about setting explicit limits on Cline running on autopilot and about monitoring what an agent does without telling you. The question that kept nagging me after nailing down that scope restriction is a different one: is lost context in long sessions a problem you solve with more scope discipline, or do you actually need an external memory layer?

That's where Mem0 comes in. It's a library that promises memory persistence for AI agents — it saves relevant facts from a conversation and retrieves them later, instead of re-injecting the entire raw history on every request. The pitch sounds good for the case I care about: a Cline session that runs for hours, on the same repo, where the agent repeats questions you already answered three times because the context filled up with noise and lost what mattered.

My thesis, before getting into the weeds: Mem0 can help in long, repetitive sessions, where the same kind of information gets needed over and over. But it doesn't replace the first line of defense, which is still limiting what the agent can touch and how much context you feed it going in. A memory layer is a patch on top of a design problem, not a solution to the design problem.

What the Mem0 repo says and what it doesn't say

The official Mem0 GitHub repo describes the tool as a memory layer that lets AI agents remember preferences, facts, and context across sessions, with support for multiple vector storage backends. The core idea is simple: instead of sending the entire conversation history to the model every time, Mem0 extracts and saves relevant snippets, and retrieves them when needed.

What the repo doesn't say — and this matters — is how much it reduces token consumption in a real code-agent workflow like Cline, working on a specific repo, with tool calls (reading a file, running a command, writing a diff) interleaved with reasoning. The docs' examples are built for conversational chatbots, not for agents that execute actions on a filesystem. That difference isn't trivial: a code agent generates a different kind of context than a chatbot that just talks. Diffs, terminal output, file contents — that's not "conversation memory," that's operational state.

So the question I'm asking isn't "does Mem0 work?" — the repo has activity, tests, and documented use cases. The question is "does Mem0 solve the specific context bloat problem in a code agent like Cline?", and the public evidence isn't enough to answer that with certainty.

Where people get it wrong: install Mem0 and expect magic

The common recipe I see floating around is: you grab Mem0, wire it up to the agent, and assume context bloat disappears because "now it has memory." The hidden cost of that recipe is that Mem0 adds a new layer with its own latency — every memory query involves a vector search, and that search isn't free in time or tokens if the retrieval prompt is verbose.

The counterexample that convinces me not to buy the hype without proof: if the agent already has a badly defined scope — you tell it "fix the bug" without specifying which files it can touch, without telling it what NOT to do — no memory layer fixes that. The agent will keep reading extra files, running exploratory commands, generating context it doesn't need. Mem0 can help so session 5 doesn't repeat what was already established in session 1, but it doesn't stop session 1 from being a context disaster if the scope was wrong from the start.

This connects directly to something I've been saying for a while: the underlying problem with autonomous agents isn't "missing memory," it's "missing limits." A well-written .clinerules, with explicit restrictions on which folders it can touch and which commands are forbidden, fixes more context bloat than an external memory layer — because it attacks the cause, not the symptom.

flowchart TD
  A[Long Cline session] --> B{Agent scope defined?}
  B -->|No| C[Context grows unchecked]
  B -->|Yes| D[Context bounded from the start]
  C --> E[Mem0 filters repeated noise]
  E --> F[Background bloat persists]
  D --> G[Mem0 adds real value in repetitive sessions]

The experiment I'd design before adopting this

I don't have production metrics of Mem0 integrated with Cline, and I'm not going to make any up. What I can lay out is the reproducible experiment I'd run before deciding whether it's worth it:

Fixed test repo: a small repo, with a known repetitive task (for example, adding the same type of endpoint three times with variations).
Baseline without Mem0: run the task three times in separate Cline sessions, counting context tokens per session (Cline exposes this in its cost UI).
Same task with Mem0: integrate Mem0 as a memory layer between sessions, repeat the three runs, and compare the input token count on the third run against the third run of the baseline.
Success criteria: if the third run with Mem0 uses noticeably fewer input context tokens than the third run without Mem0, there's a real signal. If the difference is marginal, or Mem0's query overhead cancels out the savings, the tool isn't solving the problem for that case.

I didn't run this experiment myself — this is the design I'd follow before writing a post claiming numbers. Anyone who wants to validate the thesis can clone the Mem0 repo and repeat these steps with their own Cline setup.

Decision matrix: when it actually makes sense to bring in Mem0

Situation	Worth adding Mem0?	What to check first
Short sessions, single well-scoped task	No	Scope already solves the bloat, memory is overhead with no return
Long sessions with repetitive tasks in the same domain	Possibly	Measure tokens before/after with the experiment above
Agent without `.clinerules` or scope restrictions	No, fix that first	Fix the scope limit before adding a new layer
Multiple agents sharing project context	Possibly	Check if the vector backend Mem0 uses is already in your stack
One-off project, no continuity between sessions	No	Persistent memory adds nothing if there's no future session to use it

Every row in this matrix is a criterion, not an absolute conclusion — the real outcome depends on the repo, the model, and how the agent is configured.

Limits: what can't be concluded without actually running this

Without production data or real logs from a Mem0 + Cline integration, I can't claim a token reduction percentage, an added latency figure, or whether the agent's response quality improves or gets worse with persistent memory. I also can't compare Mem0 against other context-compaction strategies (like periodic manual summaries) without running both in the same scenario.

What I do stand by with the available public evidence: the Mem0 repo is designed and documented first for conversational agents, not for code agents with heavy operational state. That design gap is why I wouldn't adopt the tool without first running the experiment described above on my own repo.

FAQ

Does Mem0 replace limiting the scope of an agent like Cline?
No. Mem0 manages what information persists across sessions, but it doesn't control what the agent can touch within a session. Scope is still defined with explicit rules, not memory.

Does Mem0 reduce tokens on every request?
It can reduce tokens if it avoids re-injecting the full history, but it adds its own retrieval query. The net balance depends on the case — you have to measure it, not assume it.

Does Mem0 work with Cline out of the box?
The Mem0 repo isn't built specifically for code agents with tools like Cline. Integrating it takes adaptation work, it's not plug-and-play for that use case.

Do I need a separate vector database to use Mem0?
Yes, Mem0 depends on a vector storage backend to index and retrieve memory. Check the repo's docs for supported options before adding new infrastructure.

When does it NOT make sense to use a memory layer like this?
When the task is a single session, when the agent already has bounded scope and resolves quickly, or when the project has no continuity between runs. There, persistent memory is cost with no return.

How do I measure if Mem0 actually helps in my case?
With the three-run experiment described above: baseline without memory, same task with memory, comparison of input tokens on the repeated run. Without that measurement, any claim is speculation.

My take

I'm not going to recommend Mem0 as a universal fix for something that, in most cases, is an agent design problem, not a memory shortage. If you're already limiting Cline's scope with clear rules — which folders it touches, which commands are forbidden, when you require confirmation — and you still feel context degrading in long, repetitive sessions, that's where Mem0 deserves the experiment. If you haven't put that limit in place first, installing a memory layer is putting makeup on a symptom.

The concrete next step for anyone who wants to actually validate this: clone the repo, set up the three-run experiment on a test project, and measure. Without that, everything else is new-tool folklore — the same mistake I've been avoiding with other pieces of the agent stack, like I wrote about monitoring the real traffic AI agents generate.

Original source:

Mem0 GitHub: https://github.com/mem0ai/mem0

This article was originally published on juanchi.dev

Mem0 no arregla un agente sin límites, lo complementa

Juan Torchia — Sun, 27 Sep 2026 12:00:16 +0000

Tengo un límite duro configurado en Cline: no toca archivos fuera de una carpeta específica, no corre comandos de red sin confirmación, y cuando la sesión se pone larga, el contexto empieza a acumular basura. Ya escribí sobre poner límites explícitos a Cline en autopilot y sobre monitorear lo que un agente hace sin avisar. La pregunta que me quedó picando después de esa restricción de scope es otra: ¿el problema de contexto perdido en sesiones largas se resuelve con más disciplina de scope, o hace falta una capa de memoria externa?

Ahí entra Mem0. Es una librería que promete persistencia de memoria para agentes de IA — guarda hechos relevantes de una conversación y los recupera después, en lugar de reinyectar todo el historial crudo en cada request. La promesa suena bien para el caso que me interesa: una sesión de Cline que dura horas, con el mismo repo, donde el agente repite preguntas que ya respondiste tres veces porque el contexto se llenó de ruido y perdió lo importante.

Mi tesis, antes de meterme en el detalle: Mem0 puede ayudar en sesiones largas y repetitivas, donde el mismo tipo de información se necesita una y otra vez. Pero no reemplaza la primera línea de defensa, que sigue siendo limitar qué puede tocar el agente y cuánto contexto le das de entrada. Una capa de memoria es un parche sobre un problema de diseño, no una solución al problema de diseño.

Qué dice el repo de Mem0 y qué no dice

El repositorio oficial de Mem0 en GitHub describe la herramienta como una capa de memoria que permite a los agentes de IA recordar preferencias, hechos y contexto entre sesiones, con soporte para múltiples backends de almacenamiento vectorial. La idea central es simple: en lugar de mandar todo el historial de conversación al modelo cada vez, Mem0 extrae y guarda fragmentos relevantes, y los recupera cuando hacen falta.

Lo que el repo no dice — y esto es importante — es cuánto reduce el consumo de tokens en un flujo real de agente de código como Cline, trabajando sobre un repo específico, con llamadas a herramientas (leer archivo, ejecutar comando, escribir diff) intercaladas con razonamiento. Los ejemplos de la documentación están pensados para chatbots conversacionales, no para agentes que ejecutan acciones sobre un sistema de archivos. Esa diferencia no es menor: un agente de código genera contexto de una naturaleza distinta a un chatbot que solo conversa. Diffs, salidas de terminal, contenido de archivos — eso no es "memoria de conversación", es estado operacional.

Entonces la pregunta que me hago no es "¿Mem0 funciona?" — el repo tiene actividad, tests, y casos de uso documentados. La pregunta es "¿Mem0 resuelve el problema específico de context bloat en un agente de código como Cline?", y ahí la evidencia pública no alcanza para responder con certeza.

Dónde se equivoca la gente: instalar Mem0 y esperar magia

La receta común que veo circular es: agarrás Mem0, lo conectás al agente, y asumís que el context bloat desaparece porque "ahora tiene memoria". El costo oculto de esa receta es que Mem0 agrega una capa nueva con su propia latencia — cada consulta a la memoria implica una búsqueda vectorial, y esa búsqueda no es gratis en tiempo ni en tokens si el prompt de recuperación es verboso.

El contraejemplo que me convence de no comprar el hype sin pruebas: si el agente ya tiene un scope mal definido — le decís "arreglá el bug" sin especificar qué archivos puede tocar, sin decirle qué NO hacer — ninguna capa de memoria arregla eso. El agente va a seguir leyendo archivos de más, ejecutando comandos exploratorios, generando contexto que no necesita. Mem0 puede ayudar a que la sesión 5 no repita lo que ya se estableció en la sesión 1, pero no evita que la sesión 1 sea un desastre de contexto si el scope está mal puesto desde el arranque.

Esto conecta directo con algo que ya vengo sosteniendo: el problema de fondo en agentes autónomos no es "falta memoria", es "falta límite". Un .clinerules bien escrito, con restricciones explícitas de qué carpetas puede tocar y qué comandos están prohibidos, resuelve más context bloat que una capa de memoria externa — porque ataca la causa, no el síntoma.

flowchart TD
  A[Sesion larga de Cline] --> B{Scope del agente definido?}
  B -->|No| C[Contexto crece sin control]
  B -->|Si| D[Contexto acotado desde el inicio]
  C --> E[Mem0 filtra ruido repetido]
  E --> F[Sigue habiendo bloat de fondo]
  D --> G[Mem0 suma valor real en sesiones repetitivas]

El experimento que diseñaría antes de adoptar esto

No tengo métricas productivas de Mem0 integrado con Cline, y no las voy a inventar. Lo que sí puedo dejar es el experimento reproducible que armaría antes de decidir si vale la pena:

Repo de prueba fijo: un repo chico, con una tarea repetitiva conocida (por ejemplo, agregar el mismo tipo de endpoint tres veces con variaciones).
Baseline sin Mem0: correr la tarea tres veces en sesiones separadas de Cline, contando tokens de contexto por sesión (Cline expone esto en su UI de costos).
Misma tarea con Mem0: integrar Mem0 como capa de memoria entre sesiones, repetir las tres corridas, y comparar el conteo de tokens de entrada en la tercera corrida contra la tercera corrida del baseline.
Criterio de éxito: si la tercera corrida con Mem0 usa notablemente menos tokens de contexto de entrada que la tercera corrida sin Mem0, hay una señal real. Si la diferencia es marginal o el overhead de consulta a Mem0 compensa el ahorro, la herramienta no está resolviendo el problema para ese caso.

Este experimento no lo corrí yo — es el diseño que seguiría antes de escribir un post afirmando números. Cualquiera que quiera validar la tesis puede clonar el repo de Mem0 y repetir estos pasos con su propio setup de Cline.

Matriz de decisión: cuándo tiene sentido meter Mem0

Situación	¿Vale meter Mem0?	Qué mirar primero
Sesiones cortas, tarea única y bien acotada	No	El scope ya resuelve el bloat, la memoria es overhead sin retorno
Sesiones largas con tareas repetitivas sobre el mismo dominio	Posiblemente	Medir tokens antes/después con el experimento de arriba
Agente sin `.clinerules` ni restricciones de scope	No, primero eso	Arreglar el límite de scope antes de agregar una capa nueva
Múltiples agentes compartiendo contexto de proyecto	Posiblemente	Evaluar si el backend vectorial que usa Mem0 ya está en el stack
Proyecto de un solo uso, sin continuidad entre sesiones	No	La memoria persistente no aporta si no hay sesión futura que la use

Cada fila de esta matriz es un criterio, no una conclusión absoluta — el resultado real depende del repo, del modelo y de cómo esté configurado el agente.

Límites: qué no se puede concluir sin correr esto en serio

Sin datos productivos ni logs reales de una integración Mem0 + Cline, no puedo afirmar un porcentaje de reducción de tokens, ni un tiempo de latencia agregado, ni si la calidad de las respuestas del agente mejora o empeora con memoria persistente. Tampoco puedo comparar Mem0 contra otras estrategias de compactación de contexto (como resúmenes periódicos manuales) sin correr ambas en el mismo escenario.

Lo que sí sostengo con la evidencia pública disponible: el repo de Mem0 está diseñado y documentado primero para agentes conversacionales, no para agentes de código con estado operacional pesado. Esa brecha de diseño es la razón por la que no adoptaría la herramienta sin antes correr el experimento descripto arriba en un repo propio.

FAQ

¿Mem0 reemplaza limitar el scope de un agente como Cline?
No. Mem0 gestiona qué información persiste entre sesiones, pero no controla qué puede tocar el agente dentro de una sesión. El scope se sigue definiendo con reglas explícitas, no con memoria.

¿Mem0 reduce tokens en cada request?
Puede reducir tokens si evita reinyectar historial completo, pero agrega su propia consulta de recuperación. El balance neto depende del caso — hay que medirlo, no asumirlo.

¿Funciona Mem0 con Cline directamente?
El repo de Mem0 no está pensado específicamente para agentes de código con herramientas como Cline. Integrarlo requiere trabajo de adaptación, no es plug-and-play para ese caso de uso.

¿Necesito una base vectorial separada para usar Mem0?
Sí, Mem0 depende de un backend de almacenamiento vectorial para indexar y recuperar memoria. Revisá la documentación del repo para las opciones soportadas antes de sumar infraestructura nueva.

¿Cuándo NO tiene sentido usar una capa de memoria como esta?
Cuando la tarea es de una sola sesión, cuando el agente ya tiene scope acotado y resuelve rápido, o cuando el proyecto no tiene continuidad entre corridas. Ahí la memoria persistente es costo sin retorno.

¿Cómo mido si Mem0 realmente ayuda en mi caso?
Con el experimento de tres corridas descripto arriba: baseline sin memoria, misma tarea con memoria, comparación de tokens de entrada en la corrida repetida. Sin esa medición, cualquier claim es especulación.

Mi postura

No voy a recomendar Mem0 como solución universal a algo que en la mayoría de los casos es un problema de diseño del agente, no de falta de memoria. Si ya limitás el scope de Cline con reglas claras — qué carpetas toca, qué comandos están prohibidos, cuándo pedís confirmación — y todavía sentís que el contexto se degrada en sesiones largas y repetitivas, ahí Mem0 merece el experimento. Si no pusiste ese límite primero, instalar una capa de memoria es maquillar un síntoma.

El próximo paso concreto para cualquiera que quiera validar esto en serio: clonar el repo, armar el experimento de tres corridas en un proyecto de prueba, y medir. Sin eso, todo lo demás es folklore de herramienta nueva — el mismo error que ya vengo evitando con otras piezas del stack de agentes, como escribí sobre monitorear el tráfico real que generan los agentes IA.

Fuente original:

Mem0 GitHub: https://github.com/mem0ai/mem0

Este artículo fue publicado originalmente en juanchi.dev

Next.js v16.3.6 vs v15.5.26: what's in each branch, according to the changelog

Juan Torchia — Sat, 26 Sep 2026 12:00:21 +0000

Hypothesis and scope

Two Next.js releases on the same day, September 22, 2026: v16.3.6 and v15.5.26. The question I'm interested in answering isn't which one is "better," but something more operational: does the 15.x branch still get only security patches, or does it also get general features and fixes? If the answer is "security only," the criteria for deciding when to migrate changes completely.

This isn't a benchmark or a performance measurement. It's a direct reading of the official release notes on GitHub, comparing the text content of each tag. Scope is limited: a single pair of releases, a single day. I can't generalize about the full lifecycle of the 15.x and 16.x branches from a single sample — that's flagged as a limitation below.

What each release note says

Primary source, no interpretation in between:

v16.3.6 — published September 22, 2026 at 17:15 UTC by maintainer eps1lon. The full text of the release reads:

"This release contains a security fix for GHSA-vcvr-r3jv-pc5j: Remote Code Execution in next/og ImageResponse"

Nothing else. A single item, one vulnerability identified by its GHSA code, affected component: next/og ImageResponse.

v15.5.26 — published the same day, one minute earlier (17:14 UTC), same maintainer. The full text:

"This release contains additional security hardening for next/og. For more information, check out https://nextjs.org/blog/nextjs-security-update-september-22-2026"

Also a single item. Same component (next/og), same day, but the wording is different: "security hardening" instead of "security fix" with a specific GHSA. The 15.5.26 release note points to a Next.js blog post for more context, which isn't part of the material I could verify for this analysis — I'm not going to speculate about its content.

Direct comparison

	v16.3.6	v15.5.26
Publish date	Sep 22, 2026, 17:15 UTC	Sep 22, 2026, 17:14 UTC
Affected component	`next/og` ImageResponse	`next/og`
Nature of the change	Specific fix with identified GHSA (RCE)	Additional "hardening," no own GHSA in the text
Number of changelog items	1	1
New features in this tag	Not mentioned	Not mentioned
Commits from this tag to canary	858	5556

The last data point in the table — commits from the tag to canary — doesn't measure development speed or future activity: it's just the current distance between that specific tag and the tip of canary at the moment GitHub was checked. I'm including it because it's public data visible on the release page, not because it predicts anything about the pace of either branch.

What I CANNOT conclude with this evidence

This pair of releases isn't enough to say whether 15.x receives only security patches as a general policy. The two texts I have in front of me are specifically about next/og, on the same day, probably coordinated as a response to the same vulnerability reported across different branches. That's consistent with "15.x gets security backports," but it doesn't prove that's all it gets: it would take reviewing several previous releases in the 15.5.x series to see if general bugfixes without a security component ever went in.

Nor can I state, with these two tags, what new features 16.3.6 brings compared to 15.5.26 in terms of product: neither text mentions features. If the 16.x branch has accumulated new functionality in other patches within the 16.3.x series, it's not documented in this specific release — reviewing the full changelog from 16.3.0 to 16.3.6, not just the last tag, would be necessary.

What this means for a team that hasn't migrated to App Router 16

With the evidence I have — just these two releases — the prudent criterion is this: if the team is still on 15.5.x and applied the next/og patch, it's covered for this specific vulnerability. That confirms Vercel keeps the 15.x branch alive for security, at least in this concrete case. What it doesn't confirm is that teams can stay there indefinitely waiting for the next fix: there's no evidence in these two tags about how much longer the 15.5.x series will receive support, or whether it will incorporate anything beyond security hardening.

The decision to force a migration to App Router 16 doesn't depend on this specific patch — it depends on which 16.x features the project needs and how much support time 15.x has left, a detail that isn't in these release notes.

Pending protocol for anyone who wants to dig deeper

I didn't run this as part of this analysis; I'm leaving it as reproducible steps for anyone who wants to go beyond the two specific tags:

# View the full release history of 15.5.x from npm
npm view next versions --json | grep '"15\.5\.'

# Compare the code diff between two specific tags
git log v15.5.20..v15.5.26 --oneline -- packages/next/src/server/image-optimizer

# Check whether any 15.5.x release brings features (not just fixes)
# by searching for the term "Feature" in each GitHub release note

Criterion for accepting or rejecting the hypothesis "15.x only receives security": if reviewing 5 or 6 previous releases in the 15.5.x series turns up an item that isn't a security fix or a critical bugfix, the hypothesis falls apart. With the two tags in this analysis, there isn't enough evidence either way — just a single data point from September 22, 2026.

Original source:

Next.js v16.3.6 release: https://github.com/vercel/next.js/releases/tag/v16.3.6
Next.js v15.5.26 release: https://github.com/vercel/next.js/releases/tag/v15.5.26

This article was originally published on juanchi.dev

Next.js v16.3.6 vs v15.5.26: qué contiene cada rama, según el changelog

Juan Torchia — Sat, 26 Sep 2026 12:00:16 +0000

Hipótesis y alcance

Dos releases de Next.js el mismo día, 22 de septiembre de 2026: v16.3.6 y v15.5.26. La pregunta que me interesa responder no es cuál es "mejor", sino algo más operativo: ¿la rama 15.x sigue recibiendo sólo parches de seguridad, o también features y fixes generales? Si la respuesta es "sólo seguridad", el criterio para decidir cuándo migrar cambia por completo.

Esto no es un benchmark ni una medición de performance. Es una lectura directa de los release notes oficiales en GitHub, comparando el contenido textual de cada tag. Alcance acotado: un solo par de releases, un solo día. No puedo generalizar sobre el ciclo de vida completo de las ramas 15.x y 16.x a partir de una sola muestra — eso queda marcado como límite más abajo.

Qué dice cada release note

Fuente primaria, sin interpretación de por medio:

v16.3.6 — publicado el 22 de septiembre de 2026 a las 17:15 UTC por el mantenedor eps1lon. El texto completo del release dice:

"This release contains a security fix for GHSA-vcvr-r3jv-pc5j: Remote Code Execution in next/og ImageResponse"

Nada más. Un solo ítem, una vulnerabilidad identificada por su código GHSA, componente afectado: next/og ImageResponse.

v15.5.26 — publicado el mismo día, un minuto antes (17:14 UTC), mismo mantenedor. El texto completo:

"This release contains additional security hardening for next/og. For more information, check out https://nextjs.org/blog/nextjs-security-update-september-22-2026"

También un solo ítem. Mismo componente (next/og), mismo día, pero la redacción es distinta: "security hardening" en lugar de "security fix" con un GHSA puntual. El release note de 15.5.26 remite a un blog post de Next.js para más contexto, que no está en el material que pude verificar para este análisis — no voy a especular sobre su contenido.

Comparación directa

	v16.3.6	v15.5.26
Fecha de publicación	22 sep 2026, 17:15 UTC	22 sep 2026, 17:14 UTC
Componente afectado	`next/og` ImageResponse	`next/og`
Naturaleza del cambio	Fix puntual con GHSA identificado (RCE)	"Hardening" adicional, sin GHSA propio en el texto
Cantidad de ítems en el changelog	1	1
Features nuevas en este tag	No mencionadas	No mencionadas
Commits desde este tag hasta canary	858	5556

El último dato de la tabla — commits desde el tag hasta canary — no mide velocidad de desarrollo ni actividad futura: es sólo la distancia actual entre ese tag puntual y la punta de canary en el momento en que se consultó GitHub. Lo incluyo porque es un dato público visible en la página del release, no porque prediga nada sobre el ritmo de cada rama.

Qué NO puedo concluir con esta evidencia

Este par de releases no alcanza para decir si 15.x recibe sólo parches de seguridad como política general. Los dos textos que tengo delante son específicamente sobre next/og, el mismo día, probablemente coordinados como respuesta a la misma vulnerabilidad reportada en distintas ramas. Eso es consistente con "15.x recibe backports de seguridad", pero no prueba que sea lo único que recibe: haría falta revisar varios releases anteriores de la serie 15.5.x para ver si en algún momento entraron bugfixes generales sin componente de seguridad.

Tampoco puedo afirmar, con estos dos tags, qué features nuevas trae 16.3.6 frente a 15.5.26 en términos de producto: ninguno de los dos textos menciona features. Si la rama 16.x acumula funcionalidad nueva en otros patches de la serie 16.3.x, no está documentado en este release puntual — sería necesario revisar el changelog de 16.3.0 a 16.3.6 completo, no sólo el último tag.

Qué implica para un equipo que no migró a App Router 16

Con la evidencia que tengo — sólo estos dos releases — el criterio prudente es este: si el equipo sigue en 15.5.x y aplicó el parche de next/og, está cubierto para esta vulnerabilidad puntual. Eso confirma que Vercel mantiene la rama 15.x viva para seguridad, al menos en este caso concreto. Lo que no confirma es que puedan quedarse ahí indefinidamente esperando la próxima corrección: no hay evidencia en estos dos tags sobre cuánto tiempo más va a recibir soporte la serie 15.5.x, ni sobre si va a incorporar algo más que hardening de seguridad.

La decisión de forzar la migración a App Router 16 no depende de este parche puntual — depende de qué features de 16.x necesita el proyecto y de cuánto tiempo de soporte le quede a 15.x, dato que no está en estos release notes.

Protocolo pendiente para quien quiera profundizar

Esto no lo ejecuté como parte de este análisis, lo dejo como pasos reproducibles para quien quiera ir más allá de los dos tags puntuales:

# Ver el historial completo de releases 15.5.x desde npm
npm view next versions --json | grep '"15\.5\.'

# Comparar el diff de código entre dos tags específicos
git log v15.5.20..v15.5.26 --oneline -- packages/next/src/server/image-optimizer

# Revisar si algún release 15.5.x trae features (no solo fixes)
# buscando el término "Feature" en cada release note de GitHub

Criterio para aceptar o descartar la hipótesis "15.x sólo recibe seguridad": si al revisar 5 o 6 releases anteriores de la serie 15.5.x aparece algún ítem que no sea fix de seguridad o bugfix crítico, la hipótesis cae. Con los dos tags de este análisis, no hay evidencia suficiente en ningún sentido — sólo un dato puntual del 22 de septiembre de 2026.

Fuente original:

Next.js v16.3.6 release: https://github.com/vercel/next.js/releases/tag/v16.3.6
Next.js v15.5.26 release: https://github.com/vercel/next.js/releases/tag/v15.5.26

Este artículo fue publicado originalmente en juanchi.dev