Dietro le quinte
Lego e iPhone: le ricerche più frequenti della clientela
di Manuel Wenk
Team Isotopes: i demoni della velocità dell'ingegneria
7.5.2018
Traduzione: tradotto automaticamente
Immagini: Thomas Kunz
Quando si parla di velocità, il team di ingegneri di Isotopes opera in un campo di tensione tra uomo, macchina e futuro. Ci offrono una panoramica del loro lavoro.
Damian Frizzi siede sui blocchi di cemento riscaldati dal sole di fronte agli uffici della Digitec. Occhiali da sole, maglietta grigia. Sembra rilassato, parla lentamente, scherza di tanto in tanto, divaga dall'argomento. Il suo argomento sono i millisecondi, la tecnologia e un po' di oratoria.
Damian è il responsabile del Frontend Engineering e un membro del team chiamato "Isotopes", dal nome della squadra di baseball della fittizia Springfield de "I Simpson". Lui e il suo team di otto ingegneri lavorano ogni giorno per rendere il negozio ancora più veloce. Non cercano l'unica cosa che elimini ritardi di dieci secondi, ma di millisecondi. Se un processo non è stato snellito in modo da non sprecare nemmeno un millisecondo di tempo di calcolo, allora i conti tornano su digitec.ch.
L'Isotopes è un'azienda che si occupa di produzione di energia.
Gli Isotopi stanno attualmente lavorando a un progetto mastodontico: vogliono riorganizzare l'intero negozio.
Uno sguardo alla storia: Come funzionavano i negozi di una volta
"Ai tempi della preistoria del Web 1.0, i siti web funzionavano in modo diverso da oggi", dice Damian con un sorriso malizioso sul volto. Perché all'epoca, verso la fine degli anni '90, quest'epoca si è conclusa. Preistoria? Niente affatto. Ma ancora molto lontana. I nati nel 1999 possono fare l'esame di guida dall'anno scorso. Il 1999 ha visto anche il primo utilizzo del termine "Web 2.0".
Le pagine web di allora funzionano così: Tu invii una richiesta a un sito web, il server calcola, il server ti rimanda una pagina completa. Poi clicchi su un link, il server ricalcola nuovamente la pagina e ti invia un'altra pagina completa. Ciò significa che ogni volta che clicchi su un sito web, viene caricata una nuova pagina. Questo processo è chiamato ricarica della pagina o rendering lato server (SSR) e può comportare l'invio all'utente di dati già richiesti. Questo comporta tempi di caricamento più lunghi durante la navigazione del sito web.
Troppo lento per l'utente e troppo lento per gli isotopi.
Questo cosiddetto rendering lato server è stato il modo migliore per implementare i siti web per molto tempo, dato che JavaScript non era ancora così avanzato come lo è oggi. All'inizio del Web 2.0, tuttavia, JavaScript, il cui scopo è quello di migliorare la dinamica dei siti web, non consentiva molto di più che slideshow di immagini o widget di selezione della data.
Con il passare degli anni, lo sviluppo di siti web e visualizzazioni sempre più potenti ha portato il web tradizionale ai suoi limiti. Oggi i clienti si aspettano piattaforme applicative complete. Con runtime JavaScript veloci e standard HTML5 che visualizzano applicazioni ricche. In altre parole: tutto ciò a cui sei abituato con Internet. Perché JavaScript e HTML5 non sono più un lusso, ma i Basic.
"Quello è stato il momento in cui gli sviluppatori hanno cambiato obiettivo", afferma Damian. Sempre più potenza di calcolo si è spostata dal server al client, cioè al tuo computer. Le cosiddette applicazioni a pagina singola con rendering lato client consentono di interagire direttamente con il sito web senza dover passare per il server.
Damian inizia a spiegare: "Le applicazioni a pagina singola sono applicazioni che si basano su una struttura HTML minimale e ricaricano i dati - personalizzati in base all'utente e al suo ambiente - in modo asincrono nel browser."
Si tratta di applicazioni a pagina singola.
Fin qui tutto bene, ma è qui che inizia il lavoro degli isotopi. Anche il trasferimento asincrono dei dati, sebbene più veloce del rendering continuo sul lato server, comporta ostacoli, sfide e idiosincrasie. Damian cita il Google Crawler, un piccolo programma che scruta il web alla ricerca di nuovi contenuti. Può elaborare i siti lato client solo in misura limitata. La raccomandazione ufficiale di Google è di visualizzare il contenuto rilevante della pagina direttamente e di non ricaricarla. In caso contrario, c'è il rischio di declassare la rilevanza e la pagina apparirà più in basso nei risultati di ricerca.
Anche le prestazioni iniziali sono fondamentali. Poiché l'intero Document Object Model (DOM), l'architettura di un sito, è costruito sul client, è necessario un certo tempo perché i dati vengano richiesti, elaborati e resi sul server.
"Questo può comportare lunghi tempi di caricamento, soprattutto per i clienti con scarsa potenza di calcolo, ad esempio i vecchi smartphone, o con una connessione internet scadente", spiega Damian.
Ciò si traduce in tempi di caricamento quasi infiniti.
Questo si traduce in animazioni di caricamento quasi infinite quando la pagina viene caricata per la prima volta.
Il percorso isotopico
Gli isotopi operano in quest'area di tensione tra le esigenze dell'utente - cioè le tue esigenze - e quelle della tecnologia. Inoltre: Google. Il gigante dei motori di ricerca ha naturalmente voce in capitolo, che sia di gradimento o meno agli Isotopi.
"Vogliamo un mix tra le esigenze degli utenti - cioè le tue - e quelle della tecnologia.
"Vogliamo un misto tra il nuovo approccio e quello tradizionale: vogliamo che il server restituisca un documento HTML completo con la richiesta iniziale, in modo che il tempo di caricamento rimanga il più breve possibile e che Google e co. possano continuare a scansionare i nostri contenuti in modo completo", afferma Damian, facendo un rapido respiro. È nel suo elemento, parla velocemente e inspira meno. "Ma vogliamo anche beneficiare dell'aumento delle prestazioni di una SPA durante la navigazione all'interno della nostra applicazione".
Gli Isotopi si sono seduti e hanno sperimentato applicazioni universalmente renderizzabili. In altre parole, sia che si tratti di un umano o di un crawler, la pagina ha senso e può essere letta, categorizzata e valutata da una macchina. A tal fine, la logica di visualizzazione deve funzionare perfettamente sia sul server che sul client. Questo ha i suoi vantaggi.
"Non solo ci risparmiamo il lavoro aggiuntivo che comporta lo sviluppo per un solo ambiente, ma possiamo anche controllare in modo specifico quali contenuti devono essere caricati e quando", spiega Damian.
Per raggiungere questo obiettivo, è necessario risolvere due problemi principali:
- Frontend universale isomorfo: Isotopes deve costruire un frontend che possa essere elaborato e renderizzato sia da un server che da un browser e distribuito nel cloud come unità indipendente
- Ricaricamento dei dati: Devi essere in grado di consumare, persistere temporaneamente e visualizzare i dati nel frontend da qualsiasi interfaccia indipendente
Dopo aver sperimentato e definito i requisiti, i desideri e i limiti, il team guidato da Damian Frizzi si è messo al lavoro. È tempo di reinventare un negozio web.
Front end universale
Gli Isotopi si buttano nella mischia. Il motore di rendering è presto detto: React, sviluppato da Facebook. Sia Facebook che Instagram utilizzano la libreria JavaScript e hanno ottime prestazioni. React, a volte chiamato anche React.JS o ReactJS, supporta il rendering sul lato client e sul lato server, ha una grande Community alle spalle ed è ampiamente accettato sia dagli esseri umani che dalle macchine. Risolve esattamente un problema: il rendering e quindi l'interazione con il DOM.
"Infine, ma non meno importante, React è molto efficiente. Con un DOM virtuale e patch mirate".
React è affiancato da Node.js sul lato server. Questo ha senso, dice Damian. Questo permette a Isotopes di programmare in JavaScript e di beneficiare delle competenze esistenti.
Ricaricamento dei dati
Le API, ovvero le interfacce di programma, sono la chiave del successo quando si ricaricano i dati. Gli isotopi che circondano Damian devono prima di tutto mettersi al passo con il presente.
"Stiamo convertendo tutte le interfacce in API web", dice. Riesce a malapena a reprimere un sospiro. Perché il passaggio non è semplice. Ci sono un gran numero di interfacce che devono essere richieste dal cliente. Per evitare che ogni utente debba inviare un numero enorme di richieste ai server di backend di digitec, abbiamo deciso di utilizzare un livello GraphQL tra il frontend e il backend.
I vantaggi sono evidenti: il client, cioè il computer dell'utente, deve richiedere solo un endpoint e gli sviluppatori del frontend non devono occuparsi di implementare le richieste di interfaccia. Il server GraphQL riduce i dati al minimo utilizzando query e risolutori di schemi. Ciò significa che tra il client e il server GraphQL vengono scambiati solo i dati effettivamente necessari. Questo è un vantaggio soprattutto in caso di connessioni internet lente. Damian guarda al futuro: "In seguito metteremo in cache i dati a livello di GraphQL", in modo da ridurre il numero di richieste alle interfacce e il cliente riceverà una risposta ancora più veloce.
Velocità.
Velocità. Gli isotopi li stanno cercando.
Damian riassume il nucleo dell'attuale stack tecnologico di digitec:
- JavaScript (ES2015, ES2016)
- Node.js
- React
- Next.js
- GraphQL
- Apollo
- Enzima
- Jest
- Docker
- Azure
- Kubernetes
- ASP.NET Web API
Il risultato è un prototipo, ed è qui che le cose si fanno interessanti.
Un'occhiata al prototipo
"Confuso? Nessun problema. Dai un'occhiata a questo prototipo", dice Damian. Il miglioramento delle prestazioni sarà evidente solo quando lo vedrai.
Damian è orgoglioso.
Damian è orgoglioso: "Ed è esattamente quello che fanno gli isotopi".
Il risultato del prototipo sarà presto online.
A proposito: il Team Isotopes vuole informarti che il nostro team di ingegneri sta cercando rinforzi. Se vuoi essere coinvolto, dai un'occhiata alle seguenti posizioni aperte:
- Junior Software Engineer
- Ingegnere software
- Ingegnere software senior
- Technical Lead / Cloud Architect
- Teamleader Software Engineering
Inoltre, ci sono altre posizioni di ingegneria qui.
Se vuoi saperne di più su come sviluppiamo, dai un'occhiata qui.
Giornalista. Autore. Hacker. Sono un contastorie e mi piace scovare segreti, tabù, limiti e documentare il mondo, scrivendo nero su bianco. Non perché sappia farlo, ma perché non so fare altro.
Informatica
Segui gli argomenti e ricevi gli aggiornamenti settimanali relativi ai tuoi interessi.
Tecnologia
Segui gli argomenti e ricevi gli aggiornamenti settimanali relativi ai tuoi interessi.
17 commenti
later