ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 84
Abonament PDF

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:

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:

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:

  1. Primul request făcut de browser este procesat și servit de server.

  2. Codul HTML procesat ajunge pe browserul clientului și este afișat.

  3. Urmează partea de hidratare, prin care se reinițializează elementele HTML afișate, utilizând același cod care a fost executat pe server.

  4. Navigările ulterioare între pagini sunt executate și procesate doar pe partea de client.

  5. 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:

  1. Maturitatea soluției;

  2. Calitatea și complexitatea documentației;

  3. Mărimea comunității;

  4. Numărul de componente disponibile în ecosistem;

  5. Performanța;

  6. Licența de folosire;

  7. Capabilitate procesare pe server (server-side rendering);

  8. Capabilitatea de a fi o aplicație izomorfă;

  9. Curba de învățare;

  10. 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:

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ă:

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:

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.

LANSAREA NUMĂRULUI 85

Prezentări articole și
Panel: Leadership & Management

Marți, 16 Iulie, ora 18:00
Charlie Upstairs, Cluj-Napoca

Înregistrează-te

Facebook Meetup

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects