Permiteți-mi să vă istorisesc o poveste tehnică.
Cu mulți ani în urmă, am dezvoltat o aplicație cu funcționalități integrate de colaborare. A fost un stiv experimentat convenabil, care a folosit pe deplin potențialul React-ului timpuriu și CouchDB. Aceasta sincroniza datele în timp real prin JSON. . A fost utilizată în activitățile interne ale companiei, dar aplicabilitatea sa largă și potențialul în alte domenii erau evidente.
Încercând să vindem această tehnologie potențialilor clienți, ne-am confruntat cu un obstacol neprevăzut. În videoclipul de demonstratie, tehnologia noastră arăta și funcționa excelent, fără nicio problemă. Videoclipul arăta exact cum funcționează, fără simulări. Am conceput și codificat un scenariu realist de utilizare a programului.
De fapt, aceasta a devenit problema. Demo-ul nostru funcționa exact ca și cum ar fi simulat modul în care funcționează aplicațiile altora. Concret, informațiile erau transmise instantaneu de la A la B, chiar și în cazul fișierelor media mari. După autentificare, fiecare utilizator vedea înregistrările noi. Prin intermediul aplicației, utilizatorii diferiți puteau colabora cu claritate la aceleași proiecte, chiar și în cazul unei conexiuni la Internet întrerupte undeva într-un sat. În mod indirect, acest lucru este sugerat în orice videoclip editat în After Effects despre produs.
Deși toată lumea știa la ce servea butonul Refresh, nimeni nu înțelegea deloc că aplicațiile web, pe care ni le cer să le dezvoltăm, sunt de obicei supuse propriilor limitări. Și că, dacă acestea nu mai sunt necesare, experiența utilizatorului va fi complet diferită. În general, observau că pot 'conversa', lăsând note partenerilor de dialog, motiv pentru care se întrebau în ce diferă aceasta de Slack, de exemplu. Uf!
Designul sincroniilor zilnice
Dacă aveți deja experiență în dezvoltarea de software, atunci ar trebui să vă enerveze necesitatea de a ține minte că majoritatea oamenilor nu pot pur și simplu să privească o imagine a interfeței și să înțeleagă ce va face aceasta atunci când interacționează cu ea. Nemaivorbind de ceea ce se întâmplă în interiorul programului. Cunoașterea a ceea ce poate va avea loc este în mare parte rezultatul cunoașterii a ceea ce nu poate avea loc și ce nu ar trebui să se întâmple. Acest lucru necesită nu doar ceea ce face software-ul, ci și modul în care părțile sale sunt sincronizate și comunică între ele.
Un exemplu clasic este utilizatorul care, timp de douăzeci de minute, se uită la spinner.gif, întrebându-se când, în sfârșit, va termina procesul. Dezvoltatorul ar fi realizat că procesul este probabil blocat, iar gif-ul nu va dispărea niciodată de pe ecran. Această animație imită finalizarea lucrării, dar nu este legată de starea acesteia. În astfel de cazuri, unii specialiști tehnici adoră să răsufle din umeri, surprinși de gradul de confuzie al utilizatorilor. Dar observați, cine dintre ei ar arăta la ceasurile care se rotesc și ar spune că de fapt stau nemișcate?
Aceasta este esența valorii timpului real. În zilele noastre, bazele de date în timp real încă sunt folosite foarte puțin și multe dintre ele sunt privite cu suspiciune. Cele mai multe dintre aceste baze de date tind să se îndrepte spre stilul NoSQL, ceea ce duce de obicei la utilizarea soluțiilor bazate pe Mongo, despre care ar fi mai bine să uităm. Totuși, pentru mine, aceasta înseamnă confortul lucrului cu CouchDB, precum și studierea proiectării structurilor care vor putea fi completate cu date nu doar de un birocrat. Cred că îmi folosesc timpul mai eficient.
Dar adevărata temă a acestui articol este ceea ce folosesc astăzi. Nu din alegerea mea, ci din cauza unei politici corporative aplicate indiferent și în mod orb. Prin urmare, voi face o Comparație Complet Onestă și Impartială a două produse strâns legate pentru lucrul cu bazele de date în timp real Google.
Ambele titluri conțin cuvântul Fire. Unul îmi amintește cu dragoste. Celălalt pentru mine este un alt tip de foc. Nu mă grăbesc să pronunț numele lor, deoarece, odată ce o fac, ne vom confrunta cu prima mare problemă – numele.
Primul se numește Firebase Real-Time Database, iar al doilea – Firebase Cloud Firestore. Ambele sunt produse din Firebase suite Google. API-urile lor se numesc, respectiv, firebase.database(…) și firebase.firestore(…).
Aceasta s-a întâmplat pentru că Real-Time Database – este pur și simplu versiunea inițială a Firebase înainte de achiziția sa de către Google în 2014. Apoi, Google a decis să creeze un produs paralel care să fie o copie Firebase pe baza big data a companiei, numindu-l Firestore cu un nor. Sper că nu te-ai pierdut încă. Dacă totuși te-ai pierdut, nu-ți face griji, am rescris această parte a articolului de zece ori.
Pentru că trebuie să specifici Firebase în ceea ce privește Firebase și Firestore în legătură cu Firebase, cel puțin pentru a fi înțeles acum câțiva ani pe Stack Overflow.
Dacă ar exista un premiu pentru cel mai prost nume al produselor software, acest caz ar fi cu siguranță unul dintre candidați. Distanța Hamming dintre aceste denumiri este atât de mică încât îi confuzează chiar și pe inginerii experimentați, al căror degete tastează un nume, deși mintea gândește la altul. Acestea sunt planuri eșuate cu zgomot, concepute cu cele mai bune intenții; ele au împlinit profeția că baza de date va fi în flăcări. Și nu glumesc. Persoana care a creat un astfel de sistem de numire a fost cauza sângelui, transpirației și lacrimilor.
O victorie Pyrrhică
S-ar putea crede că Firestore este o înlocuire pentru Firebase, urmașul său de generație următoare, dar ar fi o eroare. Firestore cu siguranță nu se potrivește rolului de înlocuire pentru Firebase. Se pare că cineva a scos din el tot ce este interesant și a complicat cea mai mare parte a ceea ce a mai rămas în diferite moduri.
Cu toate acestea, o privire rapidă asupra celor două produse poate să te confuzeze: pare că fac același lucru, prin API-uri în mare parte identice și chiar în aceeași sesiune de baze de date. Diferențele sunt greu de remarcat și sunt descoperite doar printr-o examinare atentă a documentației voluminoase. Sau când încerci să portezi un cod care funcționează perfect pe Firebase, pentru a-l face să funcționeze cu Firestore. Deja atunci îți dai seama că interfața bazei de date se activează de fiecare dată când încerci să efectuezi un drag-and-drop în timp real. Repet, nu glumesc.
Clientul Firebase este politicos în sensul că bufferizează modificările și efectuează o repetare automată a încercărilor de actualizare, dând prioritate ultimei operațiuni de scriere. Cu toate acestea, Firestore are o limitare de 1 operațiune de scriere pe document pe utilizator pe secundă, iar această limitare este impusă de server. Când lucrezi cu el, trebuie să găsești singur o modalitate de a o ocoli și de a implementa un limitator al ratei de actualizări, chiar și atunci când încerci să creezi aplicația ta. Adică Firestore este o bază de date în timp real fără client în timp real, care se maschează sub ea prin API.
Aici începem să vedem primele semne ale sensului existenței Firestore. Poate că mă înșel, dar bănuiesc că cineva sus în conducerea Google s-a uitat după achiziția Firebase și a spus: „Nu, Dumnezeule, nu. Asta e inacceptabil. Numai să nu sub conducerea mea.”
S-a făcut auzit din încăperile sale și a proclamat:
„Un singur document JSON de mari dimensiuni? Nu. Vei împărți datele în documente separate, fiecare cu o dimensiune de maximum 1 megabyte.”
Se pare că această restricție nu va supraviețui primei întâlniri cu orice bază de utilizatori suficient de motivată. Știți că așa este. La noi la muncă, de exemplu, avem mai mult de o mie și jumătate de prezentări, și asta este complet normal.
Cu o astfel de restricție, va trebui să te împaci cu faptul că un „document” din baza de date nu va semăna deloc cu un obiect pe care utilizatorul l-ar putea numi document.
„Mase de mase, care pot conține recursiv alte elemente? Nu. Masele vor conține doar obiecte sau numere de lungime fixă, așa cum a fost gândit de Domnul.”
Așa că dacă sperai să încorporezi GeoJSON în Firestore-ul tău, vei descoperi că este imposibil. Nimic multidimensional nu este permis. Sper că îți place Base64 și/sau JSON în interiorul JSON-ului.
„Importul și exportul JSON prin HTTP, instrumente de linie de comandă sau panouri de administrare? Nu. Vei putea doar să exporți și să imporți date în Google Cloud Storage. Așa pare că se numește acum. Și când spun „tu”, mă adresez doar celor care au privilegiul de Project Owner. Toți ceilalți pot merge să creeze bilete.”
După cum vedeți, modelul de date FireBase este ușor de descris. Acesta conține un singur document JSON uriaș, care leagă cheile JSON de căile URL. Dacă scrii folosind HTTP PUT în / FireBase următorul text:
{
"hello": "world"
} Atunci GET /hello va returna "world". În esență, funcționează exact așa cum te aștepți. Colecția de obiecte FireBase /my-collection/:id este echivalentă cu un dicționar JSON {"my-collection": {...}} în rădăcină, conținutul căruia este disponibil în /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Funcționează excelent dacă fiecare inserție are ID-uri fără coliziuni, pentru care în sistem există o soluție standard.
Cu alte cuvinte, baza de date este 100% compatibilă cu JSON (*) și funcționează excelent cu HTTP, de exemplu, cu CouchDB. Însă, în principal, o folosiți prin API-ul în timp real, care abstrează websockets, autorizarea și abonamentele. Panoul de administrare are ambele capacități, permițând atât editarea în timp real, cât și importul/exportul JSON. Dacă vă veți menține același principiu în codul vostru, veți fi uimiți de cât de mult cod specializat va dispărea atunci când veți înțelege că patch și diff JSON permit rezolvarea a 90% din sarcinile de rutină legate de gestionarea stării persistente.
Modelul de date Firestore este similar cu JSON, dar se deosebește în câteva aspecte critice. Am menționat deja absența tablourilor în interiorul altor tablouri. Modelul sub-collecțiilor este că acestea sunt concepte de primă clasă, separate de documentul JSON care le conține. Deoarece nu există o serializare gata făcută pentru aceasta, pentru a obține și a scrie date, este nevoie de un parcurs de execuție a codului specializat. Pentru a gestiona propriile colecții, trebuie să scrieți scripturi și instrumente proprii. Panoul de administrare vă permite să faceți doar modificări minore, câte un câmp pe rând, și nu are funcții de import/export.
Ei au transformat o bază de date NoSQL în timp real într-o soluție lentă non-SQL cu auto-uniune și o coloană separată non-JSON. Ceva de genul GraftQL.
Java fierbinte
Dacă Firestore ar trebui să devină mai fiabil și scalabil, ironia este că developerul mediu va obține o soluție mai puțin fiabilă decât dacă aleg FireBase „din cutie”. Software-ul necesar pentru un Administrator de Baze de Date Queeny necesită un nivel de efort și expertiză atât de ridicat încât este pur și simplu nerealist pentru nișa în care, teoretic, ar trebui să fie un produs bun. Este similar cu faptul că HTML5 Canvas nu este o înlocuire pentru Flash, dacă nu există unelte de dezvoltare și un player. În plus, Firestore s-a împotmolit în dorința de a menține puritatea datelor și validarea sterilă, ceea ce pur și simplu nu corespunde modului în care utilizatorul mediu de business preferă să lucreze: pentru el, totul este opțional, deoarece până la sfârșit, totul este un draft.
Principala problemă a FireBase este că clientul a fost creat cu câțiva ani înainte de termenul său, cu mult înainte ca majoritatea dezvoltatorilor web să afle despre imutabilitate. Din acest motiv, FireBase presupune că veți modifica datele, așa că nu beneficiază de avantajele imutabilității asigurate de utilizator. În plus, nu reutilizează datele în instantaneele transmise utilizatorului, ceea ce face ca realizarea unui diff să fie mult mai complicată. Pentru documente mari, mecanismul său de tranzacții bazat pe difuri modificabile este pur și simplu inadecvat. Oameni buni, avem deja WeakMap în JavaScript. Este convenabil.
Dacă datele sunt formate corespunzător și nu se fac arbori prea voluminoși, problema poate fi evitată. Dar sunt curios dacă FireBase ar deveni mult mai interesant dacă dezvoltatorii ar lansa un API client adevărat care să utilizeze imutabilitatea împreună cu sfaturi practice serioase pentru structura bazelor de date. În schimb, se pare că au încercat să repare ceea ce nu era stricat, iar rezultatul a fost mai rău.
Nu cunosc întreaga logică din spatele creării Firestore. Raționamentele despre motivele care apar în interiorul unui cutie neagră sunt și ele o parte a divertismentului. O astfel de opoziție între două baze de date extrem de asemănătoare, dar incomparabile, este destul de rară. Ca și cum cineva ar fi spus: „Firebase este pur și simplu o funcție pe care o putem emula în Google Cloud”, dar în același timp, nu a descoperit încă conceptul de determinare a cerințelor din lumea reală sau de crearea de soluții utile care să satisfacă toate aceste cerințe. „Lăsați dezvoltatorii să se ocupe de asta. Faceți UI frumos… Oare putem adăuga mai multă flacără?”
Înțeleg câteva lucruri despre structuri de date. Văd clar că conceptul de „totul într-un singur arbore JSON mare” este o încercare de a abstrahiza din baza de date orice sentiment de structură pe scară largă. Așteptând ca software-ul să facă față oricărui fractal dubios al structurii de date este pur și simplu o nebunie. Nu trebuie să-mi imaginez cât de rău poate fi totul, am realizat audite stricte de cod și am văzut lucruri pe care voi, oamenii, nici măcar nu le-ați visat.Dar știu și cum arată structurile bune, și . Pot să îmi imaginez o lume în care Firestore ar părea perfect logic, iar oamenii care l-au creat ar considera că au făcut o treabă bună. Dar noi nu trăim în această lume.
Suportul pentru construirea de interogări în FireBase este slab după orice standarde, practic nu există. Definitiv necesită îmbunătățiri sau cel puțin o revizuire. Dar Firestore nu este mult mai bun, deoarece este limitat de aceleași indici unidimensionali care există în SQL simplu. Dacă aveți nevoie de interogări, pe care oamenii le fac cu date haotice, atunci este necesară căutarea textului complet, filtre pentru mai multe intervale și un ordin arbitrar specificat de utilizator. Când studiezi cu atenție, funcțiile SQL simple sunt ele însele prea limitate. În plus, singurele interogări SQL pe care oamenii le pot efectua în producție sunt interogările rapide. Vei avea nevoie de o soluție specializată pentru indexare cu structuri de date bine gândite. Pentru tot restul, ar trebui să existe cel puțin un map-reduce incremental sau ceva similar.
Dacă cauți informații despre asta în documentele Google, sper că îți vor indica într-o direcție de genul BigTable și BigQuery. Totuși, toate aceste soluții vin cu un volum de jargon corporatist atât de dens, încât te vei întoarce rapid și vei începe să cauți altceva.
Ultimul lucru de care ai nevoie în cazul unei baze de date în timp real este ceva creat de oameni, pentru oameni, care lucrează pe baza unui salariu pentru conducere.
(*) Este o glumă, nu există un concept de .
În numele publicității
Cauți pentru depanarea proiectelor, server pentru dezvoltare și găzduire? Ești exact clientul nostru 🙂 Tarife pe zi pentru servere cu cele mai diverse configurații, antiDDoS și licențe Windows sunt deja incluse în preț.
Sursa: habr.com
