BaaS vs. Serverless: Qual é a Diferença?

Serverless é um modelo de execução em que o provedor roda o código sob demanda; BaaS é um modelo serverless que entrega o backend pronto. Ou seja, a comparação não é uma disputa entre rivais — é uma questão de escopo. FaaS (o modelo que a maioria chama de “serverless”) roda funções que você ainda escreve. O BaaS vai além e elimina a escrita: auth, banco de dados, armazenamento e APIs chegam como recursos prontos.

Principais pontos

Quem escreve o backend? Duas respostas diferentes

No FaaS, “serverless” significa que sua lógica customizada roda em computação gerenciada e disparada por eventos — mas a lógica continua sendo sua:

// cloud/main.js — a metade FaaS: lógica customizada que você ainda escreve
Parse.Cloud.beforeSave('Review', (request) => {
  const stars = request.object.get('stars');
  if (stars < 1 || stars > 5) {
    throw 'Rating must be between 1 and 5';
  }
});

No BaaS, a resposta muda: para os recursos padrão, não há código de backend a escrever. Cadastrar um usuário — hash de senha, tokens de sessão, checagem de duplicados, fluxo de e-mail — é uma chamada de SDK a partir de qualquer cliente:

// JavaScript / Node.js — Back4app JS SDK
const user = new Parse.User();
user.set('username', 'ada');
user.set('password', 'correct-horse-battery');
user.set('email', '[email protected]');
await user.signUp(); // hashing, session token, email flow — all managed
console.log(`Signed up: ${user.getUsername()}`);

// Flutter / Dart — Back4app Flutter SDK
final user = ParseUser.createUser(
    'ada', 'correct-horse-battery', '[email protected]');
final response = await user.signUp();
if (response.success) {
  print('Signed up: ${user.username}');
}

// iOS / Swift — Back4app Swift SDK
var user = User()
user.username = "ada"
user.password = "correct-horse-battery"
user.email = "[email protected]"
user.signup { result in
  switch result {
  case .success(let user):
    print("Signed up: \(user.username ?? "")")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val user = ParseUser().apply {
  username = "ada"
  setPassword("correct-horse-battery")
  email = "[email protected]"
}
user.signUpInBackground { e ->
  if (e == null) {
    Log.d("Auth", "Signed up: ${user.username}")
  }
}

Os dois exemplos são serverless — nenhum servidor é provisionado, atualizado ou escalado por você. A diferença está no que foi terceirizado: o FaaS terceiriza o runtime; o BaaS terceiriza o próprio backend.

Como os dois modelos se relacionam

A confusão em torno desta comparação é definicional, então vale resolvê-la explicitamente. O enquadramento canônico de Mike Roberts no martinfowler.com — depois adotado pelo whitepaper da CNCF — define serverless como um guarda-chuva com duas metades:

Coloquialmente, porém, “serverless” costuma ser atalho para a metade FaaS — e é por isso que “BaaS vs. serverless” é perguntado como se fossem concorrentes. Formalmente: todo BaaS é serverless, mas nem tudo que é serverless é BaaS.

BaaS vs. FaaS: as diferenças práticas

Casos de uso comuns

• BaaS: backends completos de aplicação. Um app mobile ou web que precisa de contas, dados, arquivos e APIs — os 80% padrão de todo backend — rodando sem time de backend.
• BaaS: MVPs com prazo apertado. Ao validar um produto, semanas de encanamento de auth e CRUD são o custo que você está eliminando, não o valor que está testando.
• FaaS: cola orientada a eventos. Receptores de webhook, confirmações de pagamento e sincronizações com terceiros — reações de vida curta, sem um backend completo ao redor.
• FaaS: processamento de dados. Redimensionar imagens no upload, validar registros no save, jobs agendados de limpeza — computação que roda por segundos e desaparece.
• Os dois: produtos reais em escala. Os recursos padrão rodam na camada BaaS; a lógica customizada inevitável — regras de negócio, integrações, jobs — roda como funções ao lado.

O padrão híbrido: por que raramente é “um ou outro”

A arquitetura de produção mais comum não é uma escolha entre os dois modelos, e sim uma composição deles. A camada BaaS cuida de usuários, dados e armazenamento; um runtime FaaS embutido cuida de tudo que a plataforma não podia prever — a validação beforeSave acima, um webhook de pagamento, um relatório noturno. É por isso que plataformas BaaS maduras entregam funções como recurso de primeira classe: os modelos são camadas complementares, não substitutos. A camada de Backend as a Service define o que você não escreve; a camada de funções define como roda a parte que você escreve.

Você deveria escolher BaaS ou FaaS? Matriz de decisão

Se você marca caixas nas duas colunas — a maioria das aplicações reais marca — escolha um BaaS que embute um runtime FaaS, e a escolha deixa de ser necessária.

Limitações e trade-offs

• Cold starts (metade FaaS). Funções ociosas pagam uma penalidade de provisionamento na primeira invocação, de milissegundos a segundos. A camada de API do BaaS não paga, mas suas funções customizadas podem pagar.
• Teto de customização (metade BaaS). Recursos prontos implementam o caso comum; requisitos muito fora dele — fluxos de auth exóticos, engines de consulta incomuns — podem brigar com a plataforma. A camada de funções embutida é a válvula de escape, mas também tem limites.
• Lock-in (as duas metades). Chamadas de SDK proprietárias e formatos de evento proprietários são, ambos, custos de migração. Plataformas construídas sobre open source neutralizam isso: a stack do Back4app é o Parse Server, auto-hospedável a qualquer momento.
• Custo em escala sustentada (as duas metades). O preço por uso é imbatível quando o tráfego tem picos e brutal quando é constante e pesado. Refaça a conta conforme o uso estabiliza — em qualquer um dos modelos.
• Ausência de estado (metade FaaS). Funções não guardam nada entre invocações; o estado precisa morar no banco ou no cache. Um BaaS torna isso menos doloroso porque o banco gerenciado já está lá.

BaaS e serverless 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. É o padrão híbrido em forma de produto: a camada BaaS provisiona o essencial da arquitetura serverless com cada app. A metade FaaS é o Cloud Code — funções JavaScript, triggers de banco de dados e jobs agendados, com deploy pelo dashboard ou pela CLI. E como toda a stack é open source por baixo, as duas metades permanecem portáteis: a comparação da qual você realmente escapa é “conveniência gerenciada vs. liberdade futura”.