Să spun o poveste tehnică.
Cu mulți ani în urmă, dezvoltam o aplicație cu caracteristici de colaborare încorporate în ea. A fost o stivă experimentală ușor de utilizat, care a profitat de întregul potențial al React și CouchDB timpurii. A sincronizat datele în timp real prin JSON . A fost folosit intern în cadrul companiei, dar aplicabilitatea sa largă și potențialul în alte domenii erau clare.
În timp ce încercam să vindem această tehnologie unor potențiali clienți, am întâlnit un obstacol neașteptat. În videoclipul demonstrativ, tehnologia noastră a arătat și a funcționat grozav, fără probleme acolo. Videoclipul a arătat exact cum funcționează și nu a imitat nimic. Am venit cu și am codificat un scenariu realist pentru utilizarea programului.
De fapt, aceasta a devenit problema. Demo-ul nostru a funcționat exact așa cum toți ceilalți și-au simulat aplicațiile. Mai exact, informațiile au fost transferate instantaneu de la A la B, chiar dacă erau fișiere media mari. După conectare, fiecare utilizator a văzut intrări noi. Folosind aplicația, diferiți utilizatori au putut lucra împreună clar la aceleași proiecte, chiar dacă conexiunea la Internet a fost întreruptă undeva în sat. Acest lucru este implicit implicit în orice produs video tăiat în After Effects.
Chiar dacă toată lumea știa pentru ce este butonul Reîmprospătare, nimeni nu a înțeles cu adevărat că aplicațiile web pe care ne-au cerut să le construim erau de obicei supuse propriilor limitări. Și că dacă nu mai sunt necesare, experiența utilizatorului va fi complet diferită. În cea mai mare parte, au observat că puteau „să converseze” lăsând note pentru persoanele cu care vorbeau, așa că s-au întrebat în ce fel era diferit de, de exemplu, Slack. Pf!
Proiectarea sincronizărilor de zi cu zi
Dacă aveți experiență în dezvoltarea de software, trebuie să fie deranjant să vă amintiți că majoritatea oamenilor nu pot doar să privească o imagine a unei interfețe și să înțeleagă ce va face aceasta atunci când interacționează cu ea. Ca să nu mai vorbim de ce se întâmplă în interiorul programului în sine. Să știi că putea întâmplare este în mare măsură rezultatul cunoașterii a ceea ce nu se poate întâmpla și a ceea ce nu ar trebui să se întâmple. Este nevoie de nu numai ce face software-ul, ci și modul în care părțile sale individuale sunt coordonate și comunică între ele.
Un exemplu clasic în acest sens este un utilizator care se uită la un spinner.gif, întrebându-mă când se va termina în sfârșit lucrarea. Dezvoltatorul și-ar fi dat seama că procesul a fost probabil blocat și că gif-ul nu va dispărea niciodată de pe ecran. Această animație simulează execuția unui job, dar nu are legătură cu starea acestuia. În astfel de cazuri, unor tehnicieni le place să-și dea ochii peste cap, uimiți de gradul de confuzie al utilizatorilor. Totuși, observați câți dintre ei indică ceasul care se rotește și spun că acesta este de fapt staționar?
Aceasta este esența valorii în timp real. În zilele noastre, bazele de date în timp real sunt încă foarte puțin utilizate și mulți oameni le privesc cu suspiciune. Cele mai multe dintre aceste baze de date înclină foarte mult spre stilul NoSQL, motiv pentru care folosesc de obicei soluții bazate pe Mongo, care sunt cel mai bine uitate. Cu toate acestea, pentru mine, asta înseamnă să mă simt confortabil să lucrez cu CouchDB, precum și să învăț să proiectez structuri pe care mai mult decât un simplu birocrat le poate umple cu date. Cred că îmi folosesc mai bine timpul.
Dar adevăratul subiect al acestei postări este ceea ce folosesc astăzi. Nu prin alegere, ci din cauza politicilor corporative aplicate indiferent și orbește. Prin urmare, voi oferi o comparație complet corectă și imparțială a două produse de baze de date Google în timp real strâns legate.
Ambele au cuvântul Foc în numele lor. Un lucru îmi amintesc cu drag. Al doilea lucru pentru mine este un alt tip de foc. Nu mă grăbesc să le spun numele, pentru că odată ce o voi face, ne vom confrunta cu prima mare problemă: numele.
Primul se numește Baza de date în timp real Firebaseși al doilea - Firebase Cloud Firestore. Ambele sunt produse de la Suita Firebase Google. API-urile lor sunt numite, respectiv firebase.database(…) и firebase.firestore(…).
Acest lucru s-a întâmplat pentru că Baza de date în timp real - este doar originalul Firebase înainte de cumpărarea sa de către Google în 2014. Apoi Google a decis să creeze ca produs paralel copie Firebase bazat pe o companie de date mari și a numit-o Firestore cu un cloud. Sper că nu ești încă confuz. Dacă încă sunteți confuz, nu vă faceți griji, eu însumi am rescris această parte a articolului de zece ori.
Pentru că trebuie să indicați Firebase în întrebarea Firebase și Firestore într-o întrebare despre Firebase, cel puțin pentru a vă face să înțelegeți acum câțiva ani pe Stack Overflow.
Dacă ar exista un premiu pentru cea mai proastă experiență de denumire a software-ului, acesta ar fi cu siguranță unul dintre concurenți. Distanța Hamming dintre aceste nume este atât de mică încât derutează chiar și inginerii experimentați, ale căror degete tastează un nume în timp ce capetele lor se gândesc la altul. Acestea sunt planuri bine intenționate care eșuează lamentabil; au împlinit profeția că baza de date va fi în flăcări. Și nu glumesc deloc. Persoana care a creat această schemă de denumire a provocat sânge, transpirație și lacrimi.
victorie Pyrrhic
S-ar crede că Firestore este înlocuire Firebase, urmașul său de generație următoare, dar asta ar induce în eroare. Firestore nu este garantat a fi un înlocuitor potrivit pentru Firebase. Se pare că cineva a tăiat totul interesant din el și a confundat majoritatea celorlalte în diferite moduri.
Cu toate acestea, o privire rapidă asupra celor două produse vă poate deruta: par să facă același lucru, practic prin aceleași API-uri și chiar în aceeași sesiune de bază de date. Diferențele sunt subtile și sunt relevate doar printr-un studiu comparativ atent al documentației extinse. Sau când încercați să portați codul care funcționează perfect pe Firebase, astfel încât să funcționeze cu Firestore. Chiar și atunci afli că interfața bazei de date se aprinde imediat ce încerci să trageți și să plasați cu mouse-ul în timp real. Repet, nu glumesc.
Clientul Firebase este politicos, în sensul că memorează modificările și reîncearcă automat actualizările care acordă prioritate ultimei operațiuni de scriere. Cu toate acestea, Firestore are o limită de 1 operație de scriere per document per utilizator pe secundă, iar această limită este impusă de server. Când lucrați cu acesta, depinde de dvs. să găsiți o cale de a o ocoli și să implementați un limitator al ratei de actualizare, chiar și atunci când încercați doar să vă construiți aplicația. Adică, Firestore este o bază de date în timp real fără un client în timp real, care se mascadă ca unul care utilizează un API.
Aici începem să vedem primele semne ale rațiunii de a fi a Firestore. S-ar putea să mă înșel, dar bănuiesc că cineva din conducerea Google s-a uitat la Firebase după achiziție și a spus pur și simplu: „Nu, Doamne, nu. Este inacceptabil. Doar nu sub conducerea mea.”
A apărut din camerele sale și a declarat:
„Un document JSON mare? Nu. Veți împărți datele în documente separate, fiecare dintre ele nu va avea o dimensiune mai mare de 1 megaoctet.”
Se pare că o astfel de limitare nu va supraviețui primei întâlniri cu vreo bază de utilizatori suficient de motivată. Știi că este. La serviciu, de exemplu, avem mai mult de o mie și jumătate de prezentări, iar acest lucru este Complet Normal.
Cu această limitare, veți fi forțat să acceptați faptul că un „document” din baza de date nu va semăna cu niciun obiect pe care un utilizator l-ar putea numi un document.
„Matrice de matrice care pot conține recursiv alte elemente? Nu. Matricele vor conține doar obiecte sau numere cu lungime fixă, așa cum a intenționat Dumnezeu.”
Deci, dacă sperați să introduceți GeoJSON în Firestore, veți descoperi că acest lucru nu este posibil. Nimic neunidimensional nu este acceptabil. Sper că vă place Base64 și/sau JSON în JSON.
„Import și export JSON prin HTTP, instrumente de linie de comandă sau panou de administrare? Nu. Veți putea exporta și importa date numai în Google Cloud Storage. Așa se numește acum, cred. Și când spun „tu”, mă adresez doar celor care au acreditări de proprietar de proiect. Toți ceilalți pot merge să creeze bilete.”
După cum puteți vedea, modelul de date FireBase este ușor de descris. Conține un document JSON uriaș care asociază cheile JSON cu căile URL. Daca scrii cu HTTP PUT в / FireBase este următorul:
{
"hello": "world"
}
Apoi GET /hello va reveni "world". Practic, funcționează exact așa cum te-ai aștepta. Colecție de obiecte FireBase /my-collection/:id echivalent cu un dicționar JSON {"my-collection": {...}} în rădăcină, al cărui conținut este disponibil în /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Acest lucru funcționează bine dacă fiecare inserție are un ID fără coliziuni, pentru care sistemul are o soluție standard.
Cu alte cuvinte, baza de date este 100% compatibilă cu JSON(*) și funcționează excelent cu HTTP, cum ar fi CouchDB. Dar, practic, îl utilizați printr-un API în timp real care face abstracție de websocket-uri, autorizare și abonamente. Panoul de administrare are ambele capabilități, permițând atât editarea în timp real, cât și importul/exportul JSON. Dacă faceți același lucru în codul dvs., veți fi surprins de cât de mult cod specializat va fi irosit atunci când vă dați seama că JSON de patch și diff rezolvă 90% din sarcinile de rutină de gestionare a stării persistente.
Modelul de date Firestore este similar cu JSON, dar diferă în unele moduri critice. Am menționat deja lipsa de matrice în cadrul matricelor. Modelul pentru sub-colecții este ca acestea să fie concepte de primă clasă, separate de documentul JSON care le conține. Deoarece nu există o serializare gata făcută pentru aceasta, este necesară o cale de cod specializată pentru a prelua și scrie date. Pentru a vă procesa propriile colecții, trebuie să vă scrieți propriile scripturi și instrumente. Panoul de administrare vă permite doar să faceți mici modificări câte un câmp și nu are capabilități de import/export.
Au luat o bază de date NoSQL în timp real și au transformat-o într-un non-SQL lent, cu auto-join și o coloană separată non-JSON. Ceva de genul GraftQL.
Java fierbinte
Dacă Firestore ar fi trebuit să fie mai fiabil și mai scalabil, atunci ironia este că dezvoltatorul obișnuit va ajunge cu o soluție mai puțin fiabilă decât alegerea FireBase din cutie. Tipul de software de care are nevoie Administratorul de baze de date Grumpy necesită un nivel de efort și un calibru de talent care este pur și simplu nerealist pentru nișa la care produsul ar trebui să fie bun. Acest lucru este similar cu modul în care HTML5 Canvas nu este deloc un înlocuitor pentru Flash dacă nu există instrumente de dezvoltare și un player. În plus, Firestore este înfundat într-o dorință de puritate a datelor și validare sterilă care pur și simplu nu se aliniază cu modul în care utilizatorul mediu de afaceri iubește să lucreze: pentru el totul este optional, pentru ca pana la final totul este o ciorna.
Principalul dezavantaj al FireBase este că clientul a fost creat cu câțiva ani înaintea timpului său, înainte ca majoritatea dezvoltatorilor web să știe despre imuabilitate. Din acest motiv, FireBase presupune că veți modifica datele și, prin urmare, nu profită de imuabilitatea oferită de utilizator. În plus, nu reutiliza datele din instantaneele pe care le transmite utilizatorului, ceea ce face diferența mult mai dificilă. Pentru documentele mari, mecanismul său de tranzacție bazat pe diferențe mutabile este pur și simplu inadecvat. Băieți, avem deja WeakMap în JavaScript. Este confortabil.
Dacă dați datelor forma dorită și nu faceți copacii prea voluminosi, atunci această problemă poate fi ocolită. Dar sunt curios dacă FireBase ar fi mult mai interesant dacă dezvoltatorii ar lansa un client API foarte bun care să folosească imuabilitatea combinată cu câteva sfaturi practice serioase privind proiectarea bazei de date. În schimb, păreau să încerce să repare ceea ce nu era stricat și asta a înrăutățit situația.
Nu cunosc toată logica din spatele creării Firestore. Specularea cu privire la motivele care apar în interiorul cutiei negre face, de asemenea, parte din distracție. Această juxtapunere a două baze de date extrem de similare, dar incomparabile este destul de rară. De parcă cineva s-ar fi gândit: „Firebase este doar o funcție pe care o putem emula în Google Cloud”, dar nu a descoperit încă conceptul de identificare a cerințelor din lumea reală sau de a crea soluții utile care să îndeplinească toate aceste cerințe. „Lăsați dezvoltatorii să se gândească la asta. Doar faceți interfața frumoasă... Puteți adăuga mai mult foc?”
Înțeleg câteva lucruri despre structurile de date. Cu siguranță văd conceptul „totul într-un arbore JSON mare” ca o încercare de a abstrage orice sens de structură la scară largă din baza de date. Așteptați ca software-ul să facă față pur și simplu oricărui fractal cu structură de date dubioasă este pur și simplu o nebunie. Nici nu trebuie să-mi imaginez cât de rău ar putea fi lucrurile, am făcut audituri riguroase de cod și Am văzut lucruri la care voi nu ați visat niciodată. Dar știu și cum arată structurile bune, и . Îmi pot imagina o lume în care Firestore ar părea logic și oamenii care l-au creat ar crede că au făcut o treabă bună. Dar noi nu trăim în această lume.
Suportul pentru interogări FireBase este slab după orice standard și este practic inexistent. Cu siguranță are nevoie de îmbunătățire sau măcar de revizuire. Dar Firestore nu este cu mult mai bun, deoarece este limitat la aceiași indecși unidimensionali găsiți în SQL simplu. Dacă aveți nevoie de interogări pe care oamenii le execută pe date haotice, aveți nevoie de căutare full-text, filtre cu mai multe intervale și ordine personalizată, definită de utilizator. La o inspecție mai atentă, funcțiile SQL simplu sunt prea limitate de la sine. În plus, singurele interogări SQL pe care oamenii le pot executa în producție sunt interogările rapide. Veți avea nevoie de o soluție de indexare personalizată cu structuri inteligente de date. Pentru orice altceva, ar trebui să existe cel puțin o reducere incrementală a hărții sau ceva similar.
Dacă căutați în Google Docs informații despre acest lucru, sperăm că veți fi îndreptat către ceva precum BigTable și BigQuery. Cu toate acestea, toate aceste soluții sunt însoțite de un jargon atât de dens de vânzări corporative încât te vei întoarce rapid și vei începe să cauți altceva.
Ultimul lucru pe care îl doriți cu o bază de date în timp real este ceva făcut de și pentru oameni de pe grilele de salarizare a managementului.
(*) Aceasta este o glumă, nu există așa ceva .
Despre drepturile de publicitate
Căuta pentru proiecte de depanare, un server pentru dezvoltare și găzduire? Sunteți cu siguranță clientul nostru 🙂 Prețurile zilnice pentru servere de diverse configurații, licențele anti-DDoS și Windows sunt deja incluse în preț.
Sursa: www.habr.com