Share via

Erstellen einer statischen Web-App mit einer serverlosen API

  • Artikel

Erfahren Sie, wie Sie lokal eine statische Web-App mit einer serverlosen API in Azure bereitstellen. In diesem Lernprogramm wird die Vorschauversion des neuesten Programmiermodells für Azure Functions Node.js verwendet. Da in diesem Artikel eine Vorschauversion von Azure Functions verwendet wird, wird sie als separate App von der statischen Web-App bereitgestellt.

In diesem Artikel werden folgende Themen erläutert:

  • Lokales Ausführen einer statischen Web-App (SWA) mit einer Azure-Funktions-App
  • Lokale Proxy-Front-End-Anforderungen an die lokale Back-End-API mithilfe der SWA CLI.
  • Stellen Sie denselben Code bereit und führen Sie denselben Code remote aus.

Der Proxy zwischen front-end und Backend-Endis, die von der Static Web App CLI bereitgestellt werden, bietet:

  • Die URL in React gibt /api/todonicht die Server- oder Portnummer für die API an. Anforderungen, die diese URL verwenden, können problemlos lokal verwendet werden, da die SWA-Befehlszeilenschnittstelle den Proxy für Sie verwaltet.
  • Lokaler Authentifizierungsemulator beim Zugriff auf /.auth/login/<provider>
  • Routenverwaltung und Autorisierung

Authentifizierung in diesem Beispiel

Die Authentifizierung in diesem Beispiel wird für Front-End-Benutzer aus dem Azure Static Web-Apps-Dienst bereitgestellt:

  • Anmeldung/Abmeldung
  • Öffentliche und private Inhalte

Quellcode in diesem Beispiel

Der Quellcode in diesem Beispiel soll erfahren, wie Sie eine statische Web-App mit einer serverlosen API erstellen und bereitstellen. Der Code ist nicht für die Produktion vorgesehen.

Sie finden mehrere Stellen im Code, die nicht den bewährten Sicherheitspraktiken entsprechen. Beispielsweise wird console.log der Code verwendet, um in die Browserkonsole zu schreiben.

Wenn Sie zu einer Produktionsumgebung wechseln, sollten Sie code überprüfen und entfernen, der gegen bewährte Methoden für Die Sicherheit für Ihre Organisation verstößt.

1. Vorbereiten Ihrer Entwicklungsumgebung

Erstellen Sie die folgenden Konten:

Installieren Sie Folgendes auf Ihrem lokalen Entwicklungscomputer:

2. Verzweigung des Beispiel-Repositorys auf GitHub

Sie müssen über eine eigene Verzweigung des Beispiel-Repositorys verfügen, um die Bereitstellung von GitHub abzuschließen. Während des Verzweigungsprozesses müssen Sie nur die main Verzweigung kopieren.

Verzweigen Sie das Beispiel-Repository: https://github.com/Azure-Samples/azure-typescript-e2e-apps.

3. Klonen des verzweigten Beispiel-Repositorys

  1. Klonen Sie in einem Bash-Terminal Ihr Verzweigungsrepository auf Ihrem lokalen Computer. Klonen Sie das ursprüngliche Beispiel-Repository nicht. Eine Beispiel-URL ist https://github.com/YOUR-ACCOUNT-NAME/azure-typescript-e2e-apps

    git clone YOUR-FORKED-REPO-URL

  2. Installieren von Abhängigkeiten für die lokale Front-End-App:

    cd app-react-vite && npm install

  3. Installieren von Abhängigkeiten für die lokale Back-End-App:

    cd ../api-inmemory && npm install && cd ..

4. Optional, Erstellen und Ausführen einer lokalen App

