---
term: 'Cloud Code (Funções Serverless)'
seoTitle: 'Cloud Code e Funções Serverless: FaaS, Gatilhos, Cold Starts'
headline: 'O que é Cloud Code (Funções Serverless)?'
slug: cloud-code-funcoes-serverless
category: backend-compute
shortDefinition: 'Cloud Code é um modelo serverless em que a lógica de backend roda como funções no servidor, disparadas por chamadas, eventos de dados ou agendamentos.'
relatedTerms:
  - serverless-architecture
  - baas-vs-serverless
  - iaas-paas-baas-faas
  - webhooks
contrastsWith:
  - edge-computing-edge-functions
aboutTerms:
  - 'FaaS (Functions-as-a-Service)'
  - 'Cloud Functions'
  - 'Gatilhos de Função (Function Triggers)'
faq:
  - question: 'O que é uma função serverless?'
    answer: 'É um bloco pequeno de código server-side, com um único propósito, que a plataforma executa sob demanda em resposta a um evento — uma chamada HTTP, uma mudança nos dados, um agendamento. O provedor cuida de provisionamento, escala e manutenção: você faz deploy da lógica, e a plataforma é dona de toda a máquina que a executa.'
  - question: 'Qual a diferença entre FaaS e serverless?'
    answer: 'FaaS — Functions-as-a-Service — é a metade de computação do serverless: funções individuais disparadas por eventos. Serverless é o modelo mais amplo, que inclui também os serviços gerenciados de backend (banco de dados, autenticação, armazenamento — a metade BaaS). O Cloud Code é o ponto onde as duas metades se encontram: funções rodando junto de um backend gerenciado.'
  - question: 'Como as funções serverless são disparadas?'
    answer: 'Cinco famílias: chamadas diretas (um cliente ou API invoca a função pelo nome), eventos de dados (código que roda antes ou depois de gravações e exclusões), eventos de autenticação (hooks em login e cadastro), agendamentos (jobs estilo cron) e webhooks recebidos de sistemas externos. Uma boa plataforma expõe as cinco como registro de código, não como infraestrutura.'
  - question: 'O que é cold start?'
    answer: 'É a latência — de centenas de milissegundos a segundos — quando a plataforma precisa inicializar um ambiente de execução novo para uma função que havia escalado a zero. As mitigações incluem instâncias mínimas aquecidas e bundles menores; funções hospedadas em um backend sempre ativo simplesmente não passam pelo caso de escalar a partir do zero.'
  - question: 'Por que funções serverless precisam ser stateless?'
    answer: 'Porque qualquer uma das muitas instâncias paralelas e de vida curta pode atender a próxima requisição — memória mantida entre invocações é um bug esperando para sumir. Estado persistente pertence a um banco de dados ou cache. Na variante BaaS, o banco de dados já vem conectado, o que é boa parte da conveniência do modelo.'
  - question: 'Quais são os limites das funções serverless?'
    answer: 'As plataformas limitam tempo de execução (segundos por padrão, alguns minutos no máximo), memória e tamanho de payload — trabalho de longa duração pertence a jobs em background, e throughput pesado e constante pode custar mais que um servidor sempre ativo. Os limites são o preço da escala por requisição.'
  - question: 'Qual a diferença entre funções serverless e microsserviços?'
    answer: 'Eixos diferentes: microsserviços são uma decomposição arquitetural; serverless é um modelo de execução. Uma função é mais granular que um microsserviço, e um microsserviço pode ser implementado como funções, contêineres ou uma fatia de monólito. Contêineres compram controle e processos de vida longa; funções compram zero operação e escala por requisição.'
  - question: 'Funções serverless causam vendor lock-in?'
    answer: 'Formatos de evento e ferramentas proprietários criam acoplamento real em plataformas fechadas. O contrapeso é o open source: funções escritas contra runtimes abertos — incluindo o Cloud Code open-source do Back4app, que roda em qualquer host Node.js — se movem junto com o seu backend em vez de prendê-lo ao sistema de eventos de uma única nuvem.'
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: 'Funções que vivem com o seu backend'
  text: 'O Cloud Code do Back4app roda seu JavaScript ao lado do banco de dados, da autenticação e dos arquivos — funções chamáveis, gatilhos de gravação e jobs agendados em um único deploy, sem servidores e sem a taxa do cold start.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-20'
translationKey: cloud-code-serverless-functions
---

**Cloud Code é um modelo serverless em que a lógica de backend roda como funções no servidor, disparadas por chamadas, eventos de dados ou agendamentos.** Dois esclarecimentos logo de início, porque essa família de termos vive embolada. Primeiro, "serverless" significa que os servidores são *problema de outra pessoa* — eles existem, invisíveis, escalados por você sem que você toque neles. Segundo, funções vêm em duas arquiteturas: o **FaaS** independente, em que cada função é uma unidade isolada ligada a serviços externos, e a **variante BaaS** que dá nome a este artigo — funções implantadas *dentro* do seu backend, compartilhando o ambiente com o banco de dados, a autenticação e os arquivos sobre os quais elas agem.

## Principais pontos

| Pergunta | Resposta |
| --- | --- |
| As quatro propriedades | Disparada por eventos · stateless · escala automática · pagamento por uso |
| Os dois sabores | Unidades FaaS independentes vs. Cloud Code morando com o seu backend |
| As famílias de gatilhos | Chamada pelo nome · eventos de dados · eventos de auth · agendamentos · webhooks |
| Por que server-side | Clientes podem ser descompilados; funções não podem ser adulteradas |
| Os limites honestos | Timeouts, statelessness e cold starts (onde há escala a zero) |

## Uma função, chamada de qualquer lugar

O exemplo clássico de agregação — computar ao lado dos dados e enviar só a resposta:

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

Calcular a média de mil avaliações no celular significa baixar mil avaliações; a versão em função move um único número. Esse argumento de banda se generaliza no caso completo a favor da lógica server-side, logo abaixo.

## A taxonomia de gatilhos

Explicações rasas listam os gatilhos em uma frase; a estrutura merece uma tabela:

| Família de gatilho | Dispara quando | Uso canônico |
| --- | --- | --- |
| Funções chamáveis | Um cliente invoca pelo nome com parâmetros JSON | Lógica de negócio, agregações, ações |
| Gatilhos de dados | Antes/depois de save, delete, find em uma classe | Validação, defaults, cascatas, auditoria |
| Gatilhos de auth | Antes do login, depois de cadastro/logout | Blocklists, fluxos de boas-vindas, auditoria |
| Jobs agendados | Expressões cron | Relatórios, limpezas, varreduras de TTL, resumos |
| [Webhooks](/glossary/webhooks/) recebidos | Um sistema externo faz POST de um evento | Confirmações de pagamento, notificações de CI |

```mermaid
flowchart LR
  accTitle: Fontes de eventos disparando funções serverless ao lado de um backend gerenciado
  accDescr: Chamadas de clientes, eventos de gravação no banco de dados, eventos de autenticação, agendamentos cron e webhooks externos disparam funções no servidor, que leem e gravam no banco de dados gerenciado, chamam APIs externas com segredos mantidos no servidor e retornam resultados, com a plataforma escalando a execução automaticamente.
  C["Chamada do cliente<br/>pelo nome"] --> F["Função<br/>(sua lógica, runtime gerenciado)"]
  D["Evento de dados<br/>antes/depois do save"] --> F
  A["Evento de auth<br/>login, cadastro"] --> F
  S["Agendamento<br/>cron"] --> F
  W["Webhook externo"] --> F
  F --> DB[("Banco de dados gerenciado<br/>ACLs aplicadas")]
  F -->|"segredos ficam no servidor"| X["APIs de terceiros"]
```

## Por que a lógica pertence ao servidor

Quatro argumentos, quase sempre ausentes das explicações comuns. **Não confie no cliente:** apps são descompilados e requisições são forjadas; cálculos de preço, checagens de permissão e pontuações de jogo computados no dispositivo são sugestões, enquanto a mesma lógica em uma função é lei — um gatilho `beforeSave` valida toda gravação, não importa qual cliente a enviou. **Segredos ficam em casa:** chaves de APIs de terceiros vivem no ambiente da função, nunca em um bundle que qualquer um pode desempacotar — a [disciplina de chaves de API](/glossary/api-key-security/) tornada estrutural. **Atualize sem release:** mudanças na lógica do servidor chegam instantaneamente a todos os usuários, sem ciclo de revisão de loja de aplicativos entre a correção e o corrigido. **Compute perto dos dados:** agregação, moldagem de busca e fan-out rodam a microssegundos do banco de dados, e não do outro lado de uma rede móvel.

## Cloud Code vs. FaaS independente vs. contêineres

| | Cloud Code (funções BaaS) | FaaS independente | Contêineres |
| --- | --- | --- | --- |
| Roda | Dentro do runtime do seu backend | Unidades isoladas por função | Onde você orquestrar |
| Contexto | Banco, auth e ACLs já conectados | Cada serviço ligado manualmente | O que você construir |
| Unidade de deploy | Um codebase, um deploy | Por função | Por imagem |
| Cold starts | Nenhum — o backend já está de pé | Sim, ao escalar a partir do zero | Só se você escalar a zero |
| Operações privilegiadas | Acesso com master key para lógica admin | Fiação IAM por função | Sua própria malha de auth |
| Escala | Junto com o backend | Por requisição, até zero | Conforme configurado |
| Combina com | Backends de apps em um BaaS | Trabalho de evento isolado e com picos | Serviços de vida longa e com estado |

