În urmă cu aproximativ un an, Nikita Prokopov a publicat un articol-manifest „Dezamăgirea software-ului”. Judecând după feedback-ul pozitiv, dezvoltatorii vor să aibă grijă de calitatea produselor pe care le produc. Este timpul să începem să acționăm, poate?

korolev

În această postare, vreau să vorbesc despre proiectul meu, care, în opinia mea, poate vindeca principalele probleme de performanță ale Web-ului modern și poate face utilizatorul un pic mai fericit. Iată-le - dimensiunea pachetelor JS, timp mare până la interactivitate, consum ridicat de RAM și CPU.

Înainte de a citi mai departe, urmați linkul. Încercați să jucați mai multe meciuri. Este de dorit să se joace de pe un desktop.

Un pic de istorie

La început, creatorii Web-ului au conceput browserul ca un client subțire pentru servere web. Browserul afișa pagini de hipertext primite de la un server. A fost simplu și elegant. Așa cum se întâmplă adesea, o idee frumoasă s-a confruntat cu realitatea și, după câțiva ani, producătorii de browsere au adăugat suport pentru un limbaj de scriptare. La început, era destinat doar decorării. Până la mijlocul primului deceniu, s-a considerat adecvat să se creeze site-uri web cu JS doar ca o opțiune.

Abordarea modernă a dezvoltării site-urilor web este rezultatul creșterii cerințelor de interactivitate a interfeței utilizatorului. Sarcinile de îmbunătățire a interactivității au căzut pe umerii proiectanților de șabloane. De multe ori nu au competența și autoritatea de a dezvolta o soluție „transversală”. Designerii de șabloane au învățat JS și au devenit ingineri front-end. Logica a început treptat să curgă de la server la client. Este convenabil ca tipul frontend să scrie totul pe partea clientului. Pentru tipul de backend, este convenabil să nu vă gândiți la utilizator. „Îți dau JSON și apoi nu-mi pasă” - spun ei. Acum doi ani, arhitectura fără server a devenit populară. Sugestia a fost că aplicațiile JS ar funcționa direct cu baza de date și cozile de mesaje.

Pentru moment, un site web obișnuit este o aplicație complexă scrisă în JS și un server API simplu. Logica principală se execută pe un client gros, iar partea server degenerează într-un proxy de bază de date.

Dacă o datorie tehnică din partea serverului nu poate afecta direct utilizatorul dvs., atunci din partea clientului va afecta. Dacă pornirea dvs. „decolează” și începe să câștige, atunci mai mult cu creșterea sarcinii, situația se va înrăutăți doar în ceea ce privește performanța. Cerințele se vor schimba. O bază de cod se va umfla și o rată de rotire într-o echipă va crește. Pagina se va îngrășa din dependențe. Site-ul va încărca JSON învechit. Sarcinile de fundal se vor înmulți în număr, fiecare dintre ele rulează câteva milisecunde în fiecare secundă, ceea ce după un timp va duce la decalaje și încălzirea iPad-ului unui utilizator nefericit, astfel încât el sau ea să poată prăji ouă pe el. Nimeni nu va îndrăzni să o remedieze din cauza fricii de a sparge sistemul. Se va termina cu tipii front-end arși care vin la manager cu o propunere de a renunța la vechiul cadru urât și a rescrie totul de la zero pe unul nou strălucitor. Managerul va refuza, iar tipii front-end vor începe să le folosească pe amândouă împreună.

Cum funcționează Korolev

Deci, dacă ne întoarcem la punctul de cotitură? În momentul în care cineva a venit cu ideea de a actualiza conținutul fără a reîncărca pagina, iar inevitabilitatea istorică a dat naștere AJAX? Ce se întâmplă dacă lăsăm totul pe server și facem un client subțire? Cele mai bune site-uri fac o redare prealabilă a paginilor de pe server, astfel încât un utilizator să poată vedea o interfață înainte de încărcarea JS. Putem merge mai departe și lăsăm doar codul pe client, care este responsabil pentru procesarea I/O, ținând cont de cerințele actuale de interactivitate. Gândurile despre acest lucru m-au condus la proiectul Korolev.

Cum funcționează acest lucru din punctul de vedere al clientului? Utilizatorul vine pe pagină. Un server trimite codul HTML generat și un mic script (aproximativ șase kB fără compresie), care se conectează la un server printr-o priză web. Când un utilizator face un eveniment (un clic, de exemplu), scriptul îl trimite la un server. Serverul procesează un eveniment generează și trimite o listă de comenzi precum „adăugați un nou

Ce se întâmplă pe un server? Când o cerere pentru o pagină vine de la un browser, Korolev creează o nouă sesiune. O stare inițială este făcută și stocată într-un cache. HTML se redă din această stare și a trimite unui client ca răspuns la cerere - de asemenea, serverul stochează „DOM virtual” în sesiune. După solicitarea paginii, serverul acceptă o cerere de deschidere a unui socket web. Korolev asociază socketul web deschis cu sesiunea. Fiecare eveniment care vine de la client poate modifica starea legată de sesiune (dar nu poate modifica direct DOM). Fiecare modificare de stare are ca rezultat un apel către funcția de redare, care creează un nou „DOM virtual” care se compară cu versiunea veche. Rezultatul comparației este o listă de comenzi de trimis clientului.

Ce se întâmplă într-un cod și în capul unui dezvoltator? Scris mai sus vă poate aminti de React, cu diferența că totul se întâmplă pe un server. Korolev are o abordare similară. Prin urmare, dacă ați lucrat cu React sau cu un alt „DOM virtual”, atunci stilul de lucru al lui Korolev vă va fi familiar. Dacă nu sunteți familiarizat cu React, imaginați-vă că aveți un model de date și un șablon mapate pe acesta. Managerii de evenimente schimbă datele, pagina se schimbă de la sine.

Performanţă

Există două întrebări populare despre Korolev: „ce se întâmplă dacă latența este mare” și „cum îmi încarcă serverul”. Ambele sunt foarte rezonabile.

Tipul de front-end obișnuia cu faptul că programul său rulează pe mașina locală a utilizatorului. Înseamnă că modificările aduse acestuia vor fi aplicate de îndată ce mașina JS termină executarea codului și browserul începe să redea. Am arătat în mod specific un exemplu la început. Dacă nu ați încetat să citiți, cred că ați avut o experiență bună. Mai ales dacă numărați, acel server găzduit la Moscova. Dacă locuiți în San Francisco, teoretic timpul minim dus-întors va fi de 62 ms. De asemenea, puteți citi raportul despre UX și limitele de timp de răspuns. Verificați latența medie a clientului pe orice site web. Dacă a fost mai mică de 100, latența este excelentă. Sper că am risipit îndoielile cu privire la posibilitatea decalajelor.

Băieții back-end pun de obicei întrebarea despre încărcarea pe server. Motorul care deduce modificările funcționează foarte repede:

10 mii de diferențe pe secundă pentru doi arbori arbitrari de 500 de noduri pe MacBook 2013. Redarea statică oferă, de asemenea, un rezultat destul de bun: până la 1 milion de pagini pe secundă. Fiecare „DOM virtual” este stocat și procesat într-o prezentare serializată specială și ocupă 128 KB dintr-o grămadă pentru pagina web medie. Procesul de redare este special optimizat și nu are memorie și GC overhead.

În ceea ce privește viteza de programare, aici Korolev oferă beneficii excelente. Nu este nevoie să scrieți un strat suplimentar între baza de date și server. Nu este nevoie să negociați un protocol între client și server. Nu este nevoie să vă faceți griji cu privire la dimensiunea pachetelor JS - greutatea JS pe client va rămâne întotdeauna aceeași. Nu este nevoie de muncă suplimentară pentru a sprijini evenimentele serverului: acceptați mesajul din coadă și modificați starea sesiunii, Korolev va reda și livra.

Costul

Dar avantajele au un cost. Ar trebui să rupi unele obiceiuri, iar unele noi trebuie să le dobândească. De exemplu, va trebui să părăsiți animațiile JS și să vă mulțumiți cu animațiile CSS. Va trebui să învățați cum să faceți infrastructura geodistribuită inițial dacă doriți să deserviți utilizatori din diferite țări cu o calitate înaltă. Va trebui să renunțați la JS și să treceți la Scala.

Mi-e puțin rușine (de fapt nu sunt) că am crezut cititorul și nu am spus imediat că Korolev a scris în Scala. Ați citi până la acest punct dacă v-aș spune mai sus despre asta? Vorbind despre Korolev, trebuie să depășesc două stereotipuri. Primul este legat de faptul că redarea serverului este percepută ca ceva lent, nu interactiv. Al doilea este despre Scala, este ceva complicat. Atât primul, cât și al doilea stereotip nu au nicio legătură cu realitatea.

Mai mult, programarea în stil React pe Scala este mai convenabilă decât pe JS. JS-ul modern tinde spre programare funcțională, iar Scala îl oferă din cutie. De exemplu, un obiect din Scala are o metodă copy (), care vă permite să copiați un obiect prin schimbarea unor câmpuri. Colecții imuabile incluse în biblioteca standard.

Concluzie

Korolev se dezvoltă de trei ani de la mai mulți colaboratori, iar multe probleme din stadiul incipient au fost deja rezolvate. Proiectul are documentație detaliată și exemple care acoperă toate funcționalitățile. Ofer să încep să folosesc Korolev pentru mici proiecte independente. Sper că Korolev va ajuta Web-ul să devină mai puțin frustrant.