Share via


Créer une application web statique avec une API serverless

Découvrez comment exécuter localement, puis déployer une application web statique avec une API serverless sur Azure. Ce tutoriel utilise la préversion du dernier modèle de programmation Azure Functions Node.js. Étant donné que cet article utilise une préversion d’Azure Functions, il est déployé en tant qu’application distincte de l’application web statique.

Découvrez comment :

  • Exécuter localement une application web statique (SWA) avec une application de fonction Azure
  • Demandes frontales de proxy locale vers l’API principale locale à l’aide de l’interface CLI SWA.
  • Déployez et exécutez le même code à distance.

Le proxy entre le serveur frontal et le backend-endis fourni par l’interface CLI de l’application web statique fournit :

  • L’URL dans React, /api/todone spécifie pas le serveur ou le numéro de port de l’API. Les demandes qui utilisent cette URL aboutissent localement, car l’interface CLI SWA gère le proxy pour vous.
  • Un émulateur d’authentification local lors de l’accès à /.auth/login/<provider>
  • La gestion et l’autorisation des routes

Authentification dans cet exemple

L’authentification dans cet exemple est fournie pour les utilisateurs frontaux à partir du service Azure Static Web Apps :

  • Connexion/déconnexion
  • Contenu public et privé

Code source dans cet exemple

Le code source de cet exemple est destiné à apprendre à générer et déployer une application web statique avec une API serverless. Le code n’est pas destiné à la production.

Vous trouverez plusieurs emplacements dans le code qui ne suivent pas les meilleures pratiques de sécurité. Par exemple, le code utilise console.log pour écrire dans la console du navigateur.

Lorsque vous passez à un environnement de production, vous devez passer en revue et supprimer tout code, qui enfreint les meilleures pratiques de sécurité pour votre organisation.

1. Préparer votre environnement de développement

Créez les comptes ci-après :

Installez les éléments suivants sur votre ordinateur de développement local :

2. Fork l’exemple de référentiel sur GitHub

Vous devez disposer de votre propre fourche du référentiel d’exemples pour terminer le déploiement à partir de GitHub. Pendant le processus de duplication, vous devez uniquement copier la main branche.

Fork de l’exemple de référentiel : https://github.com/Azure-Samples/azure-typescript-e2e-apps.

3. Clonez l’exemple de référentiel dupliqué

  1. Dans un terminal bash, clonez votre dépôt forked sur votre ordinateur local. Ne clonez pas l’exemple de référentiel d’origine. Un exemple d’URL est https://github.com/YOUR-ACCOUNT-NAME/azure-typescript-e2e-apps

    git clone YOUR-FORKED-REPO-URL
    
  2. Installez les dépendances pour l’application frontale locale :

    cd app-react-vite && npm install 
    
  3. Installez les dépendances pour l’application principale locale :

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

4. Facultatif, générer et exécuter l’application locale

L’exemple de référentiel comporte plusieurs versions des applications front-end et back-end. Les étapes suivantes utilisent la version React 18 (Vite) du serveur frontal et la fonction Azure v4 avec Node.js version du back-end avec les /status itinéraires d’API./todo

  1. À partir de la racine de l’exemple d’application, utilisez l’interface CLI SWA avec le ./swa-cli.config.json fichier pour générer les applications frontales et principales :

    swa build
    

    Si vous rencontrez des erreurs, qui peuvent se produire selon la version de divers packages et de votre environnement, corrigez-les avant de continuer. Il est important de savoir que votre projet s’appuie correctement localement avant de passer au déploiement vers Azure Static Web Apps.

  2. À partir de la racine de l’exemple d’application, utilisez l’interface CLI SWA pour démarrer les applications avec un proxy.

    swa start
    
  3. Lorsque vous voyez les lignes suivantes dans le terminal bash, le projet a démarré correctement.

    [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. Ouvrez un navigateur web sur l’URL proxiée. http://localhost:4280 Vous devriez voir la page suivante :

    Screenshot of local React app prior to authentication.

  5. Vous pouvez vous connecter à l’aide de l’authentification fournie par l’interface CLI SWA. Le processus simulant l’authentification dans les applications web statiques Azure basées sur le cloud. Le code frontal utilise le /.auth/me point de terminaison pour obtenir l’identité de l’utilisateur. Entrez un faux nom d’utilisateur et ne modifiez pas le reste des champs.

    Screenshot of local React app's mock authentication form.

  6. Une fois qu’un utilisateur est authentifié, le serveur frontal affiche des informations privées telles que les variables d’environnement de l’API.

    Screenshot of local React app with authentication complete.

    Le code source de l’application Azure Function v4 pour cette API est :

    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. Développez les sections publiques et privées pour afficher le contenu de l’API.

5. Créer une application Azure Functions

La section précédente de l’exécution de l’application web statique avec l’API était facultative. Les sections restantes de l’article sont requises pour déployer l’application et l’API sur le cloud Azure.

Pour utiliser la préversion du runtime Azure Functions v4, vous devez créer une application Azure Functions. Votre application web statique doit également être reconstruite et redéployée pour utiliser l’URI de l’application Azure Functions dans les requêtes Fetch vers l’API au lieu d’utiliser une API proxiée et gérée.

  1. Dans un navigateur web, ouvrez le Portail Azure pour créer une application Azure Functions : Créer une application

  2. Utilisez les informations suivantes pour créer l’application de fonction :

    Tab :Setting Valeur
    Principes de base : Abonnement Sélectionnez l’abonnement que vous souhaitez utiliser.
    Notions de base : Groupe de ressources Créez un groupe de ressources tel que first-static-web-app-with-api. Le nom n’est pas utilisé dans l’URL publique de l’application. Les groupes de ressources vous aident à regrouper et à gérer les ressources Azure associées.
    Informations de base : Détails de l’instance : Nom de l’application de fonction Entrez un nom global unique tel que swa-api 3 caractères aléatoires ajoutés à la fin, tels que swa-api-123.
    Concepts de base : Détails de l’instance : Code ou conteneur Sélectionnez Code.
    Notions de base : Détails de l’instance : pile d’exécution Sélectionnez Node.js.
    Notions de base : Détails de l’instance : pile d’exécution Sélectionnez 18LTS.
    Principes de base : Système d’exploitation Sélectionnez Linux.
    Principes de base : Hébergement Sélectionnez Consumption.
    Stockage : compte Stockage Ne modifiez pas cette valeur. Un nouveau compte Stockage Azure est créé pour faciliter les événements de fonction.
    Mise en réseau Ne changez rien.
    Surveillance : Recommandations d’application : activer l’Recommandations d’application Sélectionnez Yes. Ne modifiez pas le nom par défaut fourni.
    Déploiement : GitHub Actions Paramètres : déploiement continu Sélectionnez Enable.
    Déploiement : compte GitHub Sélectionnez votre compte GitHub.
    Déploiement : Organisation Sélectionnez votre compte GitHub, que vous avez utilisé lorsque vous avez dépliqué l’exemple de référentiel.
    Déploiement : référentiel Sélectionnez le nom de votre dépôt forked. azure-typescript-e2e-apps
    Déploiement : Branche Sélectionnez main.
    Balises Ne changez rien.
    Vérifier + créer Sélectionnez Create.

    L’étape ajoute un fichier de flux de travail Yaml GitHub à votre dépôt forked.

  3. Lorsque la ressource est créée, sélectionnez le Go to resource bouton.

  4. Sélectionnez Paramètres -> Configuration, puis ajoutez un paramètre de configuration pour le runtime Azure Function Node.js v4 avec le nom AzureWebJobsFeatureFlags et la valeurEnableWorkerIndexing.

  5. Sélectionnez Enregistrer pour enregistrer le paramètre.

  6. Dans un terminal bash, utilisez Git pour extraire le nouveau fichier de flux de travail yaml à partir de votre dépôt forked GitHub sur votre ordinateur local.

    git pull origin main
    
  7. Dans Visual Studio Code, ouvrez le nouveau fichier de flux de travail yaml situé à l’adresse ./.github/workflows/.

  8. Le fichier de flux de travail par défaut fourni pour vous suppose que le code source de la fonction est à la racine du référentiel et est la seule application dans le référentiel, mais ce n’est pas le cas avec cet exemple. Pour résoudre ce problème, modifiez le fichier. Les lignes à modifier sont mises en surbrillance dans le bloc yaml suivant et expliquées ci-dessous :

    # 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
    
    Modification de propriété Objectif
    name Raccourcissez le nom afin de le trouver facilement dans la liste des actions GitHub de votre fourche.
    paths Ajoutez la section chemins d’accès pour limiter le déploiement à exécuter uniquement lorsque le code de l’API Azure Functions change. Lorsque vous modifiez le fichier de flux de travail, vous pouvez déclencher le déploiement manuellement.
    AZURE_FUNCTIONAPP_PACKAGE_PATH Lorsque vous utilisez un sous-répertoire pour le code source, il doit s’agir du chemin et du nom du sous-répertoire.
    VERBOSE Ce paramètre est utile pour déboguer le processus de génération et de déploiement.
    étape nommée Upload artifact for deployment job Cette étape crée un artefact téléchargeable. Cela est utile lorsque vous déboguez exactement les fichiers déployés sur votre fonction Azure.

    Facultatif Upload artifact for deployment job . Il est utilisé pour comprendre et déboguer les fichiers déployés sur Azure Functions ou pour utiliser ces fichiers dans un environnement distinct.

  9. Enregistrez le fichier, puis ajoutez, validez et renvoyez-le à GitHub avec git :

    git add .
    git commit -m "fix the workflow for a subdir"
    git push origin main
    
  10. À partir d’un navigateur, réexécutez le flux de travail sur GitHub dans la zone d’actions de votre fork.

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

  11. Attendez que l’action se termine correctement avant de continuer.

  12. Dans un navigateur web, utilisez le point de terminaison d’API externe de votre application de fonction pour vérifier que l’application a été déployée avec succès.

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

    Le résultat JSON retourné pour les données en mémoire est le suivant :

    {
        "1": "Say hello"
    }
    
  13. Notez l’URL de votre fonction. Vous en avez besoin dans la section suivante.

  14. Vous savez que votre application de fonction Azure fonctionne dans le cloud. Vous devez maintenant créer votre application web statique dans le cloud pour utiliser l’API.

6. Créer une application web statique Azure

Ce processus de création déploie le même dépôt d’exemples GitHub forked sur Azure. Vous configurez le déploiement pour qu’il utilise uniquement l’application frontale.

  1. Ouvrez le Portail Azure et connectez-vous avec votre compte Azure : Portail Azure.

  2. Utilisez les informations suivantes pour effectuer les étapes de création :

    Invite Paramètre
    Abonnement Sélectionnez l’abonnement que vous souhaitez utiliser.
    Groupe de ressources Sélectionnez Create new et entrez un nouveau pour le groupe de ressources tel que first-static-web-app. Le nom n’est pas utilisé dans l’URL publique de l’application. Les groupes de ressources vous aident à regrouper les ressources utilisées pour un seul projet.
    Type de plan d’hébergement Sélectionnez Free
    Azure Functions et détails de l’environnement de préproduction Ne modifiez pas la valeur par défaut. Vous ne déployez pas l’API de fonction dans l’application web statique.
    Détails du déploiement - source Sélectionnez GitHub
    Détails du déploiement - GitHub Connectez-vous à GitHub si nécessaire.
    Détails du déploiement - Organisation Sélectionnez votre compte GitHub.
    Détails du déploiement - Référentiel Sélectionnez le dépôt dupliqué nommé azure-typescript-e2e-apps.
    Détails du déploiement - Branche Sélectionnez la main branche.
    Détails de la génération - Présentations de build Sélectionnez Custom.
    Détails de la génération - Emplacement de l’application Saisissez /app-react-vite.
    Détails de la génération - Emplacement de l’API Laissez ce champ vide
    Détails de la génération - Emplacement de sortie Entrez l’emplacement du répertoire de sortie du serveur frontal. dist
  3. Sélectionnez Vérifier + créer, puis sélectionnez Créer.

  4. Lorsque la ressource est créée, sélectionnez le Go to resource bouton.

  5. Dans la page Vue d’ensemble , notez l’URL de votre application web statique. Vous devez le faire dans la section suivante lorsque vous définissez le paramètre CORS d’Azure Function.

  6. Le processus de création crée un fichier de flux de travail Yaml GitHub dans votre dépôt GitHub forked. Extrayez cette modification avec la commande suivante :

    git pull origin main
    
  7. L’action GitHub trouvée est ./.github/workflows/azure-static-web-apps-*.yml responsable de la création et du déploiement de l’application frontale. Modifiez le fichier pour ajouter une variable d’environnement pour l’URL de l’API principale basée sur le cloud. Les lignes à modifier sont mises en surbrillance dans le bloc yaml suivant et expliquées sous le bloc yaml.

    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"
    
    Modification de propriété Objectif
    paths Ajoutez la section chemins d’accès pour limiter le déploiement à exécuter uniquement lorsque le code de l’API Azure Functions change. Lorsque vous modifiez le fichier de flux de travail, vous pouvez déclencher le déploiement manuellement.
    workflow_dispatch Ajoutez workflow_dispatchuniquement lors de l’apprentissage du processus de déploiement et du débogage des problèmes dans la build Vite. Supprimez cette ligne lorsque vous poursuivez ce code source au-delà de cet article.
    if ... || github.event_name == 'workflow_dispatch' Incluez l’événement workflow_dispatch comme autorisé à générer une build uniquement pendant l’apprentissage du processus de déploiement et le débogage des problèmes dans la build Vite.
    env Ajoutez les variables d’environnement nécessaires pour inclure l’URL de l’API de fonction Azure dans la build statique avec Vite. VITE_BACKEND_URL est l’URL de votre application De fonction Azure. VITE_CLOUD_ENV est un paramètre pour indiquer quand utiliser l’URL de VITE_BACKEND_URL. N’utilisez pas NODE_ENV pour cet exemple, car il a des effets secondaires inattendus.
  8. Enregistrez le fichier, puis ajoutez, validez et renvoyez-le à GitHub avec git :

    git add .
    git commit -m "fix the workflow for a subdir"
    git push origin main
    
  9. À partir d’un navigateur, réexécutez le flux de travail sur GitHub dans la zone d’actions de votre fork pour votre application web statique.

  10. Votre application frontale est déployée sur Azure. Vous devez maintenant configurer l’application De fonction Azure pour autoriser les requêtes CORS à partir de votre application web statique.

7. Configurer CORS pour votre application de fonction Azure

Lorsque vous utilisez une application de fonction Azure distincte, au lieu d’une application de fonction managée, vous devez configurer CORS pour autoriser les requêtes de votre application web statique.

  1. Dans le Portail Azure, ouvrez votre application De fonction Azure.
  2. Dans la section API -> CORS , ajoutez l’URL de votre application web statique à la liste des origines autorisées.

8. Tester votre application web statique

  1. Dans un navigateur, ouvrez votre application web statique.
  2. Interagissez avec l’application pour vous connecter, afficher des informations publiques et privées, puis reconnectez-vous.

9. Nettoyer toutes les ressources utilisées dans cette série d’articles

Nettoyez toutes les ressources créées dans cette série d’articles.

  1. Dans le Portail Azure, supprimez votre groupe de ressources, qui supprime l’application web statique et l’application de fonction.
  2. Dans le portail GitHub, supprimez votre référentiel dupliqué.

Résolution des problèmes

Cet exemple conserve la liste des problèmes connus et des résolutions. Si votre problème n’est pas répertorié, ouvrez un problème.

URL publiques de l’application web statique et de l’application de fonction

Vous pouvez toujours trouver l’URL de votre application web statique et l’URL de votre application de fonction dans le Portail Azure, dans la page Vue d’ensemble de chaque ressource. Ces URL sont publiques par défaut.

Étapes suivantes