O que é CRUD? Criar, ler, atualizar e apagar explicados

CRUD significa criar, ler, atualizar e apagar — as quatro operações básicas que uma app faz com dados guardados. Acrescentar um novo cliente é criar, ver a lista de clientes é ler, alterar o número de telefone dele é atualizar e removê-lo é apagar. A maioria das apps de negócio — CRM, sistemas de marcações, controlo de inventário, painéis de administração — são em grande parte CRUD, com regras e uma boa interface por cima.

Porque é que importa quando cria com IA

CRUD é o vocabulário que transforma uma ideia vaga de app num pedido preciso. «Uma app para gerir os nossos fornecedores» deixa a IA a adivinhar. «Criar, listar, editar e apagar fornecedores, com estes campos» diz-lhe exatamente que ecrãs, operações de base de dados e rotas de servidor construir.

Também lhe dá uma lista de verificação para testar. Para cada tipo de registo da sua app, pode fazer quatro perguntas: consigo acrescentar um, vê-los, alterar um e removê-lo — e só as pessoas certas conseguem fazer cada uma destas coisas? Um número surpreendente de apps criadas com IA consegue criar registos mas não os editar, ou deixa qualquer pessoa apagar tudo.

Uma analogia do dia a dia: uma caixa de cartões de receitas

Imagine uma caixa de cartões de receitas numa prateleira da cozinha.

• Criar: escreve um cartão novo e arquiva-o.
• Ler: folheia a caixa, ou tira o cartão da lasanha.
• Atualizar: risca «200 g de queijo» e escreve «250 g».
• Apagar: tira um cartão e deita-o fora.

Agora acrescente regras: só o chefe de cozinha pode deitar cartões fora, cada cartão tem de ter um título, e ninguém pode arquivar dois cartões com o mesmo nome. Isso é uma app CRUD com validação e permissões — que é o que a maioria das apps reais são.

Como o CRUD aparece em cada camada

Cada operação aparece no ecrã, no servidor e na base de dados. Vê-las lado a lado explica muito sobre a forma como as apps são construídas.

O ecrã é o frontend, o pedido de API é a forma como o frontend fala com o backend, e o SQL é a forma como o backend fala com a base de dados. Se estes termos são novos, veja o que é uma API e o que é uma base de dados.

Um exemplo prático: um controlo de empréstimo de equipamento

O departamento de media de uma escola empresta câmaras e microfones a alunos e continua a perder o registo do material. Querem uma app simples.

Os registos. Dois tipos de coisas: equipamento (nome, tipo, número de série, estado) e empréstimos (que equipamento, que aluno, data de saída, data de devolução prevista, data de devolução efetiva).

CRUD para o equipamento:

• Criar: a equipa acrescenta uma nova câmara com o seu número de série. Regra: os números de série têm de ser únicos.
• Ler: uma lista de todo o equipamento, filtrável por tipo e por «disponível agora»; uma página de detalhe com o histórico de empréstimos de um item.
• Atualizar: alterar o estado para «precisa de reparação».
• Apagar: normalmente não é um apagamento real. Se uma câmara com 30 empréstimos passados for apagada, os registos de empréstimo perdem a ligação. Em vez disso, marca-se como «desativada» para que saia da lista de disponíveis, mas o histórico fica. Isto chama-se apagamento lógico (soft delete).

CRUD para os empréstimos:

• Criar: registar a saída de um item para um aluno. Regra: não se pode emprestar um item que já está emprestado.
• Ler: «empréstimos em atraso» — uma lista em que a data de devolução já passou e não há data de devolução registada.
• Atualizar: registar a data de devolução quando o item regressa.
• Apagar: apenas a equipa, para empréstimos introduzidos por engano.

Permissões. Os alunos só podem ler o que está disponível; só a equipa pode criar, atualizar ou apagar. Estas verificações correm no servidor, não apenas escondendo botões.

Isto é a app inteira. As partes interessantes — sem empréstimos duplos, uma lista de atrasos, um histórico por item — são regras e consultas por cima de CRUD simples.

Termos-chave

• Registo (linha): um item, como um fornecedor ou um empréstimo.
• Entidade / recurso: um tipo de registo, como «fornecedores». Cada um costuma ter a sua própria tabela e o seu próprio conjunto de ecrãs CRUD.
• Validação: verificações aos dados introduzidos — campos obrigatórios, email válido, quantidade positiva. Faça-a no formulário por conveniência e no servidor por segurança.
• Apagamento lógico (soft delete): marcar um registo como apagado ou arquivado, em vez de o remover, para que o histórico e as ligações se mantenham.
• Paginação: mostrar uma lista longa uma página de cada vez, para a app continuar rápida.
• Registo de auditoria (audit log): um registo de quem criou, alterou ou apagou o quê, e quando.
• Painel de administração: um conjunto de ecrãs CRUD para a equipa gerir os dados de uma app.

Erros e ideias erradas comuns

• Esquecer uma das quatro. As apps costumam sair com criar e ler mas sem editar, por isso cada erro de escrita obriga a apagar e reintroduzir. Verifique as quatro para cada entidade.
• Apagamentos que partem coisas. Apagar um cliente que tem faturas pode deixar faturas órfãs ou apagar o histórico. Decida por entidade: bloquear o apagamento, apagar logicamente, ou apagar também os registos relacionados.
• Permissões só na interface. Esconder o botão Apagar não impede que alguém envie o pedido DELETE. O servidor tem de verificar quem está a pedir.
• Atualizar por ID sem verificar a propriedade. Se o utilizador A consegue editar /api/notes/42 mudando um número no URL, pode editar a nota do utilizador B. Cada atualização e cada apagamento tem de confirmar que o registo pertence a quem pede.
• Sem confirmação ao apagar. Um toque errado não deve destruir dados. Peça um passo de confirmação, ou uma forma de anular.
• «CRUD é básico, por isso não vale a pena construir.» Muitos produtos de valor são apps CRUD que se adaptam a um fluxo de trabalho melhor do que uma ferramenta genérica.

O que pedir ao seu criador com IA

Use este padrão para cada entidade, uma de cada vez:

Cria uma funcionalidade de fornecedores com listar, criar, editar e apagar. Campos: nome (obrigatório), email de contacto (email válido), telefone, categoria (uma de: alimentação, embalagens, limpeza), notas. Vista de lista com pesquisa por nome e filtro por categoria, 20 por página. Pede confirmação antes de apagar; se o fornecedor tiver encomendas, arquiva em vez de apagar. Só a equipa autenticada pode criar, editar ou arquivar — garante isto no servidor.

Depois teste as quatro operações, como um utilizador autorizado e como alguém que não deveria ter acesso. Quando uma entidade funcionar, acrescente a seguinte. Como construir uma ferramenta interna mostra como os ecrãs CRUD se tornam uma app de administração completa, e o que é o Postgres explica a base de dados em que a maioria destas apps assenta.

Apps CRUD no Mythex

As apps CRUD são uma das coisas que os criadores de apps com IA fazem melhor, e o Mythex não é exceção. Peça no chat a entidade e os seus campos, e o Mythex associa uma base de dados Postgres ao projeto, cria a tabela e constrói os ecrãs de lista, formulário e detalhe numa pré-visualização ao vivo; depois pode executar /test para verificar o fluxo. A documentação tem uma receita para apps CRUD com um prompt inicial, e o criador de ferramentas internas e os modelos de painéis são bons pontos de partida.

Perguntas