¿Qué es Cloud Code (Funciones Serverless)?

Cloud Code es un modelo serverless donde la lógica de backend se ejecuta como funciones en el servidor, activadas por llamadas, eventos de datos o cron. Dos aclaraciones de entrada, porque esta familia de términos vive enredada. Primero, “serverless” significa que los servidores son problema de otro — existen, invisibles, escalados por ti sin que los toques. Segundo, las funciones vienen en dos arquitecturas: el FaaS independiente, donde cada función es una unidad aislada cableada a servicios externos, y la variante BaaS que da nombre a este artículo — funciones desplegadas dentro de tu backend, compartiendo entorno con la base de datos, la autenticación y los archivos sobre los que actúan.

Puntos clave

Una función, llamada desde cualquier lugar

El ejemplo clásico de agregación — computar junto a los datos y enviar solo la respuesta:

// JavaScript / Node.js — Back4app JS SDK
// Calling a Cloud Code function: server-side logic, one line from the client
const avg = await Parse.Cloud.run('averageStars', { movie: 'Arrival' });
// The aggregation ran NEXT TO the database — only the answer crossed the wire

// The function itself (cloud/main.js — deployed to your backend, not the app):
// Parse.Cloud.define('averageStars', async (req) => {
//   const q = new Parse.Query('Review').equalTo('movie', req.params.movie);
//   const reviews = await q.find({ useMasterKey: true });
//   return reviews.reduce((s, r) => s + r.get('stars'), 0) / reviews.length;
// });

// Flutter / Dart — Back4app Flutter SDK
// Calling a Cloud Code function: server-side logic, one line from the client
final response = await ParseCloudFunction('averageStars')
    .execute(parameters: {'movie': 'Arrival'});
final avg = response.result;
// The aggregation ran NEXT TO the database — only the answer crossed the wire
// The function lives in cloud/main.js on your backend — update it anytime;
// every client gets the new logic instantly, no app-store release required.

// iOS / Swift — Back4app Swift SDK
// Calling a Cloud Code function: server-side logic, one line from the client
let avg: Double = try await Cloud.run(name: "averageStars",
                                      parameters: ["movie": "Arrival"])
// The aggregation ran NEXT TO the database — only the answer crossed the wire
// The function lives in cloud/main.js on your backend — update it anytime;
// every client gets the new logic instantly, no app-store release required.

// Android / Kotlin — Back4app Android SDK
// Calling a Cloud Code function: server-side logic, one line from the client
val params = mapOf("movie" to "Arrival")
val avg = ParseCloud.callFunction<Double>("averageStars", params)
// The aggregation ran NEXT TO the database — only the answer crossed the wire
// The function lives in cloud/main.js on your backend — update it anytime;
// every client gets the new logic instantly, no app-store release required.

Promediar mil reseñas en el teléfono significa descargar mil reseñas; la versión con función mueve un solo número. Ese argumento de ancho de banda se generaliza en el caso completo a favor de la lógica server-side, justo abajo.

La taxonomía de triggers

Las explicaciones superficiales listan los triggers en una frase; la estructura merece una tabla:

Por qué la lógica pertenece al servidor

Cuatro argumentos, casi siempre ausentes de las explicaciones habituales. No confíes en el cliente: las apps se descompilan y las solicitudes se falsifican; los cálculos de precio, chequeos de permisos y puntajes de juego computados en el dispositivo son sugerencias, mientras que la misma lógica en una función es ley — un trigger beforeSave valida cada escritura sin importar qué cliente la envió. Los secretos se quedan en casa: las claves de APIs de terceros viven en el entorno de la función, nunca en un bundle que cualquiera puede desempacar — la disciplina de claves de API vuelta estructural. Actualiza sin release: los cambios en la lógica del servidor llegan al instante a todos los usuarios, sin ciclo de revisión de tienda de aplicaciones entre la corrección y lo corregido. Computa cerca de los datos: agregación, moldeado de búsquedas y fan-out corren a microsegundos de la base de datos, no al otro lado de una red móvil.

Cloud Code vs. FaaS independiente vs. contenedores

El artículo de arquitectura serverless cubre el modelo en general y el lugar del FaaS en la escalera de servicios tiene artículo propio; la fila que importa aquí es contexto: las funciones de Cloud Code nacen conectadas — el mismo SDK, la misma semántica de sesión, ACLs aplicadas a sus queries — mientras que el FaaS independiente empieza cada proyecto por la plomería.

Cold starts y statelessness, sin rodeos

Dos propiedades se desprenden de la escala por solicitud, y ambas merecen decirse con claridad. Los cold starts ocurren cuando una función escalada a cero debe inicializar un entorno antes de correr — de cientos de milisegundos a segundos en las plataformas típicas, mitigados con instancias mínimas calientes y bundles ligeros, y arquitectónicamente ausentes en funciones alojadas en un backend siempre activo, lo cual es una diferencia genuina entre los dos sabores, no fanfarronería de proveedor. Statelessness significa que, por contrato, nada en memoria sobrevive entre invocaciones: contadores, caches y sesiones guardados en una función son bugs con hora marcada. El estado va a la base de datos — y la ventaja silenciosa de la variante BaaS es que la base de datos está a una línea de distancia, no detrás de un servicio que primero debes elegir, conectar y asegurar.

Casos de uso comunes

• Validación y reglas de negocio — puertas de beforeSave que vuelven las invariantes innegociables en todos los clientes.
• Agregaciones y reportes — computa junto a los datos; devuelve respuestas, no datasets.
• Integración con terceros — pagos, email, APIs de AI llamadas con secretos guardados en el servidor.
• Receptores y emisores de webhooks — funciones como las caras HTTP de las integraciones por eventos.
• Mantenimiento programado — resúmenes, limpiezas y barridos en cron, sin flota de workers que operar.

¿Deberías convertirlo en una función? Matriz de decisión

Limitaciones y trade-offs

• Los timeouts son contratos. Las funciones tienen techos de segundos a minutos; el trabajo que pueda excederlos necesita una cola de jobs, no esperanza.
• El statelessness es estricto. Cualquier cosa en memoria es efímera; los diseños que lo olvidan pasan los tests y fallan bajo scale-out.
• La proliferación es el modo de falla. Cincuenta funciones pequeñas sin módulos compartidos ni disciplina de nombres se convierten en un monolito distribuido con peores herramientas.
• Depurar es remoto por naturaleza. Logs y traces reemplazan a los breakpoints; las plataformas con buenas superficies de logs se ganan el sustento aquí.
• El costo se invierte bajo carga constante. Pagar por uso es imbatible para trabajo con picos y batible por servidores siempre activos a throughput alto y constante — ponle precio a la curva, no al folleto.

Cloud Code en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Aquí, Cloud Code es el sabor BaaS en su forma original: JavaScript desplegado dentro de tu backend en Back4app — Parse.Cloud.define para funciones invocables como la del ejemplo en las pestañas de código, triggers beforeSave/afterSave para reglas de datos, hooks de auth y jobs programados, todo en un codebase y un deploy. Las funciones corren con el contexto conectado: el mismo SDK que usan tus clientes, ACLs y permisos a nivel de clase aplicados a las queries, acceso con master key disponible cuando la lógica administrativa legítimamente necesita omitirlos, y secretos en la configuración server-side. Como el backend está siempre corriendo, el cold start de escalar desde cero simplemente no aplica — y como la plataforma es open source, las funciones son portables a cualquier host que la ejecute, que es la respuesta práctica a la pregunta del lock-in.