Prefață

Zilele astea am avut tot felul de conversații cu oameni dragi mie. Azi dimineață mi-am amintit ce simțeam acum trei ani despre cloud. Simțeam că e greu, că urmează să invăț (iar?!?) lucruri pe care unii și alții le-au inventat doar că să mai am eu ceva de priceput. M-am înșelat destul de tare, pentru că nu mi-a fost greu. Poate ție nu-ți este la fel de ușor să înveți, dar asta e altă discuție (să înveți să înveți e despre mentorat și scopul principal al unui om în devenire).

Ca să poți urmări unde bat, citește interviul ăsta cu Ryan. Care Ryan? Ăla de-a scris NodeJS. Ăla de a scris pe urmă Deno, ca o alternativă de secol 21 a lui NodeJS.

Părerile lui Ryan

La un moment dat, zice una profundă, la care - recunosc - nu m-am gândit s-o spun așa: „Scripting languages are good for beginners.”. N-am spus-o așa, probabil din prea mult respect pentru ceilalți. Simt organic că așa este. Dacă nu ți s-a terminat RAM-ul în fața ochilor niciodată, dacă nu te-a întrebat nimeni într-un interviu cum faci reverse la un string mare de două ori cât RAM-ul mașinii pe care lucrezi, atunci ești junior. Stai liniștit, dacă ești pasionat, o să cauți să migrezi singur. Departe de scripting.

A doua spusă a lui Ryan este despre Go. Evanghelistul din mine nu se poate abține să nu spună: „băi, dacă pe mine nu mă credeți, credeți-l pe Ryan, că doar el a scris NodeJs și Deno!”. Zice așa : „Goroutines are wonderfully simple to use and achieve peak performance. Node and Deno are, like Go, built on non-blocking I/O and OS event notification systems (epoll, kqueue). JavaScript is inherently a single threaded system, so a single instance of Node or Deno generally cannot take advantage of all the CPU cores on a system without starting creating new instances. Node/Deno are optimal for JavaScript, but Go is ultimately a better choice for high concurrency systems in the absence of other requirements that might lean preference towards JS.” Pentru ăia care tot insistă că NodeJS e multi-threaded, sper că ne-am lămurit, da? Omul care a scris Node îți spune clar care-i treaba și gata. Considerând că ne-am înțeles până aici, să vedem de ce.

Adevăratele motive pentru dezvoltarea de aplicații în NodeJS

Deși nu se spune explicit, adevăratele motive derivă din existența forței de muncă. E clar că un developer de Java e mult mai scump. La fel de clar (mie îmi e clar) e că termenul full stack developer a fost inventat de oameni care au înțeles că e mai ieftin să pui un frontend (developer) să scrie și backend-ul. Pe urmă e vorba de raritate: piața forței de muncă în IT este în criză. Și va mai fi (30% deficit până în 2024)! Angajatorii gândesc că este puțin probabil să găsească rapid programatori calificați în limbaje precum Go. De observat aici că foarte puțini angajatori se gândesc la conversie. Și extrem de puțini dezvoltatori sunt dispuși la conversie. Adică, de ce-ar face angajatorul investiția asta, în care să-ți permită ție să înveți alt limbaj, eventual unul care să te crească. Iar tu - care ai învățat atâtea hackuri în JavaScript - de ce-ai fi dispus să renunți la cunoștințele dobândite. Cum care hack-uri? Ăstea de aici!

De ce Asia a ales Go? Îmi pun întrebarea asta de mult timp, dar acum avem și cifrele o confirmă! Bănuiala mea - cu titlu de convingere - este că Go livrează. Adică, or fi încercat bieții oameni și cu PHP. Și cu NodeJS. N-a mers: sunt atât de mulți vizitatori ai site-urilor lor, încât le trebuia ceva care să livreze. Altfel, devenea prea scump. Alegerea lor s-a bazat pe motive economice (doh!?), întărind - parcă - proverbul „the right tool for the right job”.

Ce am împotrivă

Păi… mind-set-ul. Când scrii cod pentru browser, devii domnul Singleton. Nu-ți apar probleme de sharding. Nu te pasionează concepte de cloud, pentru că nu-ți folosesc la nimic. Nu e o problemă, atât timp cât continui să scrii pentru browser. Chiar dacă devin sâcâitor, mai zic odată : n-ai să măsori RAM-ul consumat, decât dacă ți se cere explicit asta.

Problemele apar când vii și scrii partea de backend. Folosind același limbaj, dar mai ales același mind-set.

Să dezvolt:

Database migration

