AppCore Runtime
AppCore n'est pas une application. C'est la couche runtime réutilisable que j'ai construite pour éviter de réinventer lifecycle, manifests, stockage, sécurité, sync, supervision, peer RPC et mises à jour dans chaque application local-first.
Le problème
Les applications local-first accumulent les mêmes sujets: décrire l'application sans figer le déploiement, exécuter commands et queries, stocker localement avec des formats récupérables, synchroniser prudemment et garder les frontières de sécurité visibles.
AppCore existe parce que cette infrastructure ne devrait pas être recodée dans chaque application métier.
Le contrat
Le contrat 1.0 réduit une application à trois artefacts:
application.tomlpour l'identité et les exigences portables.deployment.tomlpour providers, chemins, réseau et références de secrets.- Code métier implémentant
appcore_bin::application::Application.
Changer d'un notebook offline vers un cluster doit modifier le deployment manifest, pas la logique métier.
Architecture
External application
-> appcore-bin facade
-> API, core and managed runtime services
-> provider implementations
-> contracts and foundational types
La règle importante est le contrôle du vocabulaire. Les crates runtime ne doivent pas contenir de concepts produit, entreprise, client ou domaine.
Modules
| Zone | Crates |
|---|---|
| Fondation | appcore-contracts, appcore-types, appcore-transport, appcore-dnt |
| Cycle de vie | appcore-supervisor, appcore-core, appcore-bin |
| API | appcore-api |
| Sécurité et stockage | appcore-security, appcore-storage |
| Distribution | appcore-distributed-contracts, appcore-control-plane, appcore-capabilities, appcore-peer-rpc, appcore-gateway |
| Opérations | appcore-ops, appcore-scheduler, appcore-sync, appcore-update |
| Providers | appcore-provider, appcore-provider-vercel-neon |
make architecture.check valide dépendances, vocabulaire, taille de modules et
module map. L'architecture devient une gate, pas seulement un dessin.
Décisions et trade-offs
AppCore ne fournit pas RAFT, données multi-master, OAuth, vault de production embarqué, moteur de base de données générique, TLS inbound ou workflows métier. Ces limites sont intentionnelles.
La ligne RC accepte seulement les manifests V1, le protocole 1, les routes
HTTP /v1/* et les formats persistants V1. Les entrées retirées sont rejetées.
Sécurité
Le runtime protège les contrats d'infrastructure. Le déploiement protège l'hôte, le réseau, le TLS inbound, le compte système et le backend de secrets. L'application protège les données et autorisations métier.
En pratique:
- les manifests contiennent des références de secrets;
- les providers filesystem valident les chemins;
- DNT sealed storage protège contre inspection offline et altération sans clé;
- les enveloppes peer lient protocole, tenant, cluster, origine, cible, expiry, nonce, trace et hash;
- les updates sont signés par défaut en production.
Ce qui était difficile
Le plus dur n'était pas de créer des crates sync ou security, mais d'empêcher
le runtime de devenir un framework métier. Chaque capacité utile risque de tirer
du vocabulaire domaine dans la fondation. AppCore répond par layering, manifests,
providers et non-goals explicites.
Ce que cela montre
AppCore montre mon style d'ingénierie: figer les contrats avant la commodité, documenter ce que le système refuse, transformer les exemples en fixtures exécutables et traiter une release comme une preuve.
2026 © Daniel Netto. Todos os direitos reservados.