AppCore Runtime
AppCore não é uma aplicação. É a camada de runtime reutilizável que construí para que aplicações local-first não precisem reinventar ciclo de vida, manifests, storage, segurança, sync, supervisão, peer RPC e updates.
O problema
Aplicações local-first acumulam os mesmos problemas: descrever a aplicação sem fixar detalhes de deployment, rodar commands e queries de forma consistente, armazenar dados locais em formatos recuperáveis, sincronizar sem fingir ser um database multi-master e manter fronteiras de segurança visíveis.
AppCore existe porque essa infraestrutura não deveria ser reescrita dentro de cada aplicação de negócio.
O contrato
O contrato 1.0 reduz uma aplicação a três artefatos:
application.tomlcom identidade e requisitos portáveis.deployment.tomlcom providers, paths, rede e referências de secrets.- Código de negócio implementando
appcore_bin::application::Application.
O runtime assume as decisões de infraestrutura atrás desses artefatos. Mudar de um notebook offline para um cluster muda o deployment manifest, não a regra de negócio.
Arquitetura
External application
-> appcore-bin facade
-> API, core and managed runtime services
-> provider implementations
-> contracts and foundational types
A regra importante é controle de vocabulário. Crates do runtime não devem conter conceitos de produto, empresa, cliente ou domínio. Regras de negócio e integrações ficam fora do AppCore.
Módulos
| Área | Crates |
|---|---|
| Fundação | appcore-contracts, appcore-types, appcore-transport, appcore-dnt |
| Ciclo de vida | appcore-supervisor, appcore-core, appcore-bin |
| API | appcore-api |
| Segurança e storage | appcore-security, appcore-storage |
| Distribuição | appcore-distributed-contracts, appcore-control-plane, appcore-capabilities, appcore-peer-rpc, appcore-gateway |
| Operações | appcore-ops, appcore-scheduler, appcore-sync, appcore-update |
| Providers | appcore-provider, appcore-provider-vercel-neon |
make architecture.check valida dependências, vocabulário, tamanho de módulos e
mapa de módulos. A arquitetura vira gate, não só diagrama.
Decisões e trade-offs
AppCore não entrega RAFT, dados multi-master, OAuth, vault de produção embutido, database engine genérico, TLS inbound ou workflows de negócio. São fronteiras intencionais.
A linha RC aceita apenas manifests V1, protocolo 1, rotas HTTP /v1/* e
formatos persistentes V1. Inputs removidos são rejeitados em vez de convertidos
silenciosamente.
Segurança
O runtime protege contratos de infraestrutura. O deployment protege host, rede, TLS inbound, conta do sistema operacional e backend de secrets. A aplicação protege dados e autorização de negócio.
Na prática:
- manifests carregam referências de secrets;
- providers de filesystem validam paths e rejeitam traversal;
- DNT sealed storage protege arquivos contra inspeção offline e alteração sem chave;
- envelopes peer vinculam protocolo, tenant, cluster, origem, destino, expiry, nonce, trace e hash;
- updates são assinados por padrão em perfis de produção.
O que foi difícil
O difícil não foi criar crates chamados sync ou security. Foi impedir que o
runtime virasse framework de negócio. Cada capacidade útil tenta puxar vocabulário
de domínio para a fundação. A resposta do AppCore é layering, manifests,
providers e non-goals explícitos.
O aprendizado
AppCore mostra meu estilo de engenharia: congelar contratos antes de adicionar conveniência, documentar o que o sistema recusa fazer, transformar exemplos em fixtures executáveis e tratar release como evidência.
2026 © Daniel Netto. Todos os direitos reservados.