Perryがコンパイルし、Coopが動かし続けます。
違いは言語ランタイムの置き場所です。Coopはアプリイメージを小さく保ち、互換性のあるPerryランタイムと標準ライブラリをホスト側で提供します。
Perry
通常のPerry実行ファイル
アプリ、ランタイム、ガベージコレクター、選択した標準ライブラリ機能を、対象ごとの1つの実行ファイルへリンクします。
app + runtime + stdlib → executable
Coop
Coopデプロイ
アプリのみの共有ライブラリとしてコンパイルします。互換プロバイダーはマシンごとに一度ビルドされ、アプリをマップする前にその同一性が検証されます。
apps → shared runtime + stdlib
障害境界で分離
マシン、各デプロイ、各リクエストの責任を分けます。アプリコードがマシンのデーモン内で動くことはありません。
01
01
デーモン · マシンごとに1つ
TLS終端、ホストとパスによるルーティング、デプロイ、成果物、管理API、メトリクスを担当します。
02
02
ワーカー · デプロイごとに1つ
アプリライブラリを読み込み、Perryランタイム状態を所有し、cronと永続キューを実行します。
03
03
呼び出し · リクエストごとに1つ
デプロイワーカー内のタスクとして動き、リクエストごとにプロセスを作らずアドレス空間を共有します。
現在動作するもの
Coopはテスト済みのインフラですが、完成したホスティング製品ではありません。現在の実装には次が含まれます。
- ✓TypeScriptコンパイル、HTTPルーティング、静的マウント
- ✓共有プロバイダーの同一性チェック
- ✓コンテンツアドレス方式のデプロイとロールバック
- ✓cronと永続キュー
- ✓専用ワーカー向けKVとオブジェクトストレージ
- ✓CLI、Prometheusメトリクス、アラート、Grafanaダッシュボード
小さなデプロイ構成
デプロイはcoop.tomlと1つ以上のハンドラーを含むディレクトリです。Coopがコンパイルして結果をキャッシュし、ローカルワーカーを起動します。
coop.toml
name = "hello"
version = "0.1.0"
[hosts]
domains = ["hello.test"]
[[handlers]]
file = "handlers/hello.ts"
path = "/hello"
method = "GET"handlers/hello.ts
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 ./hello意図的に狭い対象
現在適している用途
- ✓自分で所有するコードのサービスや小規模アプリ
- ✓1台のマシンでポートフォリオを運用する1人の管理者
- ✓PerryのTypeScriptサブセットでコンパイルできるワークロード
- ✓密度、明示的な成果物、高速ロールバックを重視するチーム
まだ約束していないこと
- ·任意のnpmやNode.jsとの互換性
- ·信頼できない第三者コード向けサンドボックス
- ·Kubernetesの代替やマルチリージョンプラットフォーム
- ·Node.jsに対する普遍的な性能優位