Das Beispiel-Repository verfügt über mehrere Versionen der Front-End- und Back-End-Apps. Die folgenden Schritte verwenden die React 18 (Vite)-Version des Front-End und die Azure Function v4 mit Node.js-Version des Back-End mit den /status Routen und /todo API-Routen.

  1. Verwenden Sie aus dem Stamm der Beispiel-App die SWA CLI mit der ./swa-cli.config.json Datei, um die Front-End- und Back-End-Apps zu erstellen:

    swa build

    Wenn Fehler auftreten, die je nach Version der verschiedenen Pakete und Ihrer Umgebung auftreten können, beheben Sie die Fehler, bevor Sie fortfahren. Es ist wichtig zu wissen, dass Ihr Projekt erfolgreich lokal erstellt wird, bevor Sie zur Bereitstellung zu Azure Static Web-Apps wechseln.

  2. Verwenden Sie aus dem Stamm der Beispiel-App die SWA CLI, um die Apps mit einem Proxy zu starten.

    swa start

  3. Wenn die folgenden Zeilen im Bash-Terminal angezeigt werden, wurde das Projekt erfolgreich gestartet.

    [swa] Serving static content:
[swa]   /workspaces/azure-typescript-e2e-apps/app-react-vite/dist
[swa] 
[swa] Serving API:
[swa]   /workspaces/azure-typescript-e2e-apps/api-inmemory
[swa] 
[swa] Azure Static Web Apps emulator started at http://0.0.0.0:4280. Press CTRL+C to exit.

  4. Öffnen Sie einen Webbrowser für die proxygeschützte URL, http://localhost:4280. Die folgende Seite sollte angezeigt werden:

    Screenshot of local React app prior to authentication.

  5. Sie können sich mit der von der SWA CLI bereitgestellten Authentifizierung anmelden. Der Prozess simuliert die Authentifizierung in cloudbasierten Azure Static Web Apps. Der Front-End-Code verwendet den /.auth/me Endpunkt, um die Identität des Benutzers abzurufen. Geben Sie einen gefälschten Benutzernamen ein, und ändern Sie nicht die restlichen Felder.

    Screenshot of local React app's mock authentication form.

  6. Nachdem ein Benutzer authentifiziert wurde, zeigt das Front-End private Informationen wie die Umgebungsvariablen der API an.

    Screenshot of local React app with authentication complete.

    Der Quellcode der Azure Function v4-App für diese API lautet:

    import { app, HttpRequest, HttpResponseInit, InvocationContext } from "@azure/functions";

import { name, version } from '../../package.json';
function isObject(v) {
    return '[object Object]' === Object.prototype.toString.call(v);
};
function sortJson(o){
    if (Array.isArray(o)) {
        return o.sort().map(sortJson);
    } else if (isObject(o)) {
        return Object
            .keys(o)
        .sort()
            .reduce(function(a, k) {
                a[k] = sortJson(o[k]);

                return a;
            }, {});
    }
    return o;
}

export async function status(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {
    context.log(`Http function processed request for url "${request.url}"`);

    const sortedEnv = sortJson(process.env);

    return { jsonBody: {
        name,
        version,
        env: sortedEnv,
        requestHeaders: request.headers 
    }};
};

app.http('status', {
    route: "status",
    methods: ['GET'],
    authLevel: 'anonymous',
    handler: status
});

  7. Erweitern Sie die öffentlichen und privaten Abschnitte, um den Inhalt aus der API anzuzeigen.

5. Erstellen einer neuen Azure Functions-App

Der vorherige Abschnitt zum Ausführen der statischen Web-App mit der API war optional. Die Abschnitte zum Erneuten Standard des Artikels sind erforderlich, um die App und API in der Azure-Cloud bereitzustellen.

Um die Vorschauversion der Azure Functions v4-Laufzeit zu verwenden, müssen Sie eine neue Azure Functions-App erstellen. Ihre statische Web-App muss auch neu erstellt und erneut bereitgestellt werden, um den Azure Functions-App-URI in den Fetch-Anforderungen an die API zu verwenden, anstatt eine proxygesteuerte und verwaltete API zu verwenden.

  1. Öffnen Sie in einem Webbrowser die Azure-Portal, um eine neue Azure Functions-App zu erstellen: Erstellen einer neuen App

  2. Verwenden Sie die folgenden Informationen, um die Funktions-App zu erstellen::

    Tab:Setting Wert
    Grundlagen: Abonnement Wählen Sie das Abonnement aus, das Sie verwenden möchten.
    Grundlagen: Ressourcengruppe Erstellen Sie eine neue Ressourcengruppe, z first-static-web-app-with-api. B. . Der Name wird nicht in der öffentlichen URL der App verwendet. Ressourcengruppen helfen Ihnen beim Gruppieren und Verwalten verwandter Azure-Ressourcen.
    Grundlagen: Instanzdetails: Funktions-App-Name Geben Sie einen global eindeutigen Namen ein, z swa-api . B. mit drei zufälligen Zeichen, die am Ende hinzugefügt wurden, z swa-api-123. B. .
    Grundlagen: Instanzdetails: Code oder Container Wählen Sie Code aus.
    Grundlagen: Instanzdetails: Laufzeitstapel Wählen Sie Node.js aus.
    Grundlagen: Instanzdetails: Laufzeitstapel Wählen Sie 18LTS aus.
    Grundlagen: Betriebssystem Wählen Sie Linux aus.
    Grundlagen: Hosting Wählen Sie Consumption aus.
    Speicher: Speicherkonto Nehmen Sie hier keine Änderungen vor. Es wird ein neues Azure Storage-Konto erstellt, um Funktionsereignisse zu unterstützen.
    Netzwerk Ändern Sie nichts.
    Monitoring: Application Insights: Enable Application Insights Wählen Sie Yes aus. Ändern Sie nicht den angegebenen Standardnamen.
    Bereitstellung: GitHub-Aktionen Einstellungen: Kontinuierliche Bereitstellung Wählen Sie Enable aus.
    Bereitstellung: GitHub-Konto Wählen Sie Ihr GitHub-Konto aus.
    Bereitstellung: Organisation Wählen Sie Ihr GitHub-Konto aus, das Sie beim Verzweigen des Beispiel-Repositorys verwendet haben.
    Bereitstellung: Repository Wählen Sie ihren Verzweigungs-Repositorynamen aus. azure-typescript-e2e-apps
    Bereitstellung: Branch Wählen Sie main aus.
    Tags Ändern Sie nichts.
    Bewerten + erstellen Wählen Sie Create aus.

    Der Schritt fügt Ihrem Verzweigungs-Repository eine GitHub-Yaml-Workflowdatei hinzu.

  3. Wenn die Ressource erstellt wird, wählen Sie die Go to resource Schaltfläche aus.

  4. Wählen Sie Einstellungen –> Konfiguration und fügen Sie dann eine Konfigurationseinstellung für die Azure Function Node.js v4-Laufzeit mit Name AzureWebJobsFeatureFlags und Wert EnableWorkerIndexinghinzu.

  5. Klicken Sie auf Speichern, um die Einstellung zu speichern.

  6. Verwenden Sie git in einem Bash-Terminal, um die neue Yaml-Workflowdatei aus Ihrem GitHub-Repository auf Ihren lokalen Computer zu ziehen.

    git pull origin main

  7. Öffnen Sie in Visual Studio Code die neue Yaml-Workflowdatei unter ./.github/workflows/.

  8. Die für Sie bereitgestellte Standardworkflowdatei geht davon aus, dass sich der Funktionsquellcode im Stammverzeichnis des Repositorys befindet und die einzige App im Repository ist, dies ist jedoch nicht der Fall bei diesem Beispiel. Bearbeiten Sie die Datei, um dies zu beheben. Die zu bearbeitenden Zeilen werden im folgenden Yaml-Block hervorgehoben und unten erläutert:

    # Docs for the Azure Web Apps Deploy action: https://github.com/azure/functions-action
# More GitHub Actions for Azure: https://github.com/Azure/actions

# Deploy Azure Functions Node.js v4 runtime
# with api-inmemory subdir

name: Azure Function App - api-inmemory

on:
  push:
    branches:
      - main
    paths:
      - 'api-inmemory/**'
  workflow_dispatch:

env:
  AZURE_FUNCTIONAPP_PACKAGE_PATH: 'api-inmemory' # set this to the path to your web app project, defaults to the repository root
  NODE_VERSION: '18.x' # Azure Functions v4 runtime requires 18
  VERBOSE: true # For debugging

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout GitHub Action'
        uses: actions/checkout@v2

      - name: Setup Node ${{ env.NODE_VERSION }} Environment
        uses: actions/setup-node@v1
        with:
          node-version: ${{ env.NODE_VERSION }}

      - name: 'Resolve Project Dependencies Using Npm'
        shell: bash
        run: |
          pushd './${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}'
          npm install
          npm run build --if-present
          npm run test --if-present
          popd
      - name: 'Upload artifact for deployment job' # For debugging
        uses: actions/upload-artifact@v3
        with:
          name: azure-function-v4-app
          path: |
            ${{env.AZURE_FUNCTIONAPP_PACKAGE_PATH}}
            !${{env.AZURE_FUNCTIONAPP_PACKAGE_PATH}}/node_modules
            !${{env.AZURE_FUNCTIONAPP_PACKAGE_PATH}}/dist          
      - name: 'Run Azure Functions Action'
        uses: Azure/functions-action@v1
        id: fa
        with:
          app-name: 'swa-api' # change this to your Azure Function app name
          slot-name: 'Production'
          package: ${{env.AZURE_FUNCTIONAPP_PACKAGE_PATH}}
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_123 }}
          scm-do-build-during-deployment: false
          enable-oryx-build: false
    Eigenschaftenänderung Zweck
    name Kürzen Sie den Namen, damit Sie ihn ganz einfach in der GitHub-Aktionsliste Ihrer Verzweigung finden können.
    paths Fügen Sie den Pfadabschnitt hinzu, um die Ausführung der Bereitstellung nur zu beschränken, wenn sich der Azure Functions-API-Code ändert. Wenn Sie die Workflowdatei bearbeiten, können Sie die Bereitstellung manuell auslösen.
    AZURE_FUNCTIONAPP_PACKAGE_PATH Wenn Sie eine Unterdirektion für Quellcode verwenden, muss dies dieser Unterverzeichnispfad und -name sein.
    VERBOSE Diese Einstellung ist hilfreich beim Debuggen des Build- und Bereitstellungsprozesses.
    Schritt mit dem Namen Upload artifact for deployment job Dieser Schritt erstellt ein herunterladbares Artefakt. Dies ist hilfreich beim Debuggen genau der Dateien, die in Ihrer Azure-Funktion bereitgestellt werden.

    Dies Upload artifact for deployment job ist optional. Es wird verwendet, um zu verstehen und zu debuggen, welche Dateien in Azure Functions bereitgestellt werden oder um diese Dateien in einer separaten Umgebung zu verwenden.

  9. Speichern Sie die Datei, fügen Sie die Datei hinzu, übernehmen Sie ihn, und übertragen Sie sie mit GitHub zurück:

    git add .
