O que é Cloud Code (Funções Serverless)?

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

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

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:

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

O verbete de arquitetura serverless cobre o modelo em geral e o lugar do FaaS na escada de serviços 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 — 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

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