Cloudflareのドキュメントは、コンセプトを学習したり、APIの使用上の注意を確認したりする場合や、APIやコンセプトを説明するための簡潔なスニペットが必要な場合に役立つ資料です。しかし、その資料が網羅的であるとしても、Cloudflare Workersプラットフォームの新規ユーザーは、導入例に掲載されているスニペットと実際の本番環境に対応したアプリケーションの移行の間の、大きなギャップを埋める必要があります。この一部は（他のプラットフォームと同様に）Wokersに固有である可能性がありますが、世界中の開発者は、サーバーレスの世界でアプリケーションを構築する方法を考えています。大規模なサーバーレスアプリケーションの構築には、開発者の経験レベルに関係なく、学習曲線の行程が必要です。
Cloudflareでも、同じ変遷をたどらなければならなかったため、そのことは十分に承知しています。当社には世界クラスのエンジニアが在籍しており、分散パラダイムを補完する製品を巧みに設計および製造をしています…しかし、専門家は一夜にして生まれるわけではありません。当社にはその経験があり、より速いスタートと理解の助けになれることを望んでいます。
これを念頭に置いて、業界特有の何かを行うことにし、Cloudflareスタック上に完全に構築されるフィーチャーコンプリートSaaSアプリケーションの例を作成しています。これは完全に無料で、GitHubでオープンソース化され、公に開発されています。独自のSaaSアプリケーションを起動するためのテンプレートとしても使用できるので、これは素晴らしい時間になります。実際、GitHubリポジトリのクローンを作成し、いくつかのサービストークンを更新し、ビルド済みのアプリケーションを数分以内に独自のCloudflareアカウントにデプロイできます。
もちろん、例とテンプレートは素晴らしいですが、テクノロジーとベストプラクティスは決して進化を止めません。 Cloudflareも例外ではなく、常に新しい製品や製品機能を繰り返し導入しています。さらに、これにはSaaSアプリケーションがWorkersプラットフォームとともに進化する生きた手本である必要があります — これは私たちの取り組みの一環です。
||お見逃しなく！GitHubのプロジェクトに注意して、開発の進捗状況を追跡し、最新の変更と推奨事項を常に把握してください。
アプリケーションの概要
ここで、実際にアプリケーションを構築することとは別に、ケーススタディの役割として納得できる、十分な複雑さと十分なシンプルさ（あるいは自己完結型の）の両方を持ったSaaSアプリケーションの例をバランスよく選択する必要がありました。これにより開発者はすぐにソースを辿り、関連するコンポーネントと、それらが使用される理由および/または方法を理解することができます。
最終的に、当社はアプリケーションの原型として長年にわたって変化してきたコンテンツ管理システム（CMS）のサンプルを作成することに決めました。従来、CMSはハードウェアを借りて運用し、長寿命のサーバーが受信するリクエストを処理し、SQLのようなデータベースを照会してリクエストされたコンテンツを取得し、HTMLページにレンダリングし、それを何度も繰り返してきました。WordPressは、このアプローチの非常に一般的な例であり、現在も変わりありません。
当然、このアプリケーションアーキテクチャは何年にもわたって改善されてきました。キャッシングのレイヤーが導入され、処理される行数を最小限に抑えるようにデータベーススキーマが再設計され、一部のフレームワークはデータベースを完全にスキップし始め、すべてのコンテンツを静的HTMLページとして事前にレンダリングするビルドステップを好むようになりました。（これは現在「静的サイトジネレーション」として知られており、今でも非常に人気のあるアプローチです。）
サーバーレスの時代の現在では、多くの「ヘッドレスCMS」の選択肢が数多く用意されています。これらは、リクエストごとにHTMLをレンダリングするモノリシックWebサーバーではないため、「ヘッドレス」になっています。代わりに、コンテンツを生のJSONデータとして返すAPIエンドポイントを提供します。これにより、Web開発者は、好みのツールやフレームワークを使用して、Webサイト用の完全にカスタム化されたテンプレートを作成できます。このアプローチは、コンテンツや画像アセットなどを整理する機能を損なうことなく、開発者に非常に大きな柔軟性を与えます。経験豊かな老舗ともいえるWordPressは、ヘッドレスモードと「ヘッドフル」モードを提供できる数少ないものの1つです。Sanity.ioとContentfulなどの他のヘッドレスの選択肢も非常に人気があります。
CMSアプリケーションモデルは、オープンソースの例の優れたケーススタディです。エッジファーストデザインの主要理念の1つは、コンテンツを要求するユーザーに物理的に可能な限り近い場所で提供することです。また、サーバーレスアーキテクチャは、もはや単一障害点が存在しない、あるいは存在すべきではないことを意味します。これらは両方ともCMSの原型に直接利益をもたらし、実装すると明確なパフォーマンスの向上が期待できます。
現在の進捗
ロードマップへと突入してこのプロジェクトがどのように進行するかを説明する前に、このプロジェクトはすでに継続的な取り組みであり、今後も継続していくことをお伝えすることが重要です。現在、GitHubでプロジェクトを検索して、完了済みの作業をお調べいただくことができます。今のところ、このアプリケーションは、Workers、Workers KV、Cloudflare for SaaSをすでに組み合わせており、PagesとDurable Objectsによるレート制限機能は、今後のマイルストーンで追加される予定です。
フェーズ1（以下を参照）は完了に近づいており、これが完了すると、非常に重要なマイルストーンの終わりを告げることになります。これまでのプロジェクトのハイライトと技術概要を網羅した本ブログ投稿シリーズの新しいアップデートが発行されます。フェーズ1は、それ自体でフルスタックアプリケーションを正常に動かすことができるため、重要であり、すぐに役立ちます。
開発のマイルストーン
CMSアプリケーションはマイルストーン形式で進行します。当社はすでにプロジェクトをリリースしており、ロードマップ（下記）に従ってプロジェクトを構築し続けます。GitHubの熱心な読者は、進捗状況を把握するか、少なくとも、フォローしたいマイルストーンの更新分のみを購読することができます。
各マイルストーンは、それ自体がかなり大きなチェックポイントです。以下に示すように、プロジェクトのロードマップは、各フェーズでかなりの数の新機能が追加されたり、新しいCloudflare製品と統合されたりするように計画されています。すべてのポイントで、アプリケーションは機能を維持します。また、実演形式のインタラクティブデモを継続して、立ち寄っていただいた方に最新の機能をすぐに実演します。
この形式が選択されたのは、実際のアプリケーション（および実際の製品）が開発される方法だからです。当社の目標は、GitHubリポジトリが決して時代遅れにならないようにすることです。また、開発構造により、過去のマイルストーンのリストを常に検討し、Xの移行に必要だった変更や、製品Yがどのように統合されたかを確認することができます。
||注：GitHubマイルストーンにアクセスして、詳細を表示し、更新をサブスクライブしてください。ここにリストされるより多くのものがあります。
フェーズ1 – JSON API
プロジェクトは、データの管理と操作を開始するために、いくつかのAPIエンドポイントから開始する必要があります。このマイルストーン内の作業では、WorkersとWorkers KVを使用して残りのアプリケーションが必要とするコア機能を処理する堅牢なJSON APIの構築に焦点を当てます。
このフェーズには、HTML、CSS、またはクライアント側のJavaScriptは含まれていません。代わりに、ここでの作業は、データへのアクセス方法、モデルの相互関係、およびこれらの関係をWorkers KV内で構造化および保存するための最適な方法にのみ焦点を当てる必要があります。たとえば、個人は、個人のユーザーアカウントまたは所属する組織に属するワークスペースを作成および管理できる必要があります。
さらに、コンテンツを作成するときは、ドキュメントが割り当てられた既存のスキーマに対してドキュメントを検証する必要があります。この機能は、ワークスペース内で数千のドキュメントを処理することを計画しているCMSプラットフォームで重要です。これがないと、コンテンツのJSON表現が一貫して構造化されているという確信はほぼ持てません。
他にも多くの機能（Stripeを介したサブスクリプション管理と請求、SendGridを介したトランザクションメールの送信、Cloudflare for SaaSを介したワークスペースへのバニティードメインの割り当て）が計画されています。最後に、もちろん、標準的なハウスキーピングタスクが設定されます。これには、APIテストとの継続的統合（CI）および自動化された継続的展開（CD）が含まれます。
このフェーズの終了時には、プロジェクトは、それ自体が完全なアプリケーションであるAPIエンドポイントの集合として存在することになります。curlコマンド（またはHTTPリクエストを手動で作成するためのその他の推奨される方法）でのみアクセスできますが、フェーズ1を完了すると、プロジェクトはすでにフルスタックアプリケーションとして認定され、実際のSaaS製品にサービスを提供することが可能になります。
さらに、リポジトリには、長期的な成長と保守のためにテストの作成、デプロイの自動化、およびソースの整理を行うためのすべてのベストプラクティスが含まれます。また、JSON APIから始めたため、プロジェクトは既存のビルドツールやフレームワークと統合できすぐに役立ちます。言い換えれば、熱心な読者であればプロジェクトをパーソナライズされたヘッドレスCMSとして自分のアカウントにデプロイできます。もしかしたら、GatsbyまたはEleventyプラグインを作成する人もいるかもしれませんが、その場合は、お知らせください。
フェーズ2 —ダッシュボードUI
curlと同じくらい楽しいかもしれませんが、多くのユーザーは、何らかの形で対話できる視覚的なインターフェイスを好みます。このフェーズでは、CMSアプリケーションのダッシュボードとして機能するフロントエンドを組み立てます。
当社ではユーザーインターフェースを構築するためのJavaScriptフレームワークであるSvelteを使用します。すべての人がこの決定に満足し同意しているわけではありませんが、テンプレート構文は標準のHTMLマークアップに似ており、フロントエンドの開発者でない人でも何が起こっているかを追跡して測定できます。
Svelteは、設計システム用のTailwind CSSと組み合わされます。Tailwindは、非常に人気のあるユーティリティファーストのCSSフレームワークであり、開発者は事前定義された再利用可能なHTML「クラス」名を使用してスタイルを作成できます。
結果はシングルページアプリケーション（SPA）になり、Cloudflare Pagesでホストされます。これはつまり、ダッシュボードは、Accessで保護されたプレビュー展開、インスタントロールバック、自動展開、包括的な分析などが、すぐに利用できるということです。
最後に、PagesがWorkersと直接統合したため、フェーズ1のJSON APIは新しいリポジトリ構造に移行されます。これは純粋なリファクタリングのように見えるかもしれませんが、実際にはJSON APIの驚くべき機能セット（アクセス防止のプレビューデプロイメント、インスタントロールバック、自動デプロイメント）を解き放つものです。そうです、これらは上記のPages機能と同じです。これは、当社のAPIが継続的かつアトミックにバージョン管理されており、APIに依存するクライアントダッシュボードと一緒に安全に開発を継続できることを意味しているため、驚くべきことです。言い換えれば、APIとダッシュボードが分岐して互いの期待がずれてしまうようなリスクはゼロということです。アプリケーション全体が単一のPagesユニットとして動作するため、インスタントロールバックもAPIに適用されます。
前のフェーズではSaaS製品機能のコアを構築することができますが、このフェーズを完了すると、日常的に起動して使用できる実際の製品のように感じることができます。実のところ、フェーズ2が終了したことで、このアプリケーションはヘッドレスCMSサービス分野の有力な候補に位置付けられます。
フェーズ3 — 記事のエッジレンダリング
前のフェーズは、最小限の実行可能なヘッドレスCMS製品の組み立てに焦点を当てていますが、フェーズ3は、この既成概念にとらわれずに成長することを目指します。これは、JSONコンテンツを事前定義されたテンプレートに挿入することでアプリケーションがHTML Webページをレンダリングできるようにすることで実現します。
WordPressと同様に、CMSアプリケーションでは、ユーザーが「ヘッドレス」機能を引き続き使用するか、完全なテンプレートエンジンを使用するかを選択できるようにする必要があります。HTML出力を選択した場合、Cloudflareプロジェクトには、ユーザーが選択できるいくつかの既成のテンプレートのみが含まれますが、もちろん、これは独自のプロジェクトでカスタマイズできます。
このフェーズではモノリシックCMSの原型が再導入されますが、これは、以前の単一のオールインワンサーバーよりもはるかに安全かつ高速で、復元力のあるアーキテクチャです。CMSコンテンツは引き続き世界中に配布され、お客様の読者の近くにありますが、コンテンツは世界中のどこからでも非常に低い遅延でレンダリングできるようになりました。
フェーズ4 — 機能のアップグレード
この段階で、アプリケーションは（ほとんどの部分が）完成しています。機能的で見栄えがよく、グローバルに機能する、2つのまったく異なる方法で使用できます。
実際のSaaS製品に関しては、開発はユーザーが喜ぶ新機能の追加またはプロジェクトの健全性の維持にシフトし始めます。たとえば、フェーズ4では、Durable Objectsを利用して、複数のユーザーがリアルタイムのコラボレーション環境で同じドキュメントを編集できるドキュメントエディタを導入します。
また、Cloudflare R2ストレージがメディアアセットのバックエンドとして導入され、ユーザーがワークスペース内で画像をアップロードおよび管理できるようになる可能性が非常に高くなります。恐らく当社ではこれにCloudflare Imagesを使用することにして、コンテンツバックアップのインポートとエクスポートにR2を使用します。
ご想像のとおり、このマイルストーンは未知のもので溢れていますが、それは未来が無限の可能性を秘めているためです。プロジェクトは、Cloudflareと時間とともに進化し、拡大し続けます。
もちろん、機能に関するアイデアや提案がある場合は、GitHubでディスカッションを開始してください。ご連絡をお待ちしております。
次のステップ
本記事は、進行中のシリーズ（今後の予定）の紹介記事でした。各マイルストーンが完了した際には、過去の情報やその章の作業の重要な側面の技術的なウォークスルーを交えてこのシリーズの新しい投稿を公開していきます。
さあエキサイティングな旅の始まりです。あなたが興味を持ってくれることを願っています！
GitHubでプロジェクトにスターを付けるかフォローすることで、サポートを表明することができます。すべてのリリース、ディスカッション、およびマイルストーントラッキングは、リポジトリ内に存在します。次世代のSaaSアプリケーションはCloudflare上に構築されます—サブスクライブしてさっそく始めましょう！