Cum schimbi frameworkul de front-end

Alex Cioflica
Principal UI Developer @ Paddy Power Betfair

Tiberiu Krisboi
Fullstack Developer @ Paddy Power Betfair

Cristian Bote
Principal UI Developer @ Paddy Power Betfair

PROGRAMARE

Anul trecut, în jurul acestei perioade, sărbătoream îndeplinirea unui obiectiv major: lansarea unei platforme moderne de site-uri, construită pe un set nou de tehnologii. A fost o provocare mare pentru toate echipele implicate. În articolul de față vom detalia cum a fost ales framework-ul în care a fost implementată platforma.

Facem parte din echipele de Gaming, care dezvoltă mai multe produse (Casino, Vegas, Arcade, Games, etc.), pe două branduri diferite (Betfair, Paddy Power); produse care funcționează, cu reguli specifice într-o multitudine de țări printre care în Marea Britanie și Irlanda, România, Italia și nu numai.

Înaintea relansării, produsele erau implementate într-o multitudine de soluții tehnice:

Exista o aplicație care servea versiunile de mobil ale produselor, procesarea se făcea pe server și era dezvoltată într-un framework intern bazat pe Java Spring, template-uri Freemarker și jQuery;
O altă aplicație folosea o soluție tehnică similară, dar care servea doar site-uri pentru desktop;
Exista o aplicație dezvoltată folosind Angular versiunea 1.6, procesarea fiind pe partea de client (client-side rendering);
În cele din urmă, o altă aplicație, de data aceasta dezvoltată prin intermediul Angular versiunea 4.

Numărul mare de aplicații aducea o complexitate ridicată. De exemplu, adăugarea de funcționalități noi la un produs era foarte costisitoare, din cauză că implementarea trebuia să fie făcută pe rând, în fiecare aplicație.

Totodată existau probleme în materie de SEO (optimizarea pentru motoarele de căutare). Informația afișată pe site-urile de mobile și de desktop era foarte similară, și a fost interpretată ca fiind conținut duplicat, ceea ce a dus la penalizarea site-urilor în rezultatele motoarelor de căutare, prin scăderea poziționării.

Totodată, unele frameworkuri folosite erau depășite tehnologic, fie pentru că s-a oprit oficial dezvoltarea lor (de exemplu Angular 1.6), fie aveau versiuni vechi și ar fi fost costisitor să fie aduse la zi.

În definitiv, era destul de dificil să se facă mentenanța și să se dezvolte în continuare aplicațiile. Concluzia a fost că va trebui o reconstrucție totală a produselor. Înainte de a începe, am enumerat câteva obiective principale:

Rapid și performant - Produsele trebuie să fie cele mai rapide din industrie.
Responsive - Designul site-urilor trebuiau să fie scalabile pe mobile și pe desktop.
Codul sursă trebuia să fie folosit pentru a servi mai multe branduri și produse, dar în același timp să ofere posibilitatea ca fiecare produs să aibă propria sa personalitate.
Optimizare pentru motoarele de căutare .
Ușor de extins și adăugat funcționalități noi.

Ce este o aplicație izomorfă?

Aveam experiență în dezvoltarea unei aplicații web utilizând Java Spring, în care o funcționalitate este scrisă într-un limbaj (Java) pentru a putea fi interpretată pe server, dar aceeași funcționalitate trebuia implementată în alt limbaj (JavaScript) pentru putea fi executată în browser. Totodată, aveam cunoștințe în a dezvolta o aplicație complet în tehnologii de frameworkuri de front-end, în care codul este executat doar pe partea de client, de browser. Dar la o astfel de soluție, aplicația depinde foarte mult de performanța dispozitivului clientului. De asemenea, pot apărea complicații pe partea de SEO.

Figură adaptată din Isomorphic JavaScript: The Future of Web Apps

Soluția hibridă este o aplicație izomorfă, unde același cod poate fi rulat atât pe server, cât și pe partea de client, facilitând mentenanța și dezvoltarea mai rapidă. Pașii de execuție ai unei soluții izomorfe:

Primul request făcut de browser este procesat și servit de server.
Codul HTML procesat ajunge pe browserul clientului și este afișat.
Urmează partea de hidratare, prin care se reinițializează elementele HTML afișate, utilizând același cod care a fost executat pe server.
Navigările ulterioare între pagini sunt executate și procesate doar pe partea de client.
Comunicările cu serverul fiind făcute prin API-uri rapide și cu răspunsuri mici și compacte. În acest fel, se salvează mult lățimea de bandă a utilizatorului și se îmbunătățește viteza de navigare.

Izomorfismul nu este un concept nou, a apărut în jur anului 2011 și a câștigat o mulțime de adepți în ultimii ani. Există multe librării sau soluții tehnice care vă pot ajuta. De asemenea, există multe articole cu un conținut de calitate din care vă puteți informa.