git commit -m "fix the workflow for a subdir"
git push origin main

  10. Führen Sie in einem Browser den Workflow auf GitHub im Aktionsbereich Ihrer Verzweigung erneut aus.

    Screenshot of GitHub forked repository, showing how to rerun a GitHub action.

  11. Warten Sie, bis die Aktion erfolgreich abgeschlossen wurde, bevor Sie fortfahren.

  12. Verwenden Sie in einem Webbrowser den externen API-Endpunkt Ihrer Funktions-App, um zu überprüfen, ob die App erfolgreich bereitgestellt wurde.

    https://YOUR-FUNCTION-APP-NAME.azurewebsites.net/api/todo

    Das für die Speicherdaten zurückgegebene JSON-Ergebnis lautet:

    {
    "1": "Say hello"
}

  13. Notieren Sie sich die URL Ihrer Funktion. Sie benötigen dies im nächsten Abschnitt.

  14. Sie wissen, dass Ihre Azure Function-App in der Cloud funktioniert. Jetzt müssen Sie Ihre statische Web-App in der Cloud erstellen, um die API zu verwenden.

6. Erstellen einer neuen statischen Azure-Web-App

Dieser Erstellungsprozess stellt dasselbe Verzweigungs-GitHub-Beispielrepository in Azure bereit. Sie konfigurieren die Bereitstellung so, dass nur die Front-End-App verwendet wird.

  1. Öffnen Sie die Azure-Portal, und melden Sie sich mit Ihrem Azure-Konto an: Azure-Portal.

  2. Führen Sie die folgenden Informationen aus, um die Erstellungsschritte auszuführen:

    Eingabeaufforderung Einstellung
    Subscription Wählen Sie das Abonnement aus, das Sie verwenden möchten.
    Ressourcengruppe Wählen Sie aus, und geben Sie Create new eine neue für die Ressourcengruppe ein, z first-static-web-app. B. . Der Name wird nicht in der öffentlichen URL der App verwendet. Ressourcengruppen helfen Ihnen beim Gruppieren von Ressourcen, die für ein einzelnes Projekt verwendet werden.
    Typ des Hostingplans Wählen Sie Free aus.
    Details zu Azure Functions und Staging Ändern Sie die Standardeinstellung nicht. Sie stellen die Funktions-API nicht innerhalb der statischen Web-App bereit.
    Bereitstellungsdetails – Quelle Wählen Sie GitHub aus.
    Bereitstellungsdetails – GitHub Melden Sie sich bei GitHub bei Bedarf an.
    Bereitstellungsdetails – Organisation Wählen Sie Ihr GitHub-Konto aus.
    Bereitstellungsdetails – Repository Wählen Sie das verzweigte Repository mit dem Namen aus azure-typescript-e2e-apps.
    Bereitstellungsdetails – Branch Wählen Sie die main Verzweigung aus.
    Builddetails – Build presents Wählen Sie Custom aus.
    Builddetails – App-Speicherort Geben Sie /app-react-vite ein.
    Builddetails – API-Speicherort Leer lassen
    Builddetails – Ausgabespeicherort Geben Sie den Speicherort des Ausgabeverzeichnisses des Front-End-Verzeichnisses ein. dist

  3. Klicken Sie aufÜberprüfen + erstellen und dann auf Erstellen.

  4. Wenn die Ressource erstellt wird, wählen Sie die Go to resource Schaltfläche aus.

  5. Notieren Sie sich auf der Seite "Übersicht" die URL Ihrer statischen Web-App. Sie benötigen dies im nächsten Abschnitt, wenn Sie die CORS-Einstellung der Azure-Funktion festlegen.

  6. Der Erstellungsprozess erstellt eine GitHub-Yaml-Workflowdatei in Ihrem verzweigten GitHub-Repository. Ziehen Sie diese Änderung mit dem folgenden Befehl nach unten:

    git pull origin main

  7. Die GitHub-Aktion, die unter ./.github/workflows/azure-static-web-apps-*.yml "GitHub" zu finden ist, ist für das Erstellen und Bereitstellen der Front-End-App verantwortlich. Bearbeiten Sie die Datei, um eine Umgebungsvariable für die cloudbasierte Back-End-API-URL hinzuzufügen. Die zu bearbeitenden Zeilen werden im folgenden Yaml-Block hervorgehoben und unterhalb des Yaml-Blocks erläutert.

    name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
    paths:
      - 'app-react-vite/**'
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main
    paths:
      - 'app-react-vite/**'      
  workflow_dispatch:

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || github.event_name == 'workflow_dispatch' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_ORANGE_DUNE_123 }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "/app-react-vite" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "dist" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######
        env: 
          VITE_BACKEND_URI: https://swa-api-123.azurewebsites.net
          VITE_CLOUD_ENV: production

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_ORANGE_DUNE_123 }}
          action: "close"
    Eigenschaftenänderung Zweck
    paths Fügen Sie den Pfadabschnitt hinzu, um die Ausführung der Bereitstellung nur zu beschränken, wenn sich der Azure Functions-API-Code ändert. Wenn Sie die Workflowdatei bearbeiten, können Sie die Bereitstellung manuell auslösen.
    workflow_dispatch Fügen Sie nur beim Erlernen des Bereitstellungsprozesses hinzu, und debuggen Sie workflow_dispatchalle Probleme im Vite-Build. Entfernen Sie diese Zeile, wenn Sie diesen Quellcode über diesen Artikel hinaus fortsetzen.
    if ... || github.event_name == 'workflow_dispatch' Schließen Sie das workflow_dispatch Ereignis so ein, dass nur ein Build generiert werden darf, während Sie den Bereitstellungsprozess erlernen und alle Probleme im Vite-Build debuggen.
    env Fügen Sie die Umgebungsvariablen hinzu, die erforderlich sind, um die URL der Azure-Funktions-API in den statischen Build mit Vite aufzunehmen. VITE_BACKEND_URL ist die URL Ihrer Azure-Funktions-App. VITE_CLOUD_ENV ist ein Parameter, der angibt, wann die VITE_BACKEND_URL-URL verwendet werden soll. Verwenden Sie NODE_ENV für dieses Beispiel nicht, da sie unbeabsichtigte Auswirkungen hat.

  8. Speichern Sie die Datei, fügen Sie die Datei hinzu, übernehmen Sie ihn, und übertragen Sie sie mit GitHub zurück:

    git add .
