Azure Static Web Apps 活用プラクティス (2021年末版)
2021 年の Azure Static Web Apps(以下 SWA) は、ついに 5 月に GA するなど嬉しいアップデートがたくさんありました。逆にいうといろいろ選択肢も増えたため、どの機能をどこで活用すべきか悩む場面も多くなってきたのではないでしょうか。そこで、一旦このタイミング（2021 年末）で、SWA の活用プラクティスをテーマ別に QA 形式でまとめてみました。
Static Web Apps の用途は？
Azure でフロントエンドの Web アプリケーション（特に SPA のような静的アプリ）をホストするなら、まず Static Web Apps を第一候補として選択して良いと思います。
よく Blob Storage の Static Web Hosting と比較されますが、機能的にはほとんど SWA でもカバーできるのとコスト的にも Blob が有利になることはないのであえて Blob にする理由はレアケースかと思います。
App Service については、SWA が単体では対応していないアプリケーション構成（SSR で SWA の 統合 API に対応していない実装方式など）以外は選択しない方が良いと思います。ただし、SWA のステージング機能が GitHub にしか対応していないので、Azure Pipeline を利用していて Blue/Green デプロイメントをやりたい場合は App Service を選択せざるを得ません。ちなみに App Service で SPA をホストする場合は Windows を選択しないと静的ファイルをうまく扱えないので気を付けてください。
有料プランは必要？
SWA には Free プランがあるので、シンプルな Web サイトであれば、まず Free プランから検討して良いと思います。
一般的な Web サイトにとっては実は Free プランの制約はそれほどきつくないと思っています。自分が Standard プランを必要とするケースは、BYOF(Bring your own functions) を使った API 統合をする場合とカスタム認証を使いたい場合がほとんどです。
開発環境は何を使えば良い？
SWA はローカル開発からデプロイまで VS Code で完結させることができます。しかも、VS Code 拡張機能 を使えば Azure ポータルにアクセスする必要さえありません。Azure のポータルが苦手な方にはおすすめです。
さらに個人的に推したい開発環境は GitHub Codespaces です。Codespaces を使うと、作りたいアプリに特化した環境をあらかじめ定義して保存しておけるので、チームで開発環境を統一したい場合などには断然便利です。例えば、Node.js をバージョンを揃えてあらかじめ入れておき、ESlint や SWA CLI などの開発ツールを最初からセットされた状態で開発環境を起動することができます。Codespaces のメリットについては _@dz さん の記事がわかりやすいです。
ビルドワークフローは完全お任せで良い？
SWA ではリポジトリに GitHub を選択した場合、プロビジョニング時に自動で GitHub Actions の CI/CD ワークフローが生成されます。これはこれで便利なのですが、そこそこ本格的なアプリを運用するには少し不便なタスク構成になっています。例えば以下のような処理を入れることができません。
- 特定の NPM/Yarn のバージョンでビルドする
- NPM パッケージをキャッシュする
- ESLint などの Linter による静的チェックを入れる
- テストに失敗した場合はデプロイをしないように制御する
このような処理に対応させるには、ビルドワークフローの SWA 用タスクである Azure/static-web-apps-deploy@v1 内で skip_app_build を true に設定してビルドとデプロイのステップを分割しましょう。そうすれば、ビルド周りは自由にコントロールできるようになり、好みのタスクを実行してからデプロイさせることができます。
API の統合方式はどっちが良い？
SWA には Managed Function とよばれる方式の API 統合機能があります。フロントエンドと一緒に開発してデプロイされるのでいろいろ便利なように感じますが、本格的な API として利用しようとするといくつか落とし穴があります。
- コールドスタートが避けられない（Consumption Plan のため）
- ランタイムが限定され更新も遅い（現時点で Node.js は 12 系のみ）
そこで、BYOF(Bring your own functions) を使うようにします。BYOF は通常の Azure Functions として作って SWA と紐づける機能なので、フルに Azure Functions の機能を使いつつ SWA と同一ホストで運用できる仕組みです。
BYOF は通常の Azure Functions なので、Premium プランや App Service プランを選択することでコールドスタートを避けることができ、ランタイムもメジャーなものはだいたい選べます（Node.js は現在 16.x もサポート）。
個人的に気に入っているのは BYOF として紐づけた Azure Functions は SWA のフロントエンドからのトラフィックのみを受け付けるようにネットワークが制限される点です。これのおかげで認証の仕組みを SWA のみに入れるだけで良くなるケースが多くなります。
統合認証機能は本格的なアプリでも使えるの？
全く問題なく使えますし、むしろ統合認証を使うことから検討すべきです。
この統合認証機能は App Service でもおなじみの Easy Auth によって実現しているので技術的には十分洗練されており、コードに手を入れることなく認証機能を組み込めるのが最大のメリットです。
会員用のアプリケーションなどに Google や Facebook の認証を組み込むのは、設定ファイル（staticwebapp.config.json）に少し手を入れるだけで完了します。カスタム認証機能を使えば、OIDC に対応したプロバイダーに対応させたサイトも簡単に構築できます。Azure AD B2C を経由させることで LINE 認証も組み込むことができます。
個人的には独自認証を作りこんだり、認証対応のコードを独自にガリガリ書いたりする時代は終わったのかなと思ってます。
その他のプラクティス
- ローカル開発環境には SWA CLI をインストールしておきましょう
staticwebapp.config.jsonには フォールバックルート の設定を入れておきましょう- アクセス元を制限したい場合は手前に Front Door を配置 しましょう。IP 制限も可能です
2022 年の Azure Static Web Apps の進化にも期待したいですね！