---
term: 'Cloud Code (Funciones Serverless)'
seoTitle: 'Cloud Code y Funciones Serverless: FaaS, Triggers, Cold Starts'
headline: '¿Qué es Cloud Code (Funciones Serverless)?'
slug: cloud-code-funciones-serverless
category: backend-compute
shortDefinition: '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.'
relatedTerms:
  - serverless-architecture
  - baas-vs-serverless
  - iaas-paas-baas-faas
  - webhooks
contrastsWith:
  - edge-computing-edge-functions
aboutTerms:
  - 'FaaS (Functions-as-a-Service)'
  - 'Cloud Functions'
  - 'Triggers de Función (Function Triggers)'
faq:
  - question: '¿Qué es una función serverless?'
    answer: 'Es un bloque pequeño de código server-side, con un solo propósito, que la plataforma ejecuta bajo demanda en respuesta a un evento — una llamada HTTP, un cambio en los datos, una tarea programada. El proveedor se encarga del aprovisionamiento, la escala y el mantenimiento: tú haces deploy de la lógica, y la plataforma es dueña de toda la maquinaria que la ejecuta.'
  - question: '¿Cuál es la diferencia entre FaaS y serverless?'
    answer: 'FaaS — Functions-as-a-Service — es la mitad de cómputo del modelo serverless: funciones individuales activadas por eventos. Serverless es el modelo más amplio, que también incluye los servicios gestionados de backend (base de datos, autenticación, almacenamiento — la mitad BaaS). Cloud Code es el punto donde las dos mitades se encuentran: funciones que corren junto a un backend gestionado.'
  - question: '¿Cómo se activan las funciones serverless?'
    answer: 'Cinco familias: llamadas directas (un cliente o API invoca la función por su nombre), eventos de datos (código que corre antes o después de guardados y borrados), eventos de autenticación (hooks en login y registro), tareas programadas (jobs estilo cron) y webhooks que llegan de sistemas externos. Una buena plataforma expone las cinco como registro de código, no como infraestructura.'
  - question: '¿Qué es un cold start?'
    answer: 'Es la latencia — de cientos de milisegundos a segundos — cuando la plataforma debe inicializar un entorno de ejecución nuevo para una función que había escalado a cero. Las mitigaciones incluyen instancias mínimas calientes y bundles más pequeños; las funciones alojadas en un backend siempre activo sencillamente no pasan por el caso de escalar desde cero.'
  - question: '¿Por qué las funciones serverless deben ser stateless?'
    answer: 'Porque cualquiera de las muchas instancias paralelas y de vida corta puede atender la siguiente solicitud — la memoria retenida entre invocaciones es un bug esperando a desaparecer. El estado persistente pertenece a una base de datos o a un cache. En la variante BaaS, la base de datos ya viene conectada, y ahí está buena parte de la conveniencia del modelo.'
  - question: '¿Cuáles son los límites de las funciones serverless?'
    answer: 'Las plataformas limitan el tiempo de ejecución (segundos por defecto, unos minutos como máximo), la memoria y el tamaño del payload — el trabajo de larga duración pertenece a jobs en background, y un throughput alto y constante puede costar más que un servidor siempre activo. Los límites son el precio de escalar por solicitud.'
  - question: '¿Cuál es la diferencia entre funciones serverless y microservicios?'
    answer: 'Ejes distintos: los microservicios son una descomposición arquitectónica; serverless es un modelo de ejecución. Una función es más granular que un microservicio, y un microservicio puede implementarse como funciones, contenedores o una porción de monolito. Los contenedores compran control y procesos de vida larga; las funciones compran cero operación y escala por solicitud.'
  - question: '¿Las funciones serverless causan vendor lock-in?'
    answer: 'Los formatos de eventos y las herramientas propietarias crean acoplamiento real en plataformas cerradas. El contrapeso es el open source: funciones escritas contra runtimes abiertos — incluido el Cloud Code open-source de Back4app, que corre en cualquier host Node.js — se mueven junto con tu backend en lugar de atarte al sistema de eventos de una sola nube.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Serverless Architectures — Martin Fowler'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'CNCF Serverless Whitepaper'
    url: 'https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview'
  - name: 'Cloud Code guide'
    url: 'https://docs.parseplatform.org/cloudcode/guide/'
  - name: 'OpenFaaS — open-source functions'
    url: 'https://www.openfaas.com/'
  - name: 'Function as a service — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Function_as_a_service'
