Indice articolo

Al giorno d’oggi non è difficile realizzare una interfaccia grafica per uno specifico backend. Ma come realizzo un frontend per applicazioni che siano in grado di durare ed evolvere? Che sia semplice e che possa connettersi a qualsiasi nuovo backend che ne abbia bisogno? E quali tecnologie conviene usare?

Se non sapete dare risposta a queste domande o anche solo siete curiosi, proseguite nella lettura di questo articolo perché state per leggere come realizzare un Amazing Frontend !






The Amazing Frontend

Quali sono le caratteristiche di un “Amazing Frontend”?

Si potrebbe pensare che una interfaccia, un client, per essere definito strabiliante nella nostra accezione, debba utilizzare tecnologie futuristiche, fare di tutto (anche il caffè) e soprattutto essere eterno.

Niente di più sbagliato! Anzi l’ultima affermazione è proprio fuorviante e ci porta fuori strada.

Un frontend per essere “amazing” deve avere solo tre caratteristiche:

  • Deve avere una architettura ben pensata: nell’articolo si parla principalmente dell’architettura. “It’s all in the architecture!” dicono i nostri colleghi statunitensi.
  • Deve potere sopravvivere alla tecnologia: o meglio al cambio tecnologico. Sappiamo bene che, per quello che riguarda il frontend, ancora di più se pensiamo agli ambiti web e mobile, le tecnologie cambiano in modo rapidissimo e vengono soppiantate nel giro di pochissimi anni. Quindi dobbiamo considerare il frontend come un software che soffre di una malattia GRAVISSIMA, che se non trattata adeguatamente porta all’inevitabile morte del paziente (rifare completamente l’applicazione in continuazione).
  • Deve potere evolvere: man mano che le esigenze cambiano, le funzionalità aumentano e con esse anche la possibilità di interfacciarsi a sempre più “cose” (backend, device, servizi) , il frontend deve potere essere esteso in modo semplice ed efficace. Anche in questo caso senza ricominciare da capo.

Cosa abbiamo realizzato??

Prima di mostrarvi, nel dettaglio, le meraviglie dell’architettura di cui stiamo parlando, mi sembra il caso di di raccontarvi cosa abbiamo fatto per provare la bontà dell’approccio. E quali sono le tecnologie che abbiamo utilizzato e che meglio si adattano, secondo noi, alla realizzazione di un “Amazing Frontend”.

Partiamo da queste ultime.

Per quello che riguarda il mobile:

  • Dart
  • Flutter

Per chi non lo sapesse, il secondo è un framework di Google per lo sviluppo cross-platform, in particolare di applicazioni mobile (ma di recente anche per il web), con una community molto florida. E utilizza proprio Dart come linguaggio di programmazione.

Per quello che riguarda il web invece:

  • Typescript
  • Vue.js
  • Web Components

Questi ultimi nell’accezione della nostra libreria Open Source “Ketchup”.

Tramite l’utilizzo di queste tecnologie abbiamo realizzato due distinte applicazioni. Una app mobile nativa e crossplatform (iOS e Android) e una SPA (Single page application) web che abbiamo chiamato webupjs.

Queste applicazioni sono contemporaneamente:

  • Online/Offline: in modo trasparente.
  • Statiche/dinamiche: sia per quello che riguarda il contenuto e la struttura della pagina, sia per quello che riguarda la navigazione.
  • Multi-backend: grazie al meccanismo dei servizi interni, di cui parleremo nel dettaglio poi in questo articolo.

Ecco l’architettura “MAGICA”


Tenetevi forte perchè iniziamo a parlare di questa “ARCHITETTURA MAGICA”.
Non spaventiamoci davanti allo schema qui sopra: Si riferisce all’architettura dell’applicazione web. Quindi realizzata tramite VUE.js, e typescript. Abbiamo una parte, il layer in alto in ogni schema, relativa alla componentistica, ai componenti semplici o applicativi (complessi), che nel caso della SPA sono web component della libreria ketchup, e una parte di “connettori” verso i servizi dei backend che implementano relative logiche.

Una cosa, importante, che si dovrebbe capire subito da questo schema è la possibilità di avere delle schermate statiche (come nel primo schema, ad esempio un login) dove tutta la struttura è predefinita ed è decisa a livello di programmazione, delle schermate dinamica (secondo schema ad esempio) dove la struttura di quello che viene mostrato, i servizi backend da chiamare e le relative logiche sono definite tramite un DSL interpretato dall’applicazione che genera la schermata.

Osservando attentamente il layer in basso di ogni passaggio, si nota che è possibile connettersi a servizi (e quindi backend) differenti, webservices, fonti dati esterne o addirittura recuperare informazioni presenti localmente (struttura della pagina compresa) e accedere a risorse locali.

Online vs Offline? No! Online & Offline

Ho accennato prima che l’applicazione può essere online o offline. In realtà è contemporaneamente offline e online. E’ trasparente sia per l’utente sia per l’app stessa.

