No momento em que um site precisa lembrar de algo — uma reserva, uma inscrição, um membro — ele deixa de ser uma página e vira software. É aí que os projetos travam: agora você precisa de banco de dados, uma API, permissões e uma tela para ler o que chegou. Descrever o que o site coleta deveria bastar, e aqui basta.
| Fazer você mesmo | 54 | |
|---|---|---|
| Criar os dados | Desenhar tabelas, escrever o schema | Descrever o que o site coleta |
| Permissões | Escrever políticas de row level security | O dono lê o admin, o público só escreve pelo formulário |
| O formulário | Construir e ligar à API | Criado junto com a coleção |
| Ler o que chegou | Construir uma tela de admin | Já está lá |
| Contas de usuário | Escolher um provedor e integrar | Login por código no e-mail, incluso |
Escrito a partir da documentação pública de cada produto. Produtos mudam: confira o deles antes de decidir. Pelo mesmo motivo, aqui não há preços da concorrência.
Não. Você nunca vê. Essa é a troca: você também não tem o poder bruto do SQL, e se precisa dele, quer um provedor de Postgres de verdade.
Nas coleções do seu próprio site, alcançáveis só por você pelo admin e pelas suas páginas através do formulário.
Sim, quando quiser.
A pessoa coloca o e-mail, recebe um código e entra. Nada para lembrar, e nenhuma base de senhas para você proteger.
Sim: páginas que mostram o conteúdo apenas para quem está logado.
Sim, pelo admin: ler, editar, marcar como revisada, apagar.
Os dados de cada site são isolados e o admin exige ser o dono. A configuração pública vai nas variáveis do site; segredos não vão numa página, em plataforma nenhuma.
Os limites dependem do plano e o painel mostra quanto você está usando. O número aparece antes de você bater nele, não depois.
Suas páginas podem chamar qualquer API HTTP que você já tenha.
Descreva. O admin faz parte do site, então pode ser mudado como todo o resto.