Apresentando a Nulvless: autenticação, autorização e edge functions para SaaS

Todo SaaS acaba construindo a mesma coisa antes de construir qualquer outra: um formulário de cadastro, um e-mail de redefinição de senha, um segundo fator, um fluxo de convite, uma checagem de papel em cada rota e algum lugar para ver quem entrou e de onde. Nada disso é o produto, e tudo isso precisa estar certo.

A Nulvless é a plataforma que queríamos que existisse para essa camada. Este post explica o que ela é, o que já tem hoje e como foi pensada para ser usada.

O problema de costurar tudo

A resposta comum é uma pilha de fornecedores: um para autenticação, outro para e-mail transacional, um terceiro para SMS, algo para feature flags e código próprio para papéis e permissões. Cada peça funciona. Os bugs moram nas emendas entre elas.

Um papel é renomeado em um lugar e não no outro. O provedor de SMS de staging é promovido para produção com credenciais de teste. Uma sessão é revogada, mas o e-mail que confirma isso nunca chega, porque o template vive em outra ferramenta. Ninguém consegue responder "quem mudou essa configuração, e qual era o valor antes?" sem sair perguntando.

Construímos a Nulvless para que a identidade de um usuário, o que ele pode fazer, as mensagens que recebe e o código que roda nas requisições dele vivam em um só modelo, com um só histórico.

O que tem na plataforma

Por baixo de tudo está a Nulvless Network: as requisições chegam ao edge mais próximo do seu usuário, a sessão é verificada ali e suas Edge Functions rodam no mesmo lugar. Uma requisição autenticada não atravessa um oceano para descobrir quem a enviou. Apresentando as Edge Functions explica como isso funciona.

Ambientes desde o primeiro dia

Um ambiente na Nulvless não é uma flag em uma linha. É uma cópia completa do projeto, com seus próprios usuários, sessões, provedores, templates e chaves, respondendo na sua própria URL de emissor:

project · acme
├── main      → acme.nulvless.co
├── staging   → acme-staging.nulvless.co
└── develop   → acme-develop.nulvless.co

Configuração só passa de um para outro quando você promove, e uma promoção começa como um diff que você lê antes de qualquer escrita. Dados nunca passam. Um usuário de teste criado em develop não tem como aparecer em produção, porque nunca esteve naquele armazenamento.

Escrevemos mais sobre o porquê em Por que usuários de staging nunca chegam à produção.

Como fica no código

O SDK roda no navegador com uma chave publicável e no seu servidor com uma chave secreta.

import { createClient } from '@nulvless/nulvless-js';

export const nulvless = createClient('https://acme.nulvless.co', 'pk-…');

const { data, error } = await nulvless.auth.signIn({
  email: '[email protected]',
  password,
});

Apontar o mesmo app para staging é trocar uma URL e uma chave. Nada mais no seu código muda. O quickstart leva você de um projeto vazio a um usuário autenticado.

Onde estamos

A Nulvless está em acesso antecipado. O console, o SDK, a Nulvless Network e tudo o que está listado acima já estão rodando, e estamos trazendo equipes em pequenos grupos para trabalhar de perto com cada uma. Você pode entrar na lista de acesso antecipado pelo console.

Para que serve este blog

Vamos usar este blog para três coisas:

• Anúncios quando algo novo sair, junto com o changelog.
• Engenharia: posts sobre como a plataforma funciona por baixo e as escolhas que fizemos.
• Guias que vão além das docs, de um projeto em branco até algo que você colocaria na frente de usuários.

Se quiser começar por algo prático, leia Login com MFA em um app React.