ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ 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.

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects