Văzusem recent un topic, tot aici, a unui băiat care voia să facă o clonă a YouTube cu React și posta acolo ce a învățat el ziua respectivă și mi s-a părut interesantă ideea și de aici și ideea acestui topic.
Țin să-mi cer scuze dacă nu e la categoria corectă.
Eu astăzi am învățat cum să fac deploy la o aplicație django pe Raspberry Pi.
Astazi si in urmatoarea perioada o sa invat backend / nodejs / express / graphql
Ce coincidența, eu tot la graphql sunt acum, încerc să deslușesc cum se conectează la baza de date. Tot oscilez între apollo-server si express + graphql + join-monster.
Eu, incercand sa rezolv o problema de performanta/scalabilitate, la un backend Node.js cu PostgreSQL, am invatat sa interpretez mai bine metricele legate de Node Garbage Collection, de Event Loop Latency/Usage.
In cazul de fata, este vorba de Heroku care iti ofera la dispozitie aceste metrice specife Node-ului.
Am ajuns sa citesc despre:
si
Cat si despre alte informatii specifice plateformei Heroku ce tin de scalabilitate.
Ieri am invatat cat de utila poate fi comanda ab - Apache HTTP benchmark Tool , pentru debugging si scalability.
Exemplu:
Cum poti sa-ti dai seama daca anume DB-ul este bottleneck-ul de performanta.
Si mai exact, am facut asta ruland acelasi query in regim normal si in in conditii de stress/load testing cu tool-ul ab, masurand response time-ul la DB pentru acel query. Daca exista o diferenta in timpii de raspuns, atunci inseamna ca DB-ul este un bottleneck.
Am de gand sa public un articol pe medium, cat de curand, ca si case study.
@GarryOne m-am lovit si eu de acel lucru cand am avut un memory leak in aplicatie. Era cauzat de o lista care tot se umplea cu alarmele create de aplicatie. 
Am invatat sa intreb si utilizatorii aplicatiei cum o folosesc si de acolo s-a aprins beculetul.
Si ca sa raspund la intrebare si nu neaparat invatate azi sau ieri 
Pe partea tehnica:
?. si ??
@Query
Pe partea non-tehnica:
Scuze de offtopic, dar “why is this still a thing in 2021”
Da….Inca este
de orm, de mai multe
Foarte probabil pt ca java. E mai simplu sa alegi un limbaj ineficient si sa cârpești apoi, doar asa poti prinde contract de mentenanta si sa tot mulgi bani. De ce sa asculti de uncle Bob si sa chiar faci o treaba eficienta de la inceput pe care sa o mentii.
Putin web scraping pe imdb folosind node.js.
Am facut mic script cu care experimentez:
-scriu filmele intr-un file .json (9999 de filme din orice categorie si acest numar din cauza ca pagina URL-ul se modifica la filmul cu nr 10000, cred ca este criptat numarul habar n-am dar am sa dau de cap)
-folosesc cheerio, request-promise, axios.
-o functie cu care pot sa descarc posterele local.
-un mic regex pentru a ediat url-ul
Q: Cat de mare poate sa fie un fisier .json?
Prin absurd sa zicem ca vreau sa scriu 412,820 de obiecte json (unde am title, description, imageUrl etc.) intr-o fila .json. Credeti ca este potrivit? Cum pot de exemplu sa adaug atata informatie? Ma gandesc ca pot sa si dupa split pe mai multe file-uri json si fiecare sa aiba end point diferit.
Cum se abordeaza problema atunci cand lucrezi cu un volum mare de informatie.
Cât permite file-system-ul. La ntfs e 256TB.
Problemele apar însă la citire.
La câțiva (zeci?) MB nu cred că ar trebui să-ți faci probleme prea mari, mai ales dacă e doar pentru teste.
Nu cred că e idee prea bună să folosești JSON pentru stocare de date, pentru că atunci când vei avea nevoie de UN SINGUR obiect din el va trebuie să încarci în memorie TOT json-ul (ceea ce înseamnă consum de RAM și CPU). Mai degrabă stochezi datele in db și generezi json-ul on-the-fly atunci când/dacă ai nevoie de el.
Mai în topic, azi am învățat cum să rulez aplicații nodejs în container (podman) și să înțeleg cum funcționează pod-urile. Cred că fără să vreau ajung incet-incet la kubernetes
LE Și m-am lovit de o problemă (aparent) bizară din lumea containerelor. Mapez în containerul root-less un folder oarecare și îi dau drepturi de scriere containerului (podman unshare chown blabla:blabla /un/director/oarecare). Aplicația din container scrie un fișier în acel volum și ghici ce, userul care a instanțiat containerul nu are drepturi de citire pe acel fișier. Logica e că acel fișier a fost creat cu un alt user-id decât cel al “instanțiatorului”.
Exista optiunea sa ai fiecare obiect pe o linie in format json si asa e mai simplu de procesat ca nu trebuie sa incarci tot tree-ul deodata, vezi mai multe informatii aici:
Despre LoadBalancer, High Availability si Failover.
Cea mai simpla diagrama de arhitectura pentru LoadBalancing arata cam asa:
Prin urmare, tot timpul am avut senzatia ca acea componenta de LoadBalancer e, de fapt, un server separat, care trebuie sa aiba un IP separat. Altfel, cum ar sti clientul catre ce IP sa trimita request-urile ?
Intrebarea care tot imi venea si nu-i gaseam raspuns: “Ce se intampla daca serverul de LoadBalancing cade, respectiv IP-ul 10.10.10.10 devine indisponibil?”
Abia azi avea sa aflu despre notiunea de Virtual IP / Floating IP. Totodata sa aflu ca acea componenta de LoadBalancer nu exista ca si un server separat, care sa aiba un IP separat.
De fapt, diagrama arata in felul urmator, din punctul de vedere al node-urilor:
Ca mai multe node-uri sa aiba acelasi (Virtual / Floating) IP, se datoreaza protocolului VRRP (Virtual Router Redundancy Protocol)
De fapt, doar un singur node poate avea asignat acel Virtual IP, la un moment X. Restul node-urile doar au predispozitia de a primi acel IP, in mod automat, in caz ca node-ul principal cade. Acest proces se numeste failover si de el este responsabil utilitarul keepalived.
Cum afla restul node-urile cand un node a cazut? Dandu-si ping-uri, in mod constant, unul altuia, iar cand unul nu mai raspunde, e clara treaba.
Pana la etapa aceasta, folosind keepalived (bazat pe protocolul de VRRP) obtinem doar partea de High Availability.. Asta presupune strict faptul ca ori cate ori am sa trimit un TCP packet catre un IP, cineva o sa-mi raspunda (chiar daca pot fi servere diferite, care fac asta).
Mai departe, intra notiunea de LoadBalancer care se configureaza peste keepalived.
LoadBalancer-ul va fi prezent, la fel ca si keepalived, pe toate node-urile. Aplicatia de LoadBalancer, va culege de pe fiecare node pe care este instalat, informatii legat de load-ul (RARM/CPU usage) acelui node si i le va comunica restul node-urilor.
In functie de strategia de LoadBalancing aleasa in configuratie (roundrobin fiind cea mai populara, care presupune distribuirea in mod egal a load-ului) se vor distribui request-urile.
Chiar daca instantele de LoadBalancer sunt pe o linie orizontala, exista totusi, un elected leader, adica un master. In cazul in care master node-ul cade, atunci clusterul stie sa-si aleaga un nou leader, care va fi responsabil de distribuire request-urilor.
Un tutorial bun, care imbina toate aceste concepte la un loc, este acesta:
JSON, ca si XML si o gramada de alte formate, poate fi parsat pas cu pas, nu trebuie incarcat tot in memorie.
Bun, și când ai nevoie să accesezi al milionulea obiect din xml/json cum faci?
Sau dacă este totul pe o singură linie. Sau, și mai bine, dacă este cumva intercalat, câteva obiecte sunt one-linere, alte sunt lăbărțate și tot așa 
Cred că doar la formatul csv ai luxul de a parasa rând cu rând.
Exista si versiune de Json pentru streaming cu una din variante “Line-delimited JSON” , exact pentru parsare partiala.
Token cu token folosind memorie minima pana ajungi la al milionulea element (gen un counter la al catelea element esti).
Cand ai ajuns la pozitia dorita, ceri deserializare obisnuita incepand strict din acea pozitie.