git commit -m "fix the workflow for a subdir"
git push origin main

  9. Führen Sie in einem Browser den Workflow auf GitHub im Aktionsbereich Ihrer Verzweigung für Ihre statische Web-App erneut aus.

  10. Ihre Front-End-App wird in Azure bereitgestellt. Jetzt müssen Sie die Azure Function-App so konfigurieren, dass CORS-Anforderungen aus Ihrer statischen Web-App zugelassen werden.

7. Konfigurieren von CORS für Ihre Azure Function-App

Wenn Sie eine separate Azure Function-App anstelle einer verwalteten Funktions-App verwenden, müssen Sie CORS so konfigurieren, dass Anforderungen von Ihrer statischen Web-App zugelassen werden.

  1. Öffnen Sie in der Azure-Portal Ihre Azure-Funktions-App.
  2. Fügen Sie im Abschnitt "API –> CORS " die URL Ihrer statischen Web-App zur Liste der zulässigen Ursprünge hinzu.

8. Testen Ihrer statischen Web-App

  1. Öffnen Sie in einem Browser Ihre statische Web-App.
  2. Interagieren Sie mit der App, um sich anzumelden, öffentliche und private Informationen anzuzeigen und sich erneut abzumelden.

9. Bereinigen aller in dieser Artikelreihe verwendeten Ressourcen

Bereinigen Sie alle Ressourcen, die in dieser Artikelserie erstellt wurden.

  1. Löschen Sie in der Azure-Portal Ihre Ressourcengruppe, die die statische Web-App und die Funktions-App löscht.
  2. Löschen Sie im GitHub-Portal Ihr Verzweigungs-Repository.

Problembehandlung

In diesem Beispiel wird eine Liste bekannter Probleme und Lösungen beibehalten. Wenn Ihr Problem nicht aufgeführt ist, öffnen Sie ein Problem.

Öffentliche URLs für statische Web-App und Funktions-App

Sie finden immer die URL Ihrer statischen Web-App und die URL Ihrer Funktions-App im Azure-Portal auf der Seite "Übersicht" jeder Ressource. Diese URLs sind standardmäßig öffentlich.

Nächste Schritte