Bridge.SSPAF: Sharpie Single Page Application Framework – Parte 1

Repository del progetto di esempio: https://github.com/markjackmilian/spaf101

L’obiettivo primario di SSPAF è quello di creare una architettura applicativa comoda e familiare ad uno sviluppatore .net per poter creare single page application in Javascript scrivendo esclusivamente codice C#.

Prima di iniziare la presentazione, facciamo qualche considerazione sull’uso di framework javascript.

Abbiamo davvero bisogno di un framework JS?

Ad oggi usare un framework js pare essere diventato un obbligo, infondo chi vuole “reinventare la ruota ogni volta”?

Cito parte di un articolo che mi ha fatto sorridere:

Ok, sto costruendo una bici. Non ho bisogno di reinventare la ruota, mi limiterò a prendere un framework con una ruota.
E un volante.
E un cofano. In blu.
E un motore.
E un lettore CD.
Cosa, non hai nessun CD? Bene, basta non usarlo. O semplicemente utilizzare l’adattatore del lettore CD come lettore MP3.
Per la tua bicicletta.
Che stai ancora costruendo. Ma ora sulla struttura di un’auto.
Ma va bene, perché AutocarJS ha un sistema di plugin modulare che ti permette di aggiungere pedali per biciclette alla tua abominevole auto-bike. È facile.
Basta digitare ‘autocar scaffold add pedals’.
Oppure modificare il file autocar.js.manifest.nightmare
É molto piu’ facile, eh?

“Non c’è bisogno di reinventare la ruota” va bene in queste condizioni:

sai come funziona una ruota

sai come funziona questa ruota

questa ruota non include un mucchio di funzionalità che non userai mai.

si vuole solo una ruota

Quello che ironicamente si è cercato di esprimere è che spesso i framework JS hanno molto di più di quanto necessario e l’assemblaggio selvaggio di componenti, pacchetti e referenze può diventare davvero difficile da gestire e manutenere.

Un esempio?

React-scripts, che viene risolto in fase di creazione di una applicazione React, risolve quasi 1300 dipendenze (se avete tempo e voglia potete vedere questa visualizzazione: https://npm.anvaka.com/#/view/2d/react-scripts ).

Confesso che osservare l’espansione dei nodi ha un che di ipnotico..  ma 220 mb di node module per un “hello world” mi sembrano eccessivi. 🙂

Ognuna di queste dipendenze avrà il/i suoi manutentori con i propri tempi, modalità e anche eventuali problemi.

https://github.com/facebook/create-react-app/issues/6469

https://github.com/facebook/create-react-app/issues/7120

La verità è che in fondo non è così obbligatorio utilizzare un framework JS a tutti i costi:

Dobbiamo considerare inoltre che Javascript, come ogni altro linguaggio, ha i suoi pregi, difetti, peculiarità e forzature che, a differenza di linguaggi fortemente tipati, spesso sono valutabili e percepibili solo al momento dell’esecuzione. Questa caratteristica lo rende un ambiente più complesso da padroneggiare in particolare nel caso in cui non si lavori su Javascript a tempo pieno.

Un elenco molto esaustivo (e divertente) di comportamenti “anomali” è consultabile sulla pagina Github WFJS

Lavorando prevalentemente in ambito .NET, mi capita di stare mesi senza scrivere una riga di Javascript e quando mi sono trovato a dover lavorare con framework JS su progetti importanti e medio-grandi confesso che il “Time to Market” ne ha risentito un po’.

Lavorare quotidianamente con determinati strumenti, tipi e semantica, porta ad orientare la metodologia di sviluppo intorno a paradigmi noti, che permettono un livello di efficienza e produttività che in altri contesti è difficilmente garantibile.

Ma Bridge.Spaf è un altro framework JS?

No perché il frameworkè scritto e pensato per essere usato in .NET

in quanto il risultato è codice Javascript

L’idea dietro a Spaf è quella di offrire un’architettura comoda, veloce e minimale.

  • Dipendenze minimali
  • Stack di compilazione semplice e coerente con il mondo .NET
  • Totale controllo sul codice generato
  • Funzionalità base di architettura

Detto questo, credo che nel caso tu sia uno sviluppatore .NET, per una buona percentuale del tuo tempo di lavoro potrai trovare l’impostazione e la metodologia di sviluppo di Spaf gradevole e produttiva. Viceversa, nel caso tu sia uno sviluppatore JS full time, tutto questo ti potrà sembrare grottesco.

“de gustibus non disputandum est”

… iniziamo la nostra single page application in C#.

Da C# a JS

Come anticipato SPAF è un framework per lo sviluppo di applicazioni single page javascript web ed utilizza Bridge.Net per la transpilazione da codice .NET a JS.

Bridge.Net permette di sviluppare in C# e di ottenere codice JS (con dipendenza a bridge.js). In rete è possibile trovare una documentazione esaustiva e un playground di prova.

Ho conosciuto Bridge 3 anni fa e ho iniziato ad usarlo con successo su progetti personali e lavorativi, tanto da portare anche altri membri del team ad apprezzarlo. In questi 3 anni ho potuto assistere a notevoli miglioramenti ed evoluzioni di Bridge; una su tutte la possibilità di debuggare C# sul debugger di browser basati su Chromium. Dopo averlo utilizzato per creare piccoli script su pagine html, ho iniziato a pensare che sarebbe stata utile, gradita e produttiva una serie di librerie per creare un piccolo framework di sviluppo SPA. Ho iniziato quindi a fare una lista di cosa avrebbe dovuto avere:

  • IOC Container & Dependency Injection
  • Sistema di Navigazione
  • Meccanismo di Publisher-Subscriber
  • Binding a doppia via con la vista (basato su Knockout Js)
  • Template di progetto (SpafApp)

Ho sviluppato ogni componente in un progetto indipendente, riunificandole nel progetto Template che sarebbe stato il Nuget Bridge.Spaf.

Nell’ultima release 19.x.x ho preferito distribuire il Nuget come sources ed ho optato per riunificare tutto sotto un unico repository, lasciando solo Bridge.Ioc come progetto separato. La distribuzione tramite sources ha semplificato l’allineamento con le versioni di Bridge.Net.

Il primo commit di Bridge.Spaf risale al 07/05/2017 (per pura coincidenza il mio compleanno 🙂 ) e in questi 2 anni ha subito notevoli miglioramenti, integrazioni e sviluppi, essendo utilizzato anche su sistemi in produzione piuttosto complessi.

Al tempo di una delle prime versioni, preparai anche due video introduttivi per uno startup di progetto; anche se con qualche variazione, sono ancora decisamente affidabili.

Startup e Navigazione

Startup e Navigazione

Viewmodels:

ViewModels

Durante l’utilizzo in contesti di produzione si è rivelato necessario pensare un ambiente per testare il codice lato client; in seguito a questa esigenza ho sviluppato un piccolo ambiente di test Bridge.EasyTest. Questi test vengono fatti direttamente sul codice JS generato e i risultati vengono mostrati in una pagina html creata da EasyTest.

Una demo di un progetto “reale” è raggiungibile qui:

https://markjackmilian.github.io/realworld.spaf#home

I relativi sorgenti sono consultabili qui:

https://github.com/markjackmilian/bridge.spaf-realworld-app

SPAF è listato come framework “Realworld”:

https://github.com/gothinkster/realworld

A brevissimo pubblicheremo la seconda parte dell’articolo, in cui verrà affrontato il progetto pratico nel dettaglio. —->

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *