Backend de Dart: benchmarks y problemas de memoria

# Dart en el Servidor: Por Qué Colapsó Bajo Carga de Producción

Un desarrollador de SaaS cambió Node.js por Dart para reducir el uso de memoria. Expectativas: 10 MB al inicio vs. 80 MB, compilación AOT y tipado estático. Realidad: dos semanas de desarrollo, un framework personalizado y benchmarks que muestran peor rendimiento. Lección aprendida: siempre ejecuta benchmarks reales con cargas de producción antes de migrar.

El servicio de autenticación (OAuth2, ORM de Redis) fue el banco de pruebas. Node.js alcanzó 500 MB pero liberó memoria. Cientos de instancias a 80 MB al inicio era el problema principal.

Ecosistema: Sin Herramientas Backend a la Vista

Dart está hecho para Flutter. No hay equivalentes a NestJS, pocos clientes de Redis igualan la calidad de ioredis. Shelf es un router básico, Serverpod va dirigido a apps full-stack de Flutter.

Tuve que construir un framework desde cero:

• DI basado en árbol como Angular.
• Alcance de solicitudes vía Zone.
• CLI con codegen para AOT.

Porté ts-oauth2-server e ioredis (4500 líneas en Dart vs. 23.500 en TS). La IA lo hizo, pero con un costo: bandera experimental --enable-experiment=enhanced-parts, part 'file.g.dart' por todos lados, hojas de commits o generación en CI.

La reflexión desaparece con AOT. Type es un stub, sin llamadas a métodos estáticos. DI sin mirrors requiere CLI en JIT → mirrors → codegen. En TS/Java/C#, son tres líneas de reflexión.

Lenguaje: Sintaxis Agradable, Pésima para Metaprogramación

Sintaxis lógica, errores en tiempo de compilación. Pero sin for...in en objetos, sin reflexión. El codegen es una pesadilla: referencias .g.dart ensucian los archivos fuente.

La IA portó ioredis de forma mecánica. Resultado: +5% RPS sobre el mejor cliente de pub.dev. RIP ecosistema backend: nadie escribe código de servidor en Dart.

Benchmarks: Latencia y Memoria lo Hunden

Escenario: 3 endpoints, Postgres, Redis. HTTP puro, sin frameworks. 100m CPU, 500 VUS.

| Métrica | Dart AOT | Node.js | Go |

|---------|----------|---------|----|

| RSS inicio | 3 MB | 18 MB | - |

| Latencia p95 | 9,5 s | 5 s | 2,9 s |

| RPS | 2x peor que Node | - | Mejor en general |

| RSS pico | 39-47 MB | 37 MB | - |

Dart:

• No devuelve memoria al SO (>5% tras pico).
• GC bajo presión: pausas optimizadas para 60fps (Flutter), no RSS para K8s.
• Bajo throttling, se infla a 47 MB; Node se reduce.

Banderas de GC (--dontneed_on_sweep, --use_compactor) no ayudaron. Por diseño: VM para móvil. K8s ve 40 MB/pod constantes, HPA no puede empaquetar nodos eficientemente. Ahorros al inicio se comen por sobreprovisionamiento.

En Cloud Run: Dart cuesta más que Node: más lento + retiene memoria.

Lecciones Clave:

• Latencia p95 9,5 s vs. 5 s de Node = fallos en producción.
• Memoria no liberada: escalado sobrecostoso.
• Ecosistema muerto fuera de Flutter.
• Benchmarks en el repo: manifiestos K8s, perfiles CPU, Dockerfiles.

Veredicto: El Nicho de Dart es Solo Flutter

Dos semanas perdidas en framework, ports, pruebas. Dart brilla en código simple, pero en servidor es un fracaso. Sin reflexión, VM no lista para la nube, codegen infernal. Las promesas oficiales de "APIs escalables para Cloud Run" cayeron en saco roto.

Rechacé Go por err != nil y context.Context. Gana Node.js: libera memoria, mejor latencia.

— Editorial Team