O verbete de [arquitetura serverless](/glossary/pt/arquitetura-serverless/) cobre o modelo em geral e [o lugar do FaaS na escada de serviços](/glossary/pt/modelos-de-servico-em-nuvem/) tem artigo próprio; a linha que importa aqui é *contexto*: funções de Cloud Code nascem conectadas — o mesmo SDK, a mesma semântica de sessão, ACLs aplicadas às suas queries — enquanto o FaaS independente começa todo projeto pelo encanamento.

## Cold starts e statelessness, sem rodeios

Duas propriedades decorrem da escala por requisição, e ambas merecem ser ditas com clareza. **Cold starts** acontecem quando uma função escalada a zero precisa inicializar um ambiente antes de rodar — de centenas de milissegundos a segundos nas plataformas típicas, mitigados por instâncias mínimas aquecidas e bundles enxutos, e *arquiteturalmente ausentes* em funções hospedadas em um backend sempre ativo, o que é uma diferença genuína entre os dois sabores, não bravata de fornecedor. **Statelessness** significa que, por contrato, nada em memória sobrevive entre invocações: contadores, caches e sessões guardados em uma função são bugs com hora marcada. Estado vai para o banco de dados — e a vantagem silenciosa da variante BaaS é que o banco está a uma linha de distância, e não atrás de um serviço que você precisa escolher, conectar e proteger primeiro.

## Casos de uso comuns

- **Validação e regras de negócio** — gates de `beforeSave` que tornam invariantes inegociáveis em todos os clientes.
- **Agregações e relatórios** — compute ao lado dos dados; devolva respostas, não datasets.
- **Integração com terceiros** — pagamentos, e-mail, APIs de AI chamadas com segredos mantidos no servidor.
- **Receptores e emissores de [webhooks](/glossary/webhooks/)** — funções como as faces HTTP das integrações por eventos.
- **Manutenção agendada** — resumos, limpezas e varreduras no cron, sem frota de workers para operar.

## Isso deveria ser uma função? Matriz de decisão

| Trabalho | Lugar |
| --- | --- |
| Lógica que clientes poderiam adulterar | Função — sempre |
| Tarefas com picos, no formato de eventos | Função |
| Computação de longa duração (minutos ou mais) | Job em background, não função |
| Serviços com estado, sempre ativos (sockets, filas) | Contêineres / serviços de plataforma |
| Hot path crítico de latência em volume alto e constante | Meça — o sempre-ativo pode vencer |
| Tudo que toca um segredo | Função — o segredo nunca embarca |

## Limitações e trade-offs

- **Timeouts são contratos.** Funções têm teto de segundos a minutos; trabalho que pode estourar o teto precisa de uma fila de jobs, não de esperança.
- **Statelessness é estrito.** Qualquer coisa em memória é efêmera; designs que esquecem isso passam nos testes e quebram sob scale-out.
- **Proliferação é o modo de falha.** Cinquenta funções pequenas sem módulos compartilhados e disciplina de nomes viram um monólito distribuído com ferramentas piores.
- **Depurar é remoto por natureza.** Logs e traces substituem breakpoints; plataformas com boas superfícies de log ganham o próprio sustento aqui.
- **O custo inverte sob carga constante.** Pagar por uso é imbatível para trabalho com picos e batível por servidores sempre ativos em throughput alto e constante — precifique a curva, não o folheto.

## Cloud Code no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Aqui, Cloud Code é o sabor BaaS na forma original: JavaScript implantado dentro do seu backend no Back4app — `Parse.Cloud.define` para funções chamáveis como a do exemplo nas abas de código, gatilhos `beforeSave`/`afterSave` para regras de dados, hooks de auth e jobs agendados, tudo em um codebase e um deploy. As funções rodam com contexto conectado: o mesmo SDK que seus clientes usam, ACLs e [permissões em nível de classe](/glossary/class-level-permissions-clp/) aplicadas às queries, acesso com master key disponível quando a lógica administrativa legitimamente precisa contorná-las, e segredos na configuração server-side. Como o backend está sempre rodando, o cold start de escalar a partir do zero simplesmente não se aplica — e como a plataforma é open source, as funções são portáveis para qualquer host que a execute, o que é a resposta prática à pergunta do lock-in.