Un endroit où le code Perry peut se poser et s'exécuter.
Coop transforme un dossier TypeScript compatible avec Perry en bibliothèque d'application native et la sert en HTTP, tandis que le runtime et la bibliothèque standard de Perry ne sont fournis qu'une fois par machine.
Infrastructure expérimentale pour votre propre code
Perry compile. Coop maintient en ligne.
La différence tient à l'emplacement du runtime du langage. Coop garde l'image applicative légère et fournit le runtime Perry compatible et la bibliothèque standard au niveau de l'hôte.
Un exécutable Perry classique
L'application, le runtime, le ramasse-miettes et les fonctions choisies de la bibliothèque standard sont liés dans un exécutable propre à la cible.
Un déploiement Coop
L'application est compilée comme une bibliothèque partagée ne contenant que l'app. Les fournisseurs compatibles sont construits une fois par machine et leur identité est vérifiée avant son chargement.
Séparé par limite de défaillance
La machine, chaque déploiement et chaque requête ont des responsabilités distinctes. Le code applicatif ne s'exécute jamais dans le daemon de la machine.
Daemon · un par machine
Termine TLS, route par hôte et chemin, et gère les déploiements, artefacts, l'API d'administration et les métriques.
Worker · un par déploiement
Charge la bibliothèque applicative, possède l'état du runtime Perry et exécute les tâches cron et de file durable.
Invocation · une par requête
S'exécute comme tâche dans le worker et partage son espace d'adressage sans créer un processus par requête.
Ce qui fonctionne aujourd'hui
Coop est une infrastructure testée, mais pas encore un produit d'hébergement finalisé. L'implémentation actuelle comprend :
- ✓Compilation TypeScript, routage HTTP et montages statiques
- ✓Contrôles d'identité des fournisseurs partagés
- ✓Déploiements adressés par contenu et restauration
- ✓Cron et file durable
- ✓KV et stockage d'objets pour workers dédiés
- ✓CLI, métriques Prometheus, alertes et tableau de bord Grafana
Une surface de déploiement réduite
Un déploiement est un dossier contenant coop.toml et un ou plusieurs handlers. Coop le compile, met le résultat en cache et démarre un worker local.
name = "hello"
version = "0.1.0"
[hosts]
domains = ["hello.test"]
[[handlers]]
file = "handlers/hello.ts"
path = "/hello"
method = "GET"import { CoopRequest, respond } from "@coop/runtime";
export function handle(reqJson: string): string {
const req = new CoopRequest(reqJson);
return respond(200, {}, `hello from ${req.path}`);
}$ coop-cli dev ./helloVolontairement ciblé
Un bon choix aujourd'hui
- ✓Services et petites applications dont vous possédez le code
- ✓Un opérateur gérant un portefeuille sur une machine
- ✓Charges compilables dans le sous-ensemble TypeScript de Perry
- ✓Équipes privilégiant densité, artefacts explicites et restauration rapide
Ce que Coop ne promet pas encore
- ·Compatibilité arbitraire avec npm ou Node.js
- ·Sandbox pour du code tiers non fiable
- ·Remplacement de Kubernetes ou plateforme multirégion
- ·Gains de performances universels face à Node.js
La densité est la thèse. Les benchmarks restent le travail.
Les mesures actuelles divergent selon la charge. Coop a montré une densité prometteuse sur de petites applications Linux, tandis qu'une route Next.js complète a consommé plus de CPU que Node.js dans un autre test. Lisez la méthodologie avant de citer ces résultats.
Construisez avec Perry. Donnez-lui un Coop.
Explorez le code source, lancez le déploiement d'exemple et contribuez à rendre fiable le modèle de runtime partagé.