Dart en el backend: cuándo Dart Cloud Functions compensa y cuándo seguir con Go en Cloud Run

La respuesta corta

Desde mayo de 2026 puedes escribir Cloud Functions para Firebase en Dart. Para un equipo Flutter la idea es tentadora: un solo lenguaje en el cliente y en el servidor, los mismos modelos en los dos lados, sin traducir DTOs a mano.

Nuestra recomendación, después de mirarlo con calma: pruébalo si tienes un par de endpoints HTTP y tu equipo ya vive en Dart. No muevas ahí el backend de un producto en producción todavía. El soporte es experimental y le faltan piezas que se notan justo el día que las necesitas. Go sobre Cloud Run sigue siendo nuestra opción por defecto para backend serio, y más abajo está el criterio con el que trazamos la línea.

Qué es Dart Cloud Functions y cómo funciona

Firebase anunció el soporte experimental de Dart en Cloud Functions en mayo de 2026. Compila distinto al resto: en vez de subir el código fuente para que se compile en la nube, como pasa con Node.js o Python, la CLI de Firebase ejecuta la compilación Dart en tu máquina y sube el binario ya generado a Cloud Run functions. Es compilación ahead-of-time (AOT) a binario nativo, y de ahí salen los cold starts bajos: el binario arranca sin fase de calentamiento.

Para empezar necesitas Dart SDK 3.9 o superior, Firebase CLI 15.15.0 o superior y el plan Blaze para desplegar (el emulador funciona en cualquier plan). Se activa con una bandera:

firebase experiments:enable dartfunctions

Un endpoint HTTP mínimo se parece a esto:

import 'package:firebase_functions/firebase_functions.dart';

final saludo = onRequest((request, response) {
  response.send('Hola desde Dart');
});

Se despliegan dos tipos de trigger: HTTP (onRequest) y callable (onCall). El resto, como los triggers de Firestore, corren en el emulador local pero no se pueden desplegar todavía.

Por qué atrae

El argumento fuerte es compartir código. Un equipo Flutter puede reutilizar modelos, lógica de validación y utilidades entre cliente y servidor. Se acaba la deriva silenciosa entre el modelo del móvil y el del backend, ese bug que aparece cuando alguien añade un campo en un lado y olvida el otro. Escribes la validación una vez y la usas en los dos sitios.

El segundo argumento es operativo. Un equipo pequeño que ya domina Dart no tiene que montar ni mantener un stack de backend aparte para exponer cuatro endpoints. Menos lenguajes en el repositorio, menos contexto que cargar en la cabeza cada mañana.

Lo experimental, sin adornos

Aquí conviene bajar el entusiasmo. "Experimental" no es una etiqueta de cortesía:

• La consola de Firebase no muestra las funciones Dart. Las ves en la página de Cloud Run functions de la consola de Google Cloud, no donde esperas. Un detalle menor hasta que estás depurando a las once de la noche.
• Las callable no se llaman por nombre. El trigger onCall se despliega, pero no puedes invocarlo desde los SDK de cliente con httpsCallable, que localiza la función por su nombre. Tienes que usar httpsCallableFromURL con la URL completa de Cloud Run:

final callable = FirebaseFunctions.instance.httpsCallableFromURL(
  'https://tu-funcion-xxxx.run.app',
);

• Los triggers de eventos no se despliegan. Si tu lógica reacciona a escrituras en Firestore o a mensajes de Pub/Sub, hoy no es tu herramienta.
• La API puede cambiar sin aviso. Es la definición de experimental. Lo que escribas ahora quizá haya que tocarlo cuando estabilicen la interfaz.

Nada de esto es un defecto oculto; está en la documentación oficial. Pero cambia bastante la conversación entre "escribo mi backend en Dart" y "expongo un par de endpoints HTTP en Dart mientras el resto madura".

Cuándo lo usaríamos

Dart Cloud Functions encaja cuando:

• Tienes un equipo Flutter y pocos endpoints HTTP o callable.
• El valor de compartir modelos y validación entre cliente y servidor es alto para tu caso.
• Estás en un MVP, una prueba de concepto o una feature acotada donde asumir una API experimental es un riesgo pequeño y reversible.
• No tienes tiempo ni ganas de montar un backend separado.

En ese perfil, el ahorro de contexto es real y el riesgo está contenido.

Cuándo no: por qué seguimos con Go sobre Cloud Run

En Dribba construimos backend en Go sobre Cloud Run, y ahí es donde dejamos los productos que tienen que aguantar. Go es donde está la madurez que un backend de producción necesita.

Nos quedamos en Go cuando el producto tiene flujos dirigidos por eventos (reacciones a Firestore, Pub/Sub, Eventarc), que hoy en Dart no se despliegan. Cuando necesitamos observabilidad de verdad, con métricas, trazas y un catálogo de librerías probado en producción. Cuando el equipo que va a mantener el servicio no es solo Flutter, y meter Dart en el backend no ahorra contexto, lo añade. Y cuando no queremos apostar la infraestructura de un cliente a una API que puede cambiar sin aviso.

El cold start de Go en Cloud Run ya es bajo, así que la ventaja de arranque de Dart no compensa por sí sola renunciar a lo demás.

	Dart Cloud Functions	Go sobre Cloud Run
Madurez	Experimental (mayo 2026)	Estable, producción
Triggers desplegables	HTTP y callable	HTTP, Pub/Sub, Eventarc
Modelos compartidos con Flutter	Sí	No
Cold start	Muy bajo (AOT nativo)	Bajo
Visible en consola Firebase	No, solo en Cloud Run	N/A
Librerías y observabilidad	Naciente	Maduro

Cómo decidir en cinco minutos

Tres preguntas:

1. ¿Tu backend reacciona a eventos (Firestore, Pub/Sub) o son endpoints HTTP? Si hay eventos, Go.
2. ¿Quién mantiene el servicio? Si el equipo no es todo Flutter, el idioma compartido pierde valor y gana Go.
3. ¿Cuánto duele si la API cambia? Si es un MVP, adelante con Dart; si es infraestructura de producto, espera a que estabilicen.

Si las tres respuestas apuntan a Dart, tienes una razón buena para probarlo. Si una sola apunta a Go, quédate en Go.

En resumen

Dart en el backend es una buena noticia para quien trabaja con Flutter y una herramienta legítima para casos acotados. No es todavía el sitio donde poner el backend de un producto que factura. Nosotros lo usaríamos para un prototipo o una feature aislada, y mantendríamos Go sobre Cloud Run para lo que tiene que seguir en pie dentro de dos años.

Si estás trazando la arquitectura de backend de tu producto Flutter y quieres una opinión con las cicatrices puestas, es justo la conversación que tenemos cada semana. Así trabajamos el staff augmentation con Flutter.