なぜEmDashか
このページで分かること
- 編集者が管理画面で公開したエントリーが、Astroのページに表示されるまでの流れ
- EmDashが合うプロジェクトの条件と、ファイル管理のコレクション・独立したヘッドレスCMSとの比較
- 対応する実行環境（Cloudflare Workers、Node.js）、スキーマ変更の注意点、2種類のプラグイン形式、別の方法が合う場合
このページの目次
EmDashは、Astro向けに作られたコンテンツ管理システム（CMS）です。編集者が使う管理画面を、Webサイトと同じアプリケーションの中に追加します。Astroのページは、描画するときにデータベースからコンテンツを読み込みます。
このページでは、この設計を選んだ理由を説明します。自分のプロジェクトに合うかどうかの判断に使ってください。
コンテンツがサイトに表示されるまで
編集者が管理画面でエントリーを作成または更新します。EmDashは、そのエントリーを設定済みのデータベースに保存します。Astroがページを描画するとき、ページはEmDashの取得関数を呼び出し、公開済みのエントリーを受け取ります。
EmDashは、これらの取得処理をAstroのライブコンテンツコレクション（Live Content Collections）につなぎます。ライブコンテンツコレクションは、ビルド時だけでなく、必要になった時点でコンテンツを読み込む仕組みです。そのため、サーバーで描画するページ（サーバーレンダリング）では、公開した変更が次のリクエストから表示されます。事前に描画したページ（プリレンダリング）は、再ビルドするまで変わりません。
サイトのHTMLとデザインは、引き続きAstroのコンポーネントが決めます。EmDashが管理するのは構造化されたコンテンツで、画面上で見た目を組み立てるビジュアルページビルダーではありません。
やさしい解説
WordPressと同じく、記事は管理画面で書いてデータベースに保存します。違うのは、ページの見た目を作る部分が、PHPのテーマではなくAstroである点です。
Astroのページには2種類あります。
- サーバーで描画するページ：アクセスがあるたびにデータベースから最新の記事を読み込みます。管理画面で「公開」を押せば、次にページを開いたときに反映されます。
- 事前に描画したページ：ビルドした時点の内容で固定されます。記事を更新しても、もう一度ビルドするまで表示は変わりません。
EmDashの公式テンプレートは、すべてのページをサーバーで描画する設定になっています。そのため、WordPressと同じ感覚で「公開したらすぐ反映」になります。
対象となるプロジェクト
次の条件をすべて満たす場合、EmDashが適しています。
- WebサイトをAstroで作っている。
- 編集者が、リポジトリのファイルを編集せずにコンテンツを管理する必要がある。
- 開発者が、CMSとWebサイトを1つのアプリケーション・1回のデプロイにまとめたい。
- 開発者が、サイトとあわせてデータベースとメディアストレージを運用できる。
よくある例は、制作会社が作ってクライアントの編集担当者に引き渡すサイト、小規模な開発チームが保守するAstroのサイト、フロントエンドをAstroで作り直すWordPressからの移行です。
EmDashは、PHP、WordPressのテーマ、WordPressのプラグインを実行しません。WordPressのコンテンツはインポートでき、WordPressの概念やプラグインの動作がEmDashのどれにあたるかは移行ガイドで説明しています。ただし、サイトのデザインと独自のプラグインの動作は、AstroとEmDash向けに作り直す必要があります。
編集と開発
- 編集者は管理画面を使う：編集者は、コレクションとフィールドから自動生成されたフォームで作業します。権限に応じて、下書き、公開、メディア、タクソノミー、メニュー、ウィジェットエリアを管理できます。
- 開発者はAstroを使う：開発者は、コンテンツを表示するページ、レイアウト、コンポーネントを書きます。EmDashの取得関数は、エントリー、エラー、ページ分割の情報、キャッシュのヒントを返します。
- コンテンツモデルは変更できる：管理者は、管理画面でコレクションとフィールドを追加できます。開発者は、モデルをシードファイルとして書き出し、コレクション名とフィールドのTypeScriptの型宣言を生成できます。
生成した型宣言は、生成した時点のモデルを表します。ローカルでの開発中は、モデルが変わるとEmDashが emdash-env.d.ts を更新します。emdash types を使うそれ以外のワークフローでは、スキーマを変更したあとに出力を生成し直す必要があります。
Astroのほかのコンテンツソースとの比較
次の選択肢は、それぞれ異なる問題を解決します。ファイルで管理するコレクションは、コンテンツをリポジトリの中に置きます。独立したヘッドレスCMSは、専用の管理アプリケーションを動かし、ネットワーク経由のAPIでコンテンツを渡します。EmDashは、管理画面とコンテンツの実行環境をAstroのアプリケーションの中に置きます。
| 判断のポイント | EmDash | ファイルで管理するAstroのコレクション | 独立したヘッドレスCMS |
|---|---|---|---|
| 編集者が作業する場所 | Astroのアプリケーションが提供する管理画面 | リポジトリのファイルと開発ツール | CMSの提供元、または別に運用する管理アプリケーション |
| ページがコンテンツを読み込むタイミング | サーバーで描画するページがリクエストされたとき | 開発中、またはサイトのビルド時 | ビルド時またはリクエスト時に、ネットワーク経由のAPIで |
| モデルを定義する場所 | EmDashのデータベース（管理画面またはCLIで定義） | リポジトリのソースコード | CMSの設定 |
| チームが運用するもの | Astroのアプリケーション、データベース、メディアストレージ | Astroのアプリケーションとビルドパイプライン | Astroのアプリケーションに加えて、CMSのアカウントまたはサービス |
| リリースの分け方 | 管理画面とフロントエンドを一緒にデプロイする | 通常、コンテンツとフロントエンドを一緒にビルドする | CMSとフロントエンドを別々にデプロイする |
コンテンツをバージョン管理に置くべきで、寄稿者がGitのワークフローに慣れている場合は、ファイルで管理するコレクションを選びます。複数のアプリケーションが、独立してデプロイされる1つのコンテンツサービスを必要とする場合は、独立したヘッドレスCMSを選びます。編集者とAstroのサイトの両方にとって1つのアプリケーションであることが利点になり、チームがデプロイを共有することを受け入れられる場合は、EmDashを選びます。
やさしい解説
WordPressは、管理画面とサイトの表示が1つのシステムにまとまっています。この点ではEmDashも同じで、管理画面とサイトを1回のデプロイでまとめて更新します。一方、ファイルで管理するコレクションでは、記事をリポジトリのファイルとして書くため、編集者にもGitの操作が必要です。独立したヘッドレスCMSでは、管理画面が別のサービスになり、サイトとは別々にデプロイします。表の「編集者が作業する場所」と「チームが運用するもの」の行を見ると、違いが分かりやすくなります。
ホスティングとデータ
EmDashは、主に2つのデプロイ構成に対応しています。
- Cloudflare Workers：Cloudflare D1にコンテンツを保存し、R2にメディアを保存します。
- Node.js：SQLite、libSQL、PostgreSQLのいずれかにコンテンツを保存します。メディアは、ローカルのファイルシステムまたはS3互換のサービスに保存します。
データベースには、エントリーだけでなくコンテンツモデルも保存されます。管理者は、サイトの稼働中にそのモデルを変更できます。フィールドを追加しても既存のエントリーは保たれますが、編集者またはマイグレーションが値を入れるまで、既存のエントリーの新しいフィールドには値がありません。
やさしい解説
EmDashでは、どんな種類のコンテンツがあり、どんな項目を持つか（コンテンツモデル）が、記事と同じデータベースに保存されます。そのため、管理画面からサイトを止めずに変更できる一方で、フィールドやコレクションを削除すると、保存済みのデータもあわせて消えます。削除や型の変更をする前には、バックアップを取っておきます。
プラグイン
プラグインは、コンテンツやメディアの出来事に反応したり、設定、ルート、管理画面のページ、ダッシュボードのウィジェット、エディターの操作部品を追加したりできます。EmDashには、信頼の境界が異なる2つのプラグイン形式があります。
- ネイティブ型プラグインは、ホストのアプリケーションの一部として動き、アプリケーションと同じアクセス権を持ちます。
- 標準形式のプラグインは、サンドボックスランナーを設定し、必要な権限（Capability）を許可すると、隔離された実行環境で動かせます。
拡張機能を選んだり作ったりする前に、プラグイン形式を確認します。
ほかの方法を選ぶ理由
プロジェクトがAstroで作られていない場合、すべてのコンテンツをソースのリポジトリに置く必要がある場合、互いに関係のない複数のフロントエンドが独立してデプロイされるCMSを必要とする場合は、EmDashは合わない可能性が高いです。また、EmDashは運用の作業を増やします。データベース、メディアストレージ、バックアップ、アップグレード、管理画面を提供するアプリケーションは、チームが責任を持って運用します。
このモデルが合う場合は、ローカルで試すチュートリアルとしてはじめてのEmDashサイト作成を、既存のアプリケーションには既存のAstroプロジェクトにEmDashを追加するを読み進めます。