Introduzione

Sin dai primi tempi App Service su Microsoft Azure è stata la scelta PaaS per ospitare qualsiasi tipo di applicazione web. A Maggio 2020 è stata rilasciata in preview la prima versione di Azure Static Web Apps diventando una valida alternativa con il rilascio in GA (generally available) a Maggio 2021.

Come suggerisce il suo nome “Azure Static Web App”, il servizio può ospitare e gestire solo file statici, ma questo non è una limitazione in quanto la maggior parte dei portali attualmente non necessita di altro. Ne sono un esempio:

• I generatori di siti statici come Hugo, Jekyll, Gatsby che sono strutture di codice pronte all’uso, grazie alle quali è possibile sviluppare siti web statici. A differenza dei CMS, che di solito salvano i contenuti nei database ed elaborano il codice HTML lato server, i generatori di siti statici generano il codice HTML a livello locale sul computer dello sviluppatore o alternativamente nel cloud;
  
• Le Single Page applications (SPAs) scritte in JavaScript o con comuni framework come Angular, React e Vue o con altri linguaggi come Blazor WASM, utilizzato nei moderni browser che supportano il Webassembly, possono far girare il loro codice all’interno del browser solo scaricando dei file statici.

Potrebbe sembrare un alternativa con delle funzionalità ridotte, ma il tutto è contradetto dal fatto che le Azure Static Web Apps offrono dei servizi addizionali già preconfigurati come:

• La possibilità di ospitare le API (application programming interface) di backend attraverso Azure Function serverless in .Net Core, Node.js o Python;
  
• Un ambiente CI\CD già preconfigurato per i repository ospitati in GitHub e Azure DevOps (per quest’ultimo abbiamo riscontrato delle funzionalità ridotte);
  
• La possibilità, solo per repository in GitHub, di creare Ambienti (definiti Environment) di pre-produzione per ogni pull request creata sul branch main;
  
• La possibilità di distribuire i file statici come avviene con un servizio di Azure CDN (Content Delivery Network);

Pubblicare una applicazione Blazor WebAssembly

Le applicazioni Blazor WASM, a discapito delle Blazor Server Application che richiedono un .NET runtime, possono essere ospitate nelle Azure Static Web App perchè il browser deve solo scaricare i file statici dal server: assets, HTML, CSS e .Net assemblies (invece dei file javascript) .

Per poter provare gli step sotto descritti dovete utilizzare:

1. Un account GitHub (https://github.com);
2. Visual Studio 2022;
3. Un account Azure gratuito (https://azure.microsoft.com/it-it/free);

Al momento non è stato creato alcun template per Visual Studio, quindi procedete con il seguente link: https://github.com/staticwebdev/blazor-starter/generate che caricherà i file necessari per la vostra Blazor WASM all’interno di un vostro repository.

Dal pulsante “Code” (Codice) in alto a destra della pagina del repository appena creato (https://github.com/dandresini/myblazorapp), selezionate la voce “Apri in Visual Studio” per scaricare (clonare) in locale i file dell’intera soluzione.

La solutione in .NET 6 Blazor WASM consiste in quattro progetti con delle linee guida ben definite per strutturare al meglio il vostro codice:

• Client è l’applicazione Blazor WebAssembly, molto simile a quella creata dal template di Visual Studio ad eccezione della Pagina Weather Forecast dove vi è una chiamata ad Azure Function anzichè al file JSON;
• Api è un progetto di Azure Function che mette a disposizione i dati;
• ApiIsolated è un progetto di Azure Function che utilizza un processo isolato. Questo risulterà familiare agli sviluppatori ASP.NET Core, perchè consente di configurare le dipendenze e il middleware esattamente nello stesso modo in cui sono abituati. Inoltre una delle motivazioni principali per l’utilizzo della modalità “Isolated Process” è che non si è legati alla versione del runtime .NET e agli eventuali SDK di Azure utilizzati dal runtime delle Funzioni di Azure (per approfondire l’argomento: https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide#differences-with-net-class-library-functions);
• Shared è il progetto libreria .NET Standard Class che è il contenitore dei “tipi di dati” utilizzati nei tre progetti e nel nostro caso conterrà la definizione dell’oggetto “WeatherForecast“.

Per eseguire l’applicazione in locale basta selezionare in Visual studio la partenza multipla dei progetti basterà selezionare l’Action Start su Api e Client.

Prima di procedere con il Debug ricordiamoci di rinominare o copiare, nel progetto Api, il file local.settings.example.json in local.settings.json altrimenti riceverete un errore d’impossibilità di comunicazione con l’Azure Function perchè non sono state configurate regole di CORS (Cross-Origin Resource Sharing). Attenzione il file è utile solo per l’esecuzione in locale perchè uno dei vantaggi delle Azure Static Web App è di non preoccuparsi di configurare politiche di CORS, dato che utilizzano il reverse proxy per mappare le Azure Function con il subpath /api del domino del vostro progetto.

Se tutto è stato configurato correttamente, una volta eseguito il progetto la pagina di “Weather forecast” visualizzerà le informazioni dell’Azure Function.

A questo punto non ci resta che configurare la nostra “Azure Static Web Apps” nella nostra sottoscrizione FREE di Azure.

Come potete vedere ci sono pochi passaggi e parametri da settare:

• Il nome della sottoscrizione;
• Il Gruppo di Risorse precedentemente creato;
• Il nome dell’applicazione;
• Il tipo di piano di consumo (per i nostri scopi utilizzeremo il piano gratuito).

Per abilitare l’insieme dei passaggi automatizzati CI\CD (Continuous integration e  continuous delivery), che vengono eseguiti per fornire una nuova versione del software , si dovrà ultimare la configurazione del “Build Details” selezionando e autorizzando GitHub come sorgente (Source) per poi scegliere il branch del repository che deployeremo impostando “Blazor” dalle build presets messe a disposizione. Fase finale sarà l’inserimento e il controllo dei path della nostra soluzione più precisamente:

• App location è il percorso del progetto del vostro Blazor WASM;
• Api location è il percorso del progetto delle vostre Azure Function;
• Output location è il percorso della build che deve essere deployata sul web server del progetto Blazor WASM.

Una volta che la risorsa è stata creata, scatterà il processo di “build” e “deploy” dell’applicazione tramite GitHub Action. Fino a quando il processo non sarà completato, apparirà un link in top alla pagina di risorsa del portale di Azure che vi direzionerà sulla pagina di GitHub per visualizzare lo stato della build. L’ “URL” servirà per visualizzare l’applicazione una volta terminato il processo di deploy.

Ecco il nostro progetto di Blazor WASM su Azure Startic Web Apps…Enjoy 🙂

Ricordate che:
“Il successo è conoscere il tuo scopo nella vita, crescere per raggiungere il tuo potenziale e piantare semi per aiutare gli altri”.
John Maxwell

Scritto da: