Dart Cloud Functions para Firebase: qué es y cuándo (no) usarlo

Respuesta directa: Dart Cloud Functions para Firebase es una capacidad experimental, anunciada en Google Cloud Next 2026, que te permite escribir el backend de tu app en el mismo lenguaje que el cliente Flutter. Compila a binario nativo con AOT (arranque en frío casi inmediato) y se despliega con la Firebase CLI, sin Dockerfiles. Hoy es útil para MVPs y endpoints HTTP de equipos Flutter pequeños; no sustituye todavía a un backend Go en Cloud Run para cargas de alta concurrencia, triggers de eventos o producción crítica.

En Dribba llevamos desde 2011 construyendo apps con Flutter —somos Flutter Partner oficial de Google desde 2017, la única agencia española en el directorio— y también backends en Go sobre Cloud Run. Cuando aparece una pieza que toca ambos mundos, la miramos con lupa. Esto es lo que hemos entendido de Dart Functions y cómo decidir si encaja en tu stack.

¿Qué es exactamente?

Cloud Functions para Firebase soporta desde hace años Node.js/TypeScript y Python. En 2026 se suma soporte experimental para Dart: escribes funciones serverless en Dart, la Firebase CLI las compila a un binario nativo y las sube a la infraestructura de Google Cloud (por debajo, Cloud Run).

La diferencia de fondo frente a Node o Python es el modelo de ejecución. Dart usa compilación AOT (Ahead-of-Time): tu código se convierte en un binario nativo que arranca sin fase de calentamiento, a diferencia de los runtimes basados en JIT o en máquinas virtuales pesadas. En serverless, donde el arranque en frío es el enemigo, esto importa.

El argumento estratégico es el de siempre en full-stack Dart: una sola fuente de verdad. Compartes modelos, validaciones y utilidades entre el cliente Flutter y el servidor, sin duplicar lógica ni mantener dos representaciones del mismo dato en dos lenguajes distintos.

Cómo se ve en la práctica

Primero activas el experimento:

firebase experiments:enable dartfunctions

Defines la función usando el paquete firebase_functions. El caso más común es un endpoint HTTP (onRequest) o una función invocable (onCall):

import 'package:firebase_functions/firebase_functions.dart';

void main() {
  FirebaseFunctions.instance.https.onRequest((request) async {
    request.response.write('Hola desde Dart');
    await request.response.close();
  });
}

Pruebas en local con el emulador —que además vigila el código fuente y recarga la función al guardar— y despliegas sin gestionar contenedores:

firebase emulators:start
firebase deploy --only functions

No hay Dockerfile, ni registro de imágenes, ni pipeline de contenedores que mantener. La CLI se encarga de la compilación y el despliegue.

Qué soporta hoy y qué no

Aquí está el matiz que evita sorpresas en producción. Es una release experimental y limitada:

Solo se despliegan triggers HTTP (onRequest) y funciones invocables (onCall). Otros tipos de trigger (eventos de Firestore, Storage, Pub/Sub, schedulers) funcionan en el emulador, pero no se pueden desplegar todavía.
Las funciones onCall en Dart no se invocan con el httpsCallable() estándar de los SDK cliente: hay que usar httpsCallableFromURL() con la URL completa de Cloud Run.
Se marca como experimental y la API puede cambiar sin previo aviso.

Traducido: sirve para exponer lógica de backend por HTTP, no para orquestar reacciones a eventos de tu base de datos. Ese trabajo sigue siendo territorio de funciones Node/Python o de un servicio propio.

Dart Functions vs. las alternativas

Criterio	Dart Functions (Firebase)	TS/Node Functions	Go en Cloud Run
Arranque en frío	Muy bajo (binario AOT)	Medio (runtime Node)	Muy bajo (binario)
Lenguaje compartido con Flutter	Sí	No	No
Triggers de eventos (Firestore, Pub/Sub…)	No (solo emulador)	Sí	Sí (con setup)
Madurez / estabilidad	Experimental	Madura	Madura
Control de infraestructura	Bajo (gestionado)	Bajo (gestionado)	Alto
Ecosistema de librerías backend	En crecimiento	Amplio	Amplio

Cuándo NO deberías usarlo (todavía)

Somos partidarios de nombrar los límites antes que las bondades:

Alta concurrencia o rendimiento sostenido. Para un backend que aguanta picos serios, el ecosistema y la madurez de Go sobre Cloud Run siguen siendo la apuesta segura.
Necesitas triggers de eventos. Si tu arquitectura reacciona a escrituras en Firestore, subidas a Storage o mensajes de Pub/Sub en producción, hoy no es viable con Dart.
Producción crítica sin margen para sorpresas. "Experimental" significa que la API puede moverse; no lo pongas en la ruta crítica de un producto en vivo sin plan de contingencia.
Equipos backend separados del equipo móvil. La ventaja del lenguaje compartido se diluye si quien mantiene el servidor no toca Flutter.

Donde sí brilla: MVPs, prototipos y equipos Flutter pequeños que quieren un endpoint HTTP rápido sin montar y mantener un servicio backend completo, aprovechando modelos y validaciones ya escritos en Dart.

Cómo lo vemos desde el stack real

La lectura honesta es que Dart Functions no es "el fin de Go", sino una herramienta más en el abanico. En proyectos donde el equipo es 100% Flutter y la lógica de servidor es un puñado de endpoints HTTP, compartir lenguaje reduce fricción real. En productos con backend exigente, seguimos eligiendo Go en Cloud Run por rendimiento y control. La decisión no es de moda: es de encaje entre la carga, el equipo y el ciclo de vida del producto.

Si estás valorando tu arquitectura backend, en Dribba —equipo senior in-house entre Barcelona y Andorra— ayudamos a decidir el stack sin dogmas y a construirlo. Puedes ver cómo comparamos Dart full-stack frente a Go, por qué elegimos Go para alto rendimiento o cómo servimos inferencia serverless en Cloud Run.

Conclusión

Dart Cloud Functions para Firebase es una señal clara de hacia dónde va el ecosistema: un stack donde cliente y servidor hablan el mismo idioma. Hoy es experimental y acotado a HTTP/callables, así que su sitio está en MVPs y equipos Flutter, no en backends de misión crítica. Vale la pena tenerlo en el radar y probarlo en el emulador; para producción seria, mide antes de mover nada de tu backend actual.

Dart Cloud Functions para Firebase: qué es y cuándo (no) usarlo