Un potențial dezavantaj este faptul că va trebui să fiți atenți unde va rula codul: unele funcții nu vor funcționa pe server, iar altele nu vor funcționa în browser. De exemplu, citirea dimensiunii unui element HTML ar trebui făcută pe partea clientului, deoarece pe server nu aveți noduri de DOM.

Studii de caz

Următoarea întrebare a fost: ce tehnologii vom folosi pentru următoarele aplicații? Există o abundență de variante, fiecare venind cu avantaje și dezavantaje. Dar pentru a putea fi obiectivi, am ales niște criterii de evaluare a frameworkurilor. Câteva dintre ele:

Maturitatea soluției;
Calitatea și complexitatea documentației;
Mărimea comunității;
Numărul de componente disponibile în ecosistem;
Performanța;
Licența de folosire;
Capabilitate procesare pe server (server-side rendering);
Capabilitatea de a fi o aplicație izomorfă;
Curba de învățare;
Etc.

Tabel comparativ al mai multor frameworkuri de front-end

Evaluând mai multe potențiale soluții, au rămas în lista scurtă: Angular, React, Preact și Vue.

Următorul pas a fost să luăm fiecare soluție în parte și să dezvoltăm un studiu de caz, astfel încât să putem compara mere cu mere. Am construit exact aceeași pagină web în fiecare framework și le-am analizat. Specificațiile au fost următoarele:

Pagina să fie responsive (aceeași pagină să poată fi afișată și pe dispozitivele mobile și pe cele desktop);
Să conțină multe imagini;
Să fie agregate date folosind microservicii;
Procesarea inițială să se facă pe server, nu pe client.

Rezultatul a fost măsurat în aceleași condiții: în browserul Chrome, cu simularea unei conexiuni 3G și emularea unui procesor de telefon mobil cu specificații de performanță medii. O importanță foarte mare a fost dată analizei performanței, incluzând numărul de painturi și repainturi, numărul de noduri de DOM, etc. O altă analiză amănunțită a fost a fișierelor JavaScript, pentru că:

Browserul nu procesează scripturi în paralel, ci doar le descarcă în paralel.
Numai un singur thread este utilizat pentru execuția scripturilor.
Scripturile pot fi procesate și executate, numai după ce sunt descărcate. Așadar, cu cât dimensiunea lor e mai mare, cu atât amânăm momentul când vor fi procesate și executate.
Interpretarea și executarea utilizează procesorul clientului, care poate fi o problemă pentru dispozitivele cu resurse mai reduse, cum ar fi dispozitivele mobile.

Rezultatele obținute au fost foarte de interesante. Aplicația bazată pe Angular a avut dimensiunea cea mai mare și a fost cea mai lentă din punctul de vedere al evaluării și execuției. Cea bazată pe React avea metricile aproape la jumătate, iar cea bazată pe Preact a fost cea mai mică și ,,zbura" din punctul de vedere al vitezei.

Preact a fost librăria câștigătoare pentru noi. Este o un framework rapid, mic (doar 3kB), open-source și este compatibil cu React. Astfel, beneficiezi de multitudinea articolelor, forumurilor unei comunități mari și active. Mai mult, este ușor de învățat să dezvolți în Preact. Există din ce în ce mai multe companii care utilizează acest framework, printre care Uber, Pepsi, Lyft, NY Times, etc. Conform analizelor este una dintre cele mai rapide soluții care folosește vDOM-ul.

Zilele acestea se pregătește lansarea versiunii noi, Preact X, care va aduce multe îmbunătățiri din perspectiva performanței, dar și a dimensiunii.

După alegerea frameworkului, am început implementarea. Au fost multe provocări pe parcurs, dar toate produsele au fost lansate în producție.

Iar rezultatele au fost foarte bune, cu o acoperire a tuturor cerințelor:

O suită de produse rapide și performante;
Site-uri responsive / adaptive;
Îmbunătățiri mari din perspectiva de SEO;
Mai multe produse servite de același cod sursă.

De la lansarea de anul trecut, platforma a fost o fundație pe care am dezvoltat noi funcționalități, noi produse. În același timp, am reușit să o îmbunătățim și să o facem și mai performantă.

După un an de zile, putem confirma că pentru noi se potrivește foarte bine soluția aleasă. Totodată veți găsiți o multitudine de articole online sau în TSM despre experiențele altor companii în alegerea unui framework. Dar un lucru este clar: analizați toate variantele și testați-le înainte să alegeți cum vă veți implementa aplicațiile. Este un pas esențial în procesul de dezvoltare, peste care nu ar trebui să săriți.

Puteți citi mai multe articole despre experiențele noastre sau alte subiecte tehnice pe blogul nostru.