E un pattern care l-am văzut și în Go. S-apucă omul, cu mare zel, să-și migreze baza de date dintr-un serviciu. Pentru el, în mintea lui, totul e ok. Pentru mine nu e. Scriem servicii pentru cloud, în general pentru Kubernetes. Dacă nu înțelegi diferența între serviciu și pod, ai o problemă: mind-set-ul de Singleton. Care va să zică, ce se întâmplă când două sau mai multe pod-uri rulează aceeași migrare? N-am încercat, dar nici nu mă pasionează să încerc. Pentru că e o prostie. Ăștia o numesc accidental complexity, fiindcă dacă nu merge, va trebui să scrii cod, să scrii un hack s-o faci să meargă. În loc să gândești pentru cloud de la bun început.

Reutilizarea clienților HTTP

Asta e generalizată, în sensul că nu contează limbajul. Pornește aplicația, îți faci frumos un client HTTP către alt servicii, te conectezi și baftă. Nu ai idee cât de greu este să faci debug pe probleme apărute din motivul că Kubernetes îți stinge frumușel pod-uri și servicii cu varii motive. Și clientul tău a rezolvat DNS-ul. Și ești conectat cu un serviciu care nu mai este la IP-ul pe care serviciul tău l-a obținut când s-a rezolvat DNS-ul. Iar probleme (de data asta mari de tot), iar hack-uri. Again, în loc să gândești pentru cloud de la bun început.

Event bus. Event who?

Da, event bus. Event bus e ăla de-l fac ăștia prin Vue 2, ca să fie reactivi care React-ul. Nu mă pricep eu la chestii din ăstea, dar nu înțeleg de ce nu folosești un event bus în aplicațiile tale de NodeJS care rulează în cloud. Nu pricep și basta. Ți-e frică, fiindcă nu seamănă cu ce știi? Ți-e lene să citești ce e ăla un dead letter queue?

Sunt convins că drumul spre event bus e presărat cu pattern-uri cumplit de grele cum este Command Query Responsibility Segregation. Îți promit că te ajută să ții lucrurile sub control, chiar dacă tu ai ales calea scripting-ului pentru backend.

Dacă cumva folosești event bus, vezi să nu-l folosești pe post de măciucă. Spun asta, pentru că am văzut și asta: aplicația ta consumă mai puțin decât măciuca poate produce. Și-ajungi să ai retenție de mesaje, de nu-ți vine să mai pornești consumatorii.

O paranteză despre Vue

De câteva săptămâni, de acum, mă căznesc să scriu una bucățică aplicație cu Vue 3. Guess what? Nu am curaj pentru că nu găsesc destule „experimente” pentru așa o schimbare de paradigmă. Diferența majoră între Vue 2 și 3 constă în compoziție și reactivitate. De asta, nu mă arunc cu capul înainte, aducând mind-set-ul de Vue 2 în cel de Vue 3. Vreau să învăț bine ceea ce voi învăța, așa că la fiecare pas, mă gândesc la pericolele poluării cu concepte care nu mai sunt necesare.

Lambda function

Mi-amintesc de un client care vroia să facă login cu lambda function. Și care m-a enervat teribil, pentru că mi-a cheltuit timpul fix aiurea. Nu avea nevoie de mine, de expertiza mea. Știa mai bine decât mine, ce poate și cu ce se mănâncă lambda.

Și lambda te poate ajuta, dar nu să faci login, fiindcă login-ul e ușor sincron. Lambda te ajută pe probleme asincrone. Cum ar fi să generezi un PDF, un raport sau whatever. Cum ar fi să faci audit (who did what), dacă aplicația ta nu e write intensive. Condiția e să te gândești la sincronicitate și la cât de des e folosit feature-ul respectiv. Dacă e „destul” de rar și nu stă nimeni după el, atunci, e lambda.

Concluzie

Îți recomand în primul rând să gândești. Gândește-te bine ce faci, fiindcă nu rulezi în browser. Sparge problema în bucăți mici. Fă-le microservicii (ai grijă să nu confuzi cu module, fiindcă nu-s tot aia).

În al doilea rând, învață Docker, Kubernetes, soluțiile de cloud existente (event bus, dead letter queue, metrics, etc). Cu cât le înțelegi mai bine, cu atât te-ajută mai mult să-ți structurezi aplicația, fără riscuri (cum e cel de reutilizare a clienților HTTP).

În al treilea rând, pune-ți problema conversiei. Sunt ferm convins că deși pare mult și greu, nimic nu e imposibil pentru tine: doar ai supraviețuit atât de mult timp scriind într-un limbaj pe care nimeni nu-l știe, numit JavaScript.

Dacă am părut condescendent, e din cauză că sunt. Motivul e simplu: tu scrii NodeJS în felul descris mai sus, iar eu stau să fac debug în cloud după tine. N-ai empatie, atunci eu îmi permit condescendența.

Să ai o zi faină!