前回、Azure Static Web AppsがGAになった記事を書きましたが、既存のAzure Functionsをリンクさせることができませんでした。
Standardプランに変更することにより、BYOF(Bring your own functions)、つまり、既存のAzure FunctionsをAzure Static Web Appsにリンクさせることが出来たのでその手順を追っていきたいと思います。
Azure Static Web AppsへのAzure Functionsリンク手順
まず、前提として、Azure Static Web AppsとAzure Functionsがソースコード、Azure上リソースとも存在するテイで話を進めます。
Azure Functionsは、HttpトリガーなFunctionsを新規作成したひな形コードをそのまま使って前回の記事で書いたAzure Static Web Appsにリンクしてみます。
Azure Static Web Appsについては以下の記事にて。
Azure Static Web Appsのプラン変更
BYOFを行うにはStandardプランが必要です。FreeプランではBYOFは利用できず、SWA内で管理するAzure Functionsのみ利用可能という制限があります。
前回はFreeプランでSWAリソースを作成したためStandardプランに変更します。
まずはAzureポータルから、SWAリソースを開き、「ホスティング プラン」を選択します。
以下の画面になるので、「Standard」を選択して、「保存」をクリックします。これでStandardプランに変更されました。前回投稿時、まだにわかGAだったのか、リージョンの時差なのか不明ですが、Standardプランの選択が出来ませんでしたが、今回はばっちり変更できました。
Azure FunctionsをStatic Web Appsにリンク
次にSWAにFunctionsをリンクします。すでにAzure Functionsリソースが存在している必要があります(省略)。左側の「関数」を選択し、「関数アプリへのリンク」をクリックします。
以下の画面で、リンクさせるAzure Functionsのサブスクリプション、関数アプリ名を選択し、「リンク」をクリックします。たったこれだけです。
Azure Functionsソースコードのデプロイ
Azure Functionsリソースに対して、デプロイを行います。この手順はパイプラインが構築されていたり、すでにAzure Functionsへのデプロイが行われている場合は不要です。今回は1回ぽっきりですので、パイプライン構築するまでもないのでVisual Studioから手動でデプロイしてみました。
Azure Functionsソリューションを開いて、「ビルド」メニューから「(Azure Functionsアプリ名)の発行」を選択します。
公開場所に「Azure」を選択し「次へ」。
今回はAzure上に.NET CoreのAzure Functionsリソースが準備済みですので、「Azure Function App(Windows)」を選択します。「次へ」をクリックします。
デプロイ先のアカウント名、サブスクリプション名、リソースグループなどを正しく選択すると、関数アプリ欄にデプロイ可能なAzure Functionsリソースが表示されますので、選択して「完了」をクリックしましょう。
デプロイの準備が完了しました。右上の「発行」をクリックすることでAzure Functionsのデプロイが実行されます。
Azure FunctionsのCORS設定
BYOFでのAzure Functionsの場合は、CORS(Cross-Origin Resource Sharing)の設定を行い、SWAのJavaScriptからAzure Functionsへのアクセスを許可してあげる必要があります。
AzureポータルからAzure Functionsリソースを開き、左のメニューから「CORS」を選択します。
CORSの設定画面が表示されるので、Static Web AppsのURLを「許可される元のドメイン」にコピペし、「保存」をクリックします。
ソースコードの修正
次に、前回作成したSWAソースコードの修正を行います。ポイントは7行目なんですが、Azure Functions側のURLを指定しているのですが、通常だとAzure Functionsの素のURLである、「https://swabackend.azurewebsites.net/api/Function1」に対してリクエストを投げるべきところ、リンクされたAzure Functionsの場合はリンク先のStatic Web AppsのURLである「https://XXXXXXXXX.azurestaticapps.net/api/Azure Functionsの関数名」となる点にご注意を。
あとのコードはただAzure FunctionsバックエンドにHttpリクエストを投げているJavaScriptですのでよしなに。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>Swa Sample</title> <script> const Url = "https://XXXXXXXXX.azurestaticapps.net/api/Function1?name=Myfunction"; fetch(Url) .then((res)=>{ if (!res.ok) { throw new Error(`Fetch: ${res.status} ${res.statusText}`); } return( res.text() ); }) .then((text)=>{ console.log(text); document.getElementById("result").textContent = text; }) .catch((error)=>{ console.error(`[FetchAPI] ${error}, ${Url}`); }) </script> </head> <body> <div id="result"></div> </body> </html> |
また、前回のSWAでパイプラインを構築している場合はazure-pipelines.ymlの修正も必要です。
既存Azure Functionsとリンクさせる場合はこの18行目のapi_locationを空文字(””)に設定する必要があります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
# Starter pipeline # Start with a minimal pipeline that you can customize to build and deploy your code. # Add steps that build, run tests, deploy, and more: # https://aka.ms/yaml trigger: - main pool: vmImage: ubuntu-latest steps: - checkout: self submodules: true - task: AzureStaticWebApp@0 inputs: app_location: '/' api_location: '' output_location: '' env: azure_static_web_apps_api_token: $(deployment_token) |
公式にもしっかり書いてありますね。
修正が終わったらパイプラインを走らせてSWAにコードを反映させます。
Azure Static Web Appsを呼び出す
最後に、ブラウザーからAzure Static Web AppsのURLを叩いてみます。ちゃんとリンクされたバックエンド側Azure Functionsが呼び出されてレスポンスが返ってくることが確認できました。
さいごに
実際にAzure FunctionsのSWAへのリンク機能、使ってみましたがStandardプランにして利用するまでのメリットを感じられませんでした。(前回の投稿ではぜひ欲しいと感じましたがw)
既存Azure Functionsを活用させるというメリット以外でなにがあるか、どなたか教えてください。(なんかStandardプランのメリットと関数アプリのリンクに関してがごっちゃになってしまったが。。。)
(2021/11/13追記)
何となくの理解ですが、SWA+バックエンドAPIの構成で認証を実装するときに、同一オリジンとなることでCookieのやり取り(というか認証回り)にいろいろ助かるってことで落ち着いてます。StandardでもいいけどとりあえずはFreeでいいかな。
「Freeプランで十分使えるAzure Static Web Appsじゃん!」という結論にたどり着きました。
コメント