しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

Azure Static Web Apps に Azure Functions 以外の API を持ち込み可能になったので一通り試した

Azure Functions Container Apps API Management Static Web Apps

個人的に GitHub で要望を挙げていた機能でもあるのですが、Static Web Apps の BYOF 機能が拡張されて Azure Functions 以外の API を持ち込めるようになりました。

Azure Functions はシンプルなプログラミングモデルを持っているので、簡単な REST API であればサクッと用意できるのでとても便利なのですが、大規模な API 群を実装するのには向いていないので、最低でも App Service を持ち込みたいユースケースは多かったです。

今回のアップデートで Azure Functions と App Service 以外にも Container Apps と API Management という、Azure におけるサーバーレスコンピューティングにキッチリ対応してきました。

特に Container Apps への対応はこれから利用頻度が高まりそうな気配があります。API Management はダウンタイム無しでのバックエンド切り替えが必要な際には入れておきたいです。*1

アップデートに伴い Azure Portal やドキュメントでの表記が Functions から API に変わっていますが、基本的な挙動は全く変わっていないので読みかえていきましょう。

Azure Portal での設定画面も大きく変わっていますが、前より分かりやすくなったと思います。

環境毎にリンク可能になっていて、選択すると以下のように API を選ぶ画面が表示されます。見て分かるように別サブスクリプションのリソースも選択できるようになっているので、かなり柔軟な設定が可能です。

画面が変わった結果として Function 一覧を確認する機能は無くなったようですが、この画面からバックエンドのリソースに簡単に移動できるのでそれで十分だと思います。

ここから先は実際に App Service / Container Apps / API Management を Static Web Apps のバックエンド API としてリンクした結果をまとめておきます。

Azure App Service

公式ドキュメントがリソース毎に用意されていますが、ぶっちゃけ App Service と Azure Functions は中身が同じなので挙動についても違いはありません。最初からリンク可能になって欲しかった理由の一つです。

Static Web Apps へのリンクを有効にすると App Service Authentication が自動的に有効化されて、以下のように特定の Static Web Apps のみ許可されるようになります。

App Service にブラウザからアクセスしてみると 400 が返ってきて、直接のアクセスがブロックされていることが確認出来ます。エラー画面は若干アレですが要件は満たしています。

ちなみに Static Web Apps が API として認識するのは /api 以下だけで、書き換え時にパス変換はしないので Web API 側も /api を prefix にする必要があります。

Static Web Apps の URL 経由で API にアクセスしてみると、こちらは問題なく通ります。URL から分かるように ASP.NET Core Web API のテンプレートをデプロイしたので、Azure Functions ではありません。

数多くの REST API を用意する場合には ASP.NET Core Web API の用に特化したフレームワークが最適なので、複雑な機能を持った SPA も今後は Static Web Apps で簡単にホスト出来るはずです。

おまけ程度ですが、リンクの詳細を確認すると Deployment Slot の情報がひっそりと含まれていました。将来的には Deployment Slot まで選べるようになるのかもしれません。

App Service のリンクについては予想通りというか、Azure Functions と同じなので期待した通りでした。

Azure Container Apps

Static Web Apps から見ると全く新しいリンク先となる Container Apps ですが、GA 前に Authentication が追加されたので挙動としてはほぼ同じだろうという期待があります。

Container Apps へのリンクを追加すると、App Service の時と同じように自動的に Authentication が有効化されて特定の Static Web Apps のみ許可される設定となりました。

ブラウザから Container Apps へ直接アクセスすると App Service とは異なる 400 画面が返ってきましたが、大した違いはありません。あまり余計な情報は出さないで欲しいですが。

Static Web Apps 経由でアクセスしてみると、もちろん API の呼び出しに成功しました。Easy Auth ベースの Authentication が組み込まれているので実に素直な挙動です。

現在はリビジョンを指定することは出来ないようですが、App Service の Deployment Slot が対応する際には、同じように特定リビジョンを指定できると便利そうな気がしました。

Azure API Management

これまでの App Service / Container Apps とは大きく異なるのが API Management です。理由としては Easy Auth が存在していないので、同じ実装には出来ないというのが大きいです。

確認用に適当に API を作成しておきます。注意点は API URL Suffix だけで、基本は api を指定しておけば良いです。API Management のバックエンドが /api から始まる場合は空にしておきます。

Static Web Apps から API Management へのリンクを追加すると、Easy Auth の設定が追加される代わりに Subscription と Product が自動的に作成されます。

以下のように自動生成された Subscription と Product は分かりやすい名前になるので判断が付きます。

App Service / Container Apps の場合とは異なり API Management の場合は、この Subscription キーを使って Static Web Apps からのアクセスのみ許可される仕組みになります。

リンク後に Static Web Apps 経由で API Management にアクセスしてみると以下のようにエラーとなります。

正直なところエラーメッセージに明確な原因が書いてあるので難しくはないのですが、API の設定から Static Web Apps が自動生成した Product を関連づけしないと API の実行が出来ません。以下のように Products に Static Web Apps が自動生成した Product を追加すると通るようになります。

Subscription キーのエラーだからと Subscription Required をオフにしては意味がないので注意しましょう。

設定後にもう一度 Static Web Apps 経由で API を実行してみると、今度は正常に通るようになります。

若干 API Management 周りの知識が必要とされますが、そこまで難しい手順なく Static Web Apps からリンクすることが出来ました。BFF や Microservices を SPA から使う場合には便利なはずです。

Azure のサーバーレスコンピューティングと簡単かつ柔軟に連携できる Static Web Apps は、エンタープライズ向けでも使えるようになったなと個人的に思っています。

*1:現状の Static Web Apps は Azure Portal からのリンク切り替え時にダウンタイムが発生する