All’interno dell’applicazione viene utilizzato “un meccanismo”, una libreria che permette di avere “on board sul device” una replica dei dati che devono essere accessibili anche in assenza di connettività e che vengono automaticamente sincronizzati.

Abbiamo utilizzato firebase-firestore perché è una soluzione già completa e “comoda”, ma ovviamente non è l’unica possibilità.

Questo meccanismo consente di fare due cose:

  • Di avere una sorta di cache, cioè di avere una modalità offline in caso di perdita di connettività.
  • L’altro caso, più interessante, è quello di avere una gestione offline “reale”, in cui i dati vengono pre caricati dal backend nel database in cloud e tenuti sincronizzati dalla libreria con tutti i dispositivi su cui è in uso l’applicazione.

Per accedere a questi dati, in lettura e in scrittura, vengono usati quelli che chiamiamo servizi interni. In questo caso sono loro che permettono il passaggio tra una modalità e l’altra e anche tra fonti dati diverse. Per esempio una app potrebbe dialogare con un backend ed avere anche un fonte dati interamente “offline”. Il frontend utilizza sempre dei servizi e non deve sapere altro.

Schermate dinamiche/statiche

Questa architettura prevede due tipologie di schermata:

  • Tipo dinamico: la struttura della pagina e la navigazione sono definite tramite un JSON. Abbiamo utilizzato JSON anche per rappresentare i dati, per semplicità. Questi JSON possono essere fisicamente più o meno ovunque, anche on board sul client. Tipicamente stanno sul backend.
  • Tipo statico: si tratta di pagine ad-hoc. La struttura, i contenuti ed i servizi chiamati dalla pagina sono definiti, come avviene per tutte le applicazioni convenzionali, dal programmatore che realizza la pagina.

Servizi interni: amici molto “stretti”

Ora che avete capito come è fatto questa architettura, voglio parlarvi dei servizi interni. Sono nostri “amici”, in quanto ci aiutano molto e fanno davvero tante cose.

Fanno parte dello strato dei connettori, la parte basso dello schema, e permettono di accedere ad un backend qualsiasi. L’interfaccia dialoga chiamando servizi.

Un servizio interno è un servizio implementato nell’app che fa da connettore e che nasconde la logica specifica per un particolare backend. Si occupa, ove necessario, di convertire i dati dal backend in un formato “neutro” interpretabile dall’applicazione.

Permettono anche l’accesso a risorse locali (JSON dati, JSON struttura della pagina o altro).

Ma la cosa più importante è che questi servizi si richiamano come tutti gli altri servizi a cui siamo abituati.
Quindi tramite FUN.

Per l’applicazione, e anche per chi disegna le schermate dinamiche, chiamare un servizio qualsiasi o un servizio interno è identico e trasparente.

Perchè questa architettura può evolvere e può sopravvivere?

Dato che la logica applicativa dell’applicazione sta quasi completamente nel DSL, pure la struttura delle pagine e la navigazione, questo ci consente, nel futuro, per necessità o per scelta, di cambiare tutto lo stack tecnologico, senza perdere la logica applicativa.
Sapete bene che al giorno d’oggi la tecnologia evolve molto velocemente, ancora di più, quella che ha che fare con l’interfaccia ed il frontend. Anche gli strumenti che usiamo oggi nessuno può dire se verranno usati anche nei prossimi anni.

In questo caso quando c’è necessità di cambiamento tecnologico, tutta la logica applicativa non viene persa.
Allo stesso modo potremmo volere rendere fruibile la nostra applicazione in modi nuovi, su “canali” nuovi che magari adesso nemmeno ci immaginiamo.
Logica applicativa, dati e servizi rimangono e non cambio.


Inoltre, tramite questa architettura, è possibile realizzare applicazioni utilizzando diverse combinazioni di quanto descritto sopra.
Ad esempio applicazioni che siano:

  • offline con schermate create dinamicamente, tramite dei json caricati localmente sincronizzati con il backend.
  • online statiche, in cui tutte pagine sono statiche, ma tutti i dati sono presi direttamente dal backend online.
  • miste.. il limite è solo la fantasia.


Si possono pensare anche ad alcuni casi “limite”. Ad esempio applicazioni offline con sole schermate statiche (è il caso di diverse applicazioni mobile) oppure applicazioni online totalmente dinamiche (in questo caso si pensi ai “social”).

Conclusioni

Per “auto-dimostrarci” la bontà di questo approccio abbiamo realizzato due frontend.


Una app mobile e una single page application in cui, seguendo l’architettura che vi ho proposto, è possibile avere navigazione e schermate definite in modo statico o in modo dinamico tramite un DSL.

E’ possibile gestire dati online e offline e tenerli sincronizzati.

E soprattutto interfacciare qualsiasi backend tramite i servizi interni specifici.
Tutto questo in modo trasparente

Direi la migliore invenzione dopo il “flusso canalizzatore” (cit.) 😀

Per vedere la registrazione dello speech di questo intervento, CLICCA QUI.