Când co-fondatorul și colegul nostru de inginerie Dmitriy Zaporozhets a decis să construiască GitLab, a ales să o facă cu Ruby on Rails, în ciuda faptului că lucra în principal în PHP la acea vreme. GitHub, o sursă de inspirație pentru GitLab, se baza, de asemenea, pe Rails, făcându-l o alegere logică având în vedere interesul său pentru acest framework. Directorul executiv al GitLab, Sid Sijbrandij, crede că cofondatorul său a făcut o alegere bună:
„A funcționat foarte bine pentru că ecosistemul Ruby on Rails îți permite să modelezi o mulțime de funcționalități la o calitate ridicată”, a explicat el. „Dacă vă uitați la GitLab, acesta are o cantitate enormă de funcționalitate. Dezvoltarea de software este foarte complexă și, pentru a ne ajuta în acest sens, avem nevoie de o mulțime de funcționalități, iar Ruby on Rails este o modalitate de a face acest lucru. Pentru că există toate aceste bune practici care se află pe calea ta fericită, este, de asemenea, o modalitate de a păstra consecvența codului atunci când livrezi ceva precum GitLab. Ești într-un fel ghidat să faci ceea ce trebuie.”
Depinde de gemuri utile
Gemele Ruby joacă un rol esențial în construirea GitLab, acesta încărcând mai mult de o mie de gemuri neunitare, potrivit lui Sid. Calificând cadrul Ruby on Rails ca fiind „foarte avizat”, el crede că este un mediu puternic în care se poate construi o aplicație complexă precum GitLab.
„Există un ecosistem grozav în jurul său, cu pietre prețioase care pot face presupuneri cu privire la modul în care faci lucrurile și, în această privință, cred că ecosistemul Ruby on Rails este încă fără egal”, spune el. „Dacă vă uitați la Gemfile-ul nostru, acesta vă dă o indicație despre cât de mare este turnul de dependențe pe care putem construi. Ruby on Rails are niște umeri uimitori pe care să se sprijine și ar fi fost mult mai lent să dezvoltăm GitLab în orice alt framework.”
Depășirea provocărilor
Toate acestea nu înseamnă că nu au existat provocări în construirea GitLab cu Ruby on Rails. Performanța a fost o problemă pe care dezvoltatorii noștri au făcut eforturi pentru a o îmbunătăți în mai multe moduri, inclusiv prin rescrierea codului în Go și utilizarea cadrului Vue. Acesta din urmă este folosit pentru a rescrie paginile accesate frecvent, cum ar fi solicitările de probleme și de fuziune, astfel încât acestea să se încarce mai repede, îmbunătățind experiența utilizatorului.
Go este folosit pentru a rezolva alte probleme care afectează timpii de încărcare și pentru a reduce utilizarea memoriei.
„Ruby a fost optimizat pentru dezvoltator, nu pentru a fi rulat în producție”, spune Sid. „Pentru lucrurile care sunt lovite foarte mult și care trebuie să fie foarte performante sau care, de exemplu, trebuie să aștepte foarte mult timp la un IO de sistem, le rescriem în Go … Încercăm în continuare să facem GitLab să folosească mai puțină memorie. Așadar, va trebui să activăm multithreading-ul. Când am dezvoltat GitLab, acest lucru nu era obișnuit în ecosistemul Ruby on Rails. Acum este mai comun, dar pentru că acum avem atât de mult cod și atât de multe dependențe, va fi o cale mai lungă pentru noi să ajungem acolo. Asta ar trebui să ne ajute; nu va fi fulminant de rapid, dar cel puțin va folosi mai puțină memorie.”
Aducerea Go în setul de instrumente GitLab a dus la crearea unui serviciu separat numit Gitaly, care se ocupă de toate solicitările Git.
Building on GitLab’s mission
Stilul organizat, structurat al cadrului Ruby on Rails se potrivește cu misiunea noastră de bază. Deoarece Rails este simplificat, oricine poate sări în GitLab și participa, ceea ce l-a făcut deosebit de atractiv pentru Sid încă de la început.
„Misiunea noastră este ca toată lumea să poată contribui”, explică el. „Deoarece Ruby on Rails este cu adevărat opinat cu privire la ce piese merg unde, este mult mai ușor pentru noii dezvoltatori să intre în baza de cod, pentru că știi unde au pus oamenii lucrurile. De exemplu, în fiecare bucătărie în care intri, nu știi niciodată unde sunt amplasate cuțitele și farfuriile. Dar cu Ruby on Rails, intri în bucătărie și este întotdeauna în același loc, iar noi vrem să rămânem la acest lucru.
În orice bucătărie în care intri, nu știi niciodată unde se află cuțitele și farfuriile. Dar cu Ruby on Rails, intri în bucătărie și este întotdeauna în același loc, iar noi vrem să rămânem la asta.
„Am fost foarte încurajat când am deschis proiectul și l-am văzut pentru prima dată la un an după ce Dmitriy l-a început. L-am deschis și este un Rails idiomatic. A urmat toate principiile. Nu a încercat să experimenteze cu un fel de modă care îl interesa. A transformat-o într-o aplicație de producție. Dmitriy a verificat cu atenție toate contribuțiile pentru a se asigura că respectă aceste convenții, iar acest lucru este încă valabil. Cred că avem o bază de cod foarte bună care permite altor oameni să construiască pe ea. Una dintre subvalorile noastre este soluțiile plictisitoare: nu faceți nimic extravagant. Asta pentru ca alții să poată construi pe ea. Cred că am făcut asta foarte bine… și suntem foarte recunoscători că Ruby a fost un ecosistem atât de stabil, pe care am putut să construim.”
Imaginea de copertă de Elvir K pe Unsplash
Lasă un răspuns