Ein Ort, an dem Perry-Code ruhen und laufen kann.
Coop verwandelt ein Verzeichnis mit Perry-kompatiblem TypeScript in eine native Anwendungsbibliothek und stellt sie über HTTP bereit. Perry-Laufzeit und Standardbibliothek werden dabei nur einmal pro Maschine bereitgestellt.
Experimentelle Infrastruktur für eigenen Code
Perry kompiliert. Coop hält es am Laufen.
Der Unterschied liegt darin, wo die Sprachlaufzeit lebt. Coop hält das Anwendungsabbild klein und stellt die kompatible Perry-Laufzeit samt Standardbibliothek auf Host-Ebene bereit.
Ein reguläres Perry-Programm
Anwendung, Laufzeit, Garbage Collector und ausgewählte Funktionen der Standardbibliothek werden in eine zielspezifische ausführbare Datei gelinkt.
Ein Coop-Deployment
Die Anwendung wird als reine App-Bibliothek kompiliert. Kompatible Laufzeitbibliotheken werden einmal pro Maschine gebaut und ihre Identität vor dem Einbinden der App geprüft.
Nach Fehlergrenzen getrennt
Maschine, Deployment und Anfrage haben getrennte Verantwortlichkeiten. Anwendungscode läuft niemals im Box-Daemon.
Daemon · einer pro Maschine
Beendet TLS, routet nach Host und Pfad und verwaltet Deployments, Artefakte, Admin-API und Metriken.
Worker · einer pro Deployment
Lädt die Anwendungsbibliothek, besitzt den Perry-Laufzeitzustand und führt Cron- sowie dauerhafte Queue-Aufgaben aus.
Aufruf · einer pro Anfrage
Läuft als Task im Deployment-Worker und teilt dessen Adressraum, ohne pro Anfrage einen Prozess zu starten.
Was heute funktioniert
Coop ist getestete Infrastruktur, aber noch kein fertiges Hosting-Produkt. Die aktuelle Implementierung umfasst:
- ✓TypeScript-Kompilierung, HTTP-Routing und statische Mounts
- ✓Identitätsprüfungen für gemeinsame Provider
- ✓Inhaltsadressierte Deployments und Rollback
- ✓Cron und eine dauerhafte Queue
- ✓KV- und Objektspeicher für dedizierte Worker
- ✓CLI, Prometheus-Metriken, Alarme und Grafana-Dashboard
Eine kleine Deployment-Oberfläche
Ein Deployment ist ein Verzeichnis mit einer coop.toml-Datei und einem oder mehreren Handlern. Coop kompiliert es, speichert das Ergebnis im Cache und startet einen lokalen Worker.
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 ./helloBewusst eng gefasst
Heute gut geeignet für
- ✓Dienste und kleine Anwendungen mit eigenem Code
- ✓Einen Betreiber mit einem Portfolio auf einer Maschine
- ✓Workloads innerhalb von Perrys TypeScript-Teilmenge
- ✓Teams, die Dichte, explizite Artefakte und schnelle Rollbacks schätzen
Was Coop noch nicht verspricht
- ·Beliebige npm- oder Node.js-Kompatibilität
- ·Eine Sandbox für nicht vertrauenswürdigen Drittcode
- ·Kubernetes-Ersatz oder Multi-Region-Plattform
- ·Universelle Performance-Vorteile gegenüber Node.js
Dichte ist die These. Benchmarks bleiben die Arbeit.
Aktuelle Messungen zeigen je nach Workload in unterschiedliche Richtungen. Kleine Linux-Anwendungen zeigen vielversprechende Dichte, während eine vollständige Next.js-Route in einem anderen Test mehr CPU als Node.js benötigte. Vor dem Zitieren bitte die Methodik lesen.
Mit Perry bauen. In Coop laufen lassen.
Quellcode erkunden, das Beispiel-Deployment starten und helfen, das Shared-Runtime-Modell zu verlässlicher Infrastruktur zu machen.