cta:
  title: 'Funciones que viven con tu backend'
  text: 'El Cloud Code de Back4app ejecuta tu JavaScript junto a la base de datos, la autenticación y los archivos — funciones invocables, triggers de guardado y jobs programados en un solo deploy, sin servidores y sin el impuesto del cold start.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-27'
translationKey: cloud-code-serverless-functions
---

**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

| Pregunta | Respuesta |
| --- | --- |
| Las cuatro propiedades | Activada por eventos · stateless · escala automática · pago por uso |
| Los dos sabores | Unidades FaaS independientes vs. Cloud Code viviendo con tu backend |
| Las familias de triggers | Llamada por nombre · eventos de datos · eventos de auth · cron · webhooks |
| Por qué server-side | Los clientes pueden descompilarse; las funciones no pueden manipularse |
| Los límites honestos | Timeouts, statelessness y cold starts (donde hay escala a cero) |

## 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:**

```javascript
// 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
// 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.
```

**Swift:**

```swift
// 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.
```

**Kotlin:**

```kotlin
// 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:

| Familia de trigger | Se dispara cuando | Uso canónico |
| --- | --- | --- |
| Funciones invocables | Un cliente invoca por nombre con parámetros JSON | Lógica de negocio, agregaciones, acciones |
| Triggers de datos | Antes/después de save, delete, find en una clase | Validación, defaults, cascadas, auditoría |
| Triggers de auth | Antes del login, después de registro/logout | Blocklists, flujos de bienvenida, auditoría |
| Jobs programados | Expresiones cron | Reportes, limpiezas, barridos de TTL, resúmenes |
| [Webhooks](/glossary/webhooks/) entrantes | Un sistema externo hace POST de un evento | Confirmaciones de pago, notificaciones de CI |

```mermaid
flowchart LR
  accTitle: Fuentes de eventos activando funciones serverless junto a un backend gestionado
  accDescr: Llamadas de clientes, eventos de guardado en la base de datos, eventos de autenticación, tareas cron y webhooks externos activan funciones en el servidor, que leen y escriben en la base de datos gestionada, llaman APIs externas con secretos guardados en el servidor y devuelven resultados, con la plataforma escalando la ejecución automáticamente.
  C["Llamada del cliente<br/>por nombre"] --> F["Función<br/>(tu lógica, runtime gestionado)"]
  D["Evento de datos<br/>antes/después del save"] --> F
  A["Evento de auth<br/>login, registro"] --> F
  S["Programación<br/>cron"] --> F
  W["Webhook externo"] --> F
  F --> DB[("Base de datos gestionada<br/>ACLs aplicadas")]
  F -->|"los secretos se quedan en el servidor"| X["APIs de terceros"]
```

## 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](/glossary/api-key-security/) 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

| | Cloud Code (funciones BaaS) | FaaS independiente | Contenedores |
| --- | --- | --- | --- |
| Corre | Dentro del runtime de tu backend | Unidades aisladas por función | Donde tú lo orquestes |
| Contexto | Base de datos, auth y ACLs ya conectados | Cada servicio cableado a mano | Lo que tú construyas |
| Unidad de deploy | Un codebase, un deploy | Por función | Por imagen |
| Cold starts | Ninguno — el backend ya está arriba | Sí, al escalar desde cero | Solo si escalas a cero |
| Operaciones privilegiadas | Acceso con master key para lógica admin | Cableado IAM por función | Tu propia malla de auth |
| Escala | Junto con el backend | Por solicitud, hasta cero | Según lo configures |
| Encaja con | Backends de apps en un BaaS | Trabajo de eventos aislado y con picos | Servicios de vida larga y con estado |

El artículo de [arquitectura serverless](/glossary/es/arquitectura-serverless/) cubre el modelo en general y [el lugar del FaaS en la escalera de servicios](/glossary/es/modelos-de-servicio-en-la-nube/) 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](/glossary/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

| Trabajo | Lugar |
| --- | --- |
| Lógica que los clientes podrían manipular | Función — siempre |
| Tareas con picos, con forma de evento | Función |
| Cómputo de larga duración (minutos o más) | Job en background, no función |
| Servicios con estado, siempre activos (sockets, colas) | Contenedores / servicios de plataforma |
| Hot path crítico de latencia a volumen alto y constante | Mide — el siempre-activo puede ganar |
| Todo lo que toca un secreto | Función — el secreto nunca se embarca |

## 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](/glossary/class-level-permissions-clp/) 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.