ASP.NET Core è una piattaforma matura?

ASP.NET Core è il framework Web open-source di Microsoft, l'azienda di Redmond due anni fa decise di rivedere completamente il suo approccio nello sviluppo per Internet presentando una soluzione riscritta da zero che includeva i progetti precedenti: ASP.NET MVC e API Web ASP.NET. Microsoft si è avvalsa dei suggerimenti e del supporto della sua vasta community di sviluppatori in modo da individuare le esigenze e le preferenze dei developer di terze parti che fanno riferimento alla sua piattaforma.

ASP.NET Core è un framework Web modulare che funziona sia su .NET Framework completo, su Windows e su .NET Core multipiattaforma, dunque è possibile sfruttarlo ovunque indipendente dal sistema operativo o dalla piattaforma software scelta per iniziare lo sviluppo della propria applicazione o servizio. Nonostante si tratti di un nuovo framework, costruito su un nuovo stack Web, presenta un elevato grado di compatibilità con i precedenti progetti di Microsoft dedicati allo sviluppo web.

Le applicazioni ASP.NET Core supportano il controllo delle versioni affiancate, con cui diverse applicazioni, in esecuzione sulla stessa macchina, possono scegliere come target versioni diverse di ASP.NET Core.

Rispetto al .NET Framework standard gli aggiornamenti rilasciati hanno una cadenza molto più frequente e questo spesso porta ad alcune problematiche di aggiornamento. Se un'azienda deve mantenere un alto numero di microservizi che utilizzano ASP.NET Core, l'upgrade non è sempre un'operazione semplice. Inoltre non sono solo ASP.NET Core, ma tutti gli assembly satelite costruiti su .NET Core sono in costante evoluzione e, negli ultimi tempi, Microsoft sta rilasciato numerosi update. Basterebbe fare riferimento al tasso di cambiamento di progetti come Serilog e Swashbuckle per trovare dei validi esempi.

Tuttavia .NET Core offre meno pacchetti e questi risultano essere comunque molto più stabili rispetto alle soluzioni della concorrenza. Nell'ecosistema di Node.js diversi sviluppatori si lamentano perché diversi pacchetti sono instabili e costantemente in fase di revisione. Quindi stare al passo con le ultime novità è una battaglia costante ed ogni volta che si aggiorna un package Node.js c'è anche il rischio che si manifesti qualche malfunzionamento, cosa che sembrerebbe accedere meno spesso con i pacchetti per .NET Core.

.NET Core e ASP.NET Core erano inizialmente progetti molto leggeri e con poche API disponibili. Spesso si doveva eseguire il rollover del proprio codice, anche per funzionalità di base che sarebbero dovute già essere implementate. Fortunatamente oggi sono state integrate svariate API e dove ci sono lacune la comunità le colma tramite pacchetti di terze parti. Non poche di queste lacune sono poi specifiche di Windows e, probabilmente, diverse novità arriveranno solo nel timeframe di .NET Core 3.0.

Ci sono poi dei settori dove effettivamente .NET Core non regge il confronto con i suoi concorrenti diretti, come ad esempio Node.js. Le API di compressione dell'immagine quasi non esistono su .NET. Microsoft è infatti arrivata ​​in ritardo per quanto riguarda il supporto alla compressione con Brotli, aggiunta su .NET Core di recente e presto implementato anche per il middleware di compressione ASP.NET Core.

Ci sono però casi come GraphQL.NET, che è molto ricco di funzionalità ma è ancora in ritardo rispetto all'implementazione di Apollo.

Uno degli elementi che ha fatto la differenza durante la a creazione di .NET Core e ASP.NET Core è la natura open source. In passato gli sviluppatori dovevano consultare la documentazione di .NET Framework per capire il funzionamento di un'API, oggi il nuovo riferimento per i coder è GitHub, con cui accedere al codice ed esporre problemi specifici del proprio progetto. Non si può sottovalutare quanto questo abbia migliorato gli standard di vita della community.

Diversi team di sviluppatori stanno riscontrando aumenti di prestazioni ad ogni aggiornamento della piattaforma. Su questo versante una feature interessante è .NET Native, dove il codice C # è compilato direttamente in codice nativo invece che in una lingua intermedia. Ciò significa che il linguaggio intermedio non ha bisogno di sfruttare un compilatore just-in-time ed essere trasformato in codice macchina. Con .NET Native si può ottenere facilmente un singolo file eseguibile, sfruttando i vantaggi di linguaggi di basso livello come Go o Rust, ma eliminando le problematiche di sviluppo con linguaggi simili. .NET Native è però ancora in fase di sviluppo e probabilmente bisognerà aspettare dopo il rilascio di ASP.NET Core 3.0 per vederlo in azione sugli ambienti di produzione.

.NET è nella posizione piuttosto rara di avere un gran numero di pacchetti ufficiali scritti e gestiti da Microsoft. Ciò significa che si ha bisogno di meno pacchetti di terze parti e a volte è possibile creare un progetto senza sfruttare dipendenze da terze parti. Ciò significa anche che le dipendenze di terze parti che si finisce per usare hanno a loro volta meno dipendenze. Dal punto di vista della sicurezza NuGet ha recentemente integrato il supporto per i pacchetti firmati, in modo da evitare manomissioni tra il server di NuGet e la macchina di compilazione.

Uno dei talloni d'Achille di ASP.NET Core è la gestione del caching, infatti attualmente la cache di risposta supporta solo l'in-memory caching. Se si desidera memorizzare nella cache in Redis utilizzando IDistributedCache non è possibile farlo. Anche utilizzando la in-memory caching, se si usano i cookie o l'intestazione HTTP di autorizzazione il caching della risposta viene disattivato.

Per quanto riguarda il supporto ad HTTPS e all'implementazione di soluzioni come Lets Encrypt, il progetto sta andando abbastanza a rilento, lo stesso vale per HTTP3. Tale protocollo (precedentemente denominato QUIC) di base può già funzionare con Kestrel, ma a livello di integrazione non è il massimo. Le App di ASP.NET Core sono comunque nascoste dietro un server Web proxy come IIS o NGINX che implementa questi protocolli. Anche il "Servizio app" di Azure viene eseguito dietro un fork di IIS. Inoltre è possibile utilizzare Kubernetes per esporre l'app ASP.NET Core sulla porta 80 e ottenere un miglioramento delle prestazioni.

Altro punto "dolente" di ASP.NET Core è la pubblicazione di file statici. Non è possibile utilizzare il middleware di autorizzazione per limitare l'accesso ai file statici anche se probabilmente questo aspetto dovrebbe essere migliorato con ASP.NET Core 3.0.

ASP.NET Core è una piattaforma matura? Lo è sicuramente sotto diversi punti di vista. Microsoft sta investendo su questo progetto e nelle future release sempre più funzionalità verranno aggiunte o migliorate. In questi anni si è potuta osservare l'ascesa di linguaggi completamente nuovi che ne hanno spodestato altri. Gli sviluppatori Android sono passati da Java a Kotlin e lo stesso è successo con i developer Apple che hanno vissuto una migrazione da Object-C a Swift. Dove una volta le App sarebbero state scritte in C++, ora sono scritte in Go o Rust.

.NET Core sembra essere l'unico ad aver "rallentato" tale tendenza, cercando di reinventarsi completamente senza stravolgere il proprio ecosistema.

Via Rehansaeed