Lasciami dì una storia tecnica.
Parechji anni fà, aghju sviluppatu una applicazione cù funzioni di cullaburazione integrate. Era una pila sperimentale user-friendly chì hà apprufittatu di tuttu u putenziale di i primi React è CouchDB. Hè sincronizatu e dati in tempu reale via JSON . Hè stata utilizata internamente in a cumpagnia, ma a so larga applicabilità è u putenziale in altri spazii era chjaru.
Mentre pruvava di vende sta tecnulugia à i clienti potenziali, avemu scontru un ostaculu inesperu. In u video demo, a nostra tecnulugia pareva è hà travagliatu bè, senza prublemi. U video hà dimustratu esattamente cumu funziona è ùn hà micca imitatu nunda. Avemu ghjuntu è codificatu un scenariu realistu per aduprà u prugramma.
In fatti, questu hè diventatu u prublema. A nostra demo hà travagliatu esattamente cumu tutti l'altri simulavanu e so applicazioni. In particulare, l'infurmazione hè stata trasferita istantaneamente da A à B, ancu s'ellu era grandi schedarii media. Dopu à u login, ogni utilizatore hà vistu novi entrate. Utilizendu l'applicazione, diversi utilizatori puderanu travaglià inseme chjaramente nantu à i stessi prughjetti, ancu s'è a cunnessione Internet hè stata interrotta in un locu in u paese. Questu hè implicitamente implicatu in qualsiasi video di produttu tagliatu in After Effects.
Ancu s'è tutti sapianu ciò chì u buttone Refresh era per, nimu hà veramente capitu chì l'applicazioni web chì ci anu dumandatu di custruisce sò generalmente sottumessi à e so limitazioni. È chì s'ellu ùn sò più necessarii, l'esperienza di l'utilizatore serà completamente diversa. Per suprattuttu anu nutatu chì puderanu "chat" lascendu note per e persone chì parlavanu, cusì si dumandavanu cumu questu era diversu da, per esempiu, Slack. Uff!
Disegnu di sincronizazioni di ogni ghjornu
Sè vo avete sperienza in u sviluppu di software, deve esse nerve-wracking à ricurdà chì a maiò parte di a ghjente ùn pò micca solu fighjà una foto di una interfaccia è capisce ciò chì farà quandu interagisce cun ella. Senza parlà di ciò chì succede in u prugramma stessu. Sapete chì pò succede hè largamente u risultatu di sapè ciò chì ùn pò micca succede è ciò chì ùn deve micca succede. Questu hè bisognu micca solu ciò chì u software faci, ma ancu cumu e so parti individuali sò coordinati è cumunicà cù l'altri.
Un esempiu classicu di questu hè un utilizatore chì fissa a spinner.gif, dumandendu quandu u travagliu serà infine finitu. U sviluppatore averia capitu chì u prucessu era prubabilmente chjapputu è chì u gif ùn sparissi mai da u screnu. Questa animazione simula l'esekzione di un travagliu, ma ùn hè micca ligata à u so statu. In tali casi, certi tecnichi piace à vultà l'ochji, maravigliati da l'estensione di cunfusione di l'utilizatori. Tuttavia, nutate quanti di elli puntanu à u clock rotativu è dicenu chì hè veramente stazionariu?
Questu hè l'essenza di u valore in tempu reale. In questi ghjorni, e basa di dati in tempu reale sò sempre pocu utilizati è parechje persone li vedenu cun suspettu. A maiò parte di sti basa di dati s'appoghjanu assai versu l'stile NoSQL, per quessa chì generalmente utilizanu suluzioni basate in Mongo, chì sò megliu scurdate. Tuttavia, per mè, questu significa esse cunfortu à travaglià cù CouchDB, è ancu amparà à cuncepisce strutture chì più di un burocrate pò riempie di dati. Pensu chì aghju aduprà u mo tempu megliu.
Ma u veru tema di stu post hè ciò chì aghju utilizatu oghje. Micca per scelta, ma per via di e pulitiche corporative applicate indifferentemente è ciechi. Dunque, daraghju un paragone cumpletamente ghjusta è imparziale di dui prudutti di basa di dati Google in tempu reale strettamente ligati.
Tutti dui anu a parolla Fire in i so nomi. Una cosa mi ricordu cù affettu. A seconda cosa per mè hè un altru tipu di focu. Ùn aghju micca fretta di dì i so nomi, perchè una volta ch'e aghju fattu, anderemu in u primu grande prublema : i nomi.
U primu hè chjamatu Firebase Database in tempu reale, è secondu - Firebase Cloud Firestore. Tutti dui sò prudutti da Suite Firebase Google. I so API sò chjamati rispettivamente firebase.database(…) и firebase.firestore(…).
Questu hè accadutu perchè Database in tempu reale - hè solu l'uriginale Firebase prima di a so compra da Google in 2014. Allora Google hà decisu di creà cum'è un pruduttu parallelu cupià Firebase basatu annantu à a cumpagnia di big data, è chjamatu Firestore cù un nuvulu. Spergu chì ùn site micca ancu cunfusu. Sè vo site sempre cunfusu, ùn vi preoccupate micca, aghju riscritto sta parte di l'articulu deci volte.
Perchè avete bisognu di indicà Firebase in a quistione di Firebase, è Firestore in una quistione di Firebase, almenu per fà capisce uni pochi anni fà nantu à Stack Overflow.
S'ellu ci era un premiu per a peghju sperienza di nomi di software, questu seria sicuramente unu di i contendenti. A distanza di Hamming trà questi nomi hè cusì chjuca chì cunfundisce ancu ingegneri sperimentati, chì i so dite scrivenu un nome mentre i so capi pensanu à un altru. Quessi sò piani bè intenzionati chì fallenu miserably; anu rializatu a prufezia chì a basa di dati seria nantu à u focu. È ùn scherzu à tuttu. A persona chì hè stata cun stu schema di nomi hà causatu sangue, sudore è lacrime.
Vittoria pirrica
Unu puderia pensà chì Firestore hè sustituzzioni Firebase, u so discendenti di a prossima generazione, ma chì seria sbagliatu. Firestore ùn hè micca garantitu per esse un sustitutu adattatu per Firebase. Sembra chì qualchissia hà tagliatu tuttu ciò chì hè interessante da ellu, è hà cunfunditu a maiò parte di u restu in vari modi.
In ogni casu, un sguardu rapidu à i dui prudutti pò cunfundà: parenu fà a listessa cosa, à traversu in fondu à e stesse API è ancu in a stessa sessione di basa di dati. I diffirenzii sò sottili è sò revelati solu da un studiu comparativu attentu di una documentazione estensiva. O quandu pruvate à portà u codice chì funziona perfettamente in Firebase in modu chì travaglia cù Firestore. Ancu tandu scopre chì l'interfaccia di a basa di dati si accende appena pruvate à arrastà è goccia cù u mouse in tempu reale. Ripecu, ùn scherzu micca.
U cliente Firebase hè educatu in u sensu chì buffers cambiamenti è riprova automaticamente l'aghjurnamenti chì dà priorità à l'ultima operazione di scrittura. Tuttavia, Firestore hà un limitu di 1 operazione di scrittura per documentu per utilizatore per seconda, è questu limitu hè infurzatu da u servitore. Quandu travaglia cun ellu, tocca à voi di truvà un modu intornu è implementà un limitatore di freccia di aghjurnamentu, ancu quandu avete solu pruvà à custruisce a vostra applicazione. Vale à dì, Firestore hè una basa di dati in tempu reale senza un cliente in tempu reale, chì si maschera cum'è quellu chì usa una API.
Quì avemu principiatu à vede i primi signali di a raison d'être di Firestore. Puderaghju esse sbagliatu, ma suspettu chì qualcunu altu in a gestione di Google hà guardatu Firebase dopu a compra è hà dettu solu: "No, oh mio Diu, nò. Questu hè inaccettabile. Solu micca sottu à a mo dirigenza ".
Hè apparsu da e so camere è hà dichjaratu:
"Un grande documentu JSON? Innò. Dividerete e dati in documenti separati, ognuna di e quali ùn serà micca più di 1 megabyte in dimensione ".
Sembra chì una tale limitazione ùn sopravvive à u primu scontru cù una basa d'utilizatori abbastanza motivata. Sapete chì hè. À u travagliu, per esempiu, avemu più di un milla è mezzo di presentazione, è questu hè Completamente Normale.
Cù sta limitazione, sarete obligatu à accettà u fattu chì un "documentu" in a basa di dati ùn s'assumiglia à alcun ughjettu chì un utilizatore puderia chjamà un documentu.
"Matrici di matrici chì ponu cuntene recursivamente altri elementi? Innò. Arrays cuntenenu solu oggetti o numeri di lunghezza fissa, cum'è Diu hà intesu ".
Allora s'è vo sperava di mette GeoJSON in u vostru Firestore, truverete chì questu ùn hè micca pussibule. Nunda micca unidimensionale hè accettabile. Spergu chì ti piace Base64 è / o JSON in JSON.
"Importazione è esportazione JSON via HTTP, strumenti di linea di cummanda o pannellu di amministrazione? Innò. Puderete solu exportà è impurtà dati in Google Cloud Storage. Hè ciò chì si chjama avà, pensu. È quandu dicu "tu", mi rivolgu solu à quelli chì anu credenziali di Prughjettu di Prughjettu. Tutti l'altri ponu andà è creà biglietti ".
Comu pudete vede, u mudellu di dati FireBase hè faciule da descriverà. Contene un grande documentu JSON chì associa e chjave JSON cù i percorsi URL. Sè vo scrivite cun HTTP PUT в / FireBase hè u seguente:
{
"hello": "world"
}
U GET /hello tornerà "world". In fondu, funziona esattamente cum'è aspittà. Raccolta di oggetti FireBase /my-collection/:id equivalenti à un dizziunariu JSON {"my-collection": {...}} in a ràdica, u cuntenutu di quali sò dispunibuli in /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Questu funziona bè se ogni inserimentu hà un ID senza collisione, chì u sistema hà una suluzione standard per.
In altre parolle, a basa di dati hè 100% JSON (*) cumpatibile è funziona bè cù HTTP, cum'è CouchDB. Ma basicamente l'utilizate attraversu una API in tempu reale chì astrae websockets, l'autorizazione è l'abbonamenti. U pannellu di amministrazione hà e duie capacità, chì permettenu sia l'edizione in tempu reale sia l'importazione / esportazione JSON. Sè vo fate u listessu in u vostru còdice, vi Mulateri Di L'esse maravigliatu di quantu codice specializatu serà persu quandu vi capisce chì patch è diff JSON risolve u 90% di i travaglii di rutina di manighjà u statu persistente.
U mudellu di dati Firestore hè simile à JSON, ma differisce in certi modi critichi. Aghju digià citatu a mancanza di arrays in arrays. U mudellu per i sub-collections hè per elli esse cuncetti di prima classe, separati da u documentu JSON chì li cuntene. Siccomu ùn ci hè micca una serializazione pronta per questu, un percorsu di codice specializatu hè necessariu per ricuperà è scrive dati. Per processà e vostre cullezzione, avete bisognu di scrive i vostri scritti è arnesi. U pannellu di amministrazione permette solu di fà picculi cambiamenti un campu à tempu, è ùn hà micca capacità d'importazione / esportazione.
Hanu pigliatu una basa di dati NoSQL in tempu reale è l'hanu trasfurmatu in una lenta non-SQL cù auto-join è una colonna separata non-JSON. Qualcosa cum'è GraftQL.
Java calda
Se Firestore duverebbe esse più affidabile è scalabile, allora l'ironia hè chì u sviluppatore mediu finisce cù una suluzione menu affidabile di sceglie FireBase fora di a scatula. U tipu di software chì l'Amministratore di Database Grumpy hà bisognu richiede un livellu di sforzu è calibre di talentu chì hè simplicemente irrealisticu per u niche chì u pruduttu deve esse bonu. Questu hè simili à cumu HTML5 Canvas ùn hè micca un sustitutu di Flash in tuttu s'ellu ùn ci hè micca strumenti di sviluppu è un lettore. Inoltre, Firestore hè impiccatu in un desideriu di purità di dati è validazione sterile chì simpricimenti ùn hè micca allinatu cù cumu l'utilizatore mediu di l'affari. piace à travaglià: per ellu tuttu hè facultativu, perchè finu à a fine tuttu hè un draft.
U principale disadvantage di FireBase hè chì u cliente hè statu creatu parechji anni prima di u so tempu, prima chì a maiò parte di i sviluppatori web sapianu l'immutabilità. Per via di questu, FireBase assume chì avete da cambià i dati è per quessa ùn prufiteghja micca di l'immutabilità furnita da l'utilizatori. Inoltre, ùn riutilice micca e dati in i snapshots chì passa à l'utilizatore, chì rende difficiuli assai più difficili. Per i grandi documenti, u so mecanismu di transazzione basata in diffizzioni mutabile hè simplicemente inadegwate. Ragazzi, avemu digià WeakMap in JavaScript. Hè còmode.
Se dà i dati a forma desiderata è ùn fate micca l'arbureti troppu voluminosi, allura stu prublema pò esse circundatu. Ma sò curiosu se FireBase seria assai più interessante se i sviluppatori anu liberatu una API cliente veramente bona chì usava l'immutabilità cumminata cù qualchi cunsiglii pratichi serii nantu à u disignu di basa di dati. Invece, parevanu pruvà à riparà ciò chì ùn era micca rottu, è chì l'aggravava.
Ùn cunnosci micca tutta a logica daretu à a creazione di Firestore. A speculazione di i mutivi chì nascenu in a scatula negra hè ancu parte di u divertimentu. Questa giustapposizione di duie basa di dati estremamente simili ma incomparabile hè abbastanza rara. Hè cum'è qualchissia hà pensatu: "Firebase hè solu una funzione chì pudemu emulà in Google Cloud", ma ùn hà ancu scupertu u cuncettu di identificà i bisogni di u mondu reale o di creà suluzioni utili chì rispondenu à tutti quelli requisiti. "Lasciate chì i sviluppatori pensanu à questu. Basta à fà a UI bella... Pudete aghjunghje più focu?
Aghju capitu un paru di cose nantu à e strutture di dati. Definitivamente vecu u cuncettu di "tuttu in un grande arbre JSON" cum'è un tentativu di astrattu ogni sensu di struttura à grande scala da a basa di dati. Aspittendu u software per affruntà solu cù qualsiasi struttura di dati dubbiosa frattale hè simplicemente insane. Ùn aghju mancu à imaginà quantu e cose pò esse male, aghju fattu auditi di codice rigurosu è Aghju vistu cose chì voi persone ùn avete mai sunniatu. Ma sò ancu ciò chì parenu e boni strutture, и . Puderaghju imaginate un mondu induve Firestore parerebbe logicu è e persone chì l'anu criatu pensanu chì anu fattu un bonu travagliu. Ma ùn campemu micca in stu mondu.
U supportu di dumanda di FireBase hè poviru per qualsiasi standard è hè praticamente inesistente. Hè certamente bisognu di migliurà o almenu rivisione. Ma Firestore ùn hè micca assai megliu perchè hè limitatu à i stessi indici unidimensionali truvati in SQL pianu. Sè avete bisognu di e dumande chì e persone correnu nantu à dati caòtichi, avete bisognu di ricerca di testu cumpletu, filtri multi-range, è ordini persunalizati definiti da l'utilizatori. Dopu un'ispezione più stretta, e funzioni di SQL chjaru sò troppu limitati per sè stessu. Inoltre, l'unicu dumande SQL chì e persone ponu eseguisce in produzzione sò e dumande veloci. Averete bisognu di una soluzione di indexazione persunalizata cù strutture di dati intelligenti. Per tuttu u restu, deve esse almenu una mappa incrementale-reduce o qualcosa simili.
Sè vo circate Google Docs per infurmazione nantu à questu, sperendu esse indicatu in a direzzione di qualcosa cum'è BigTable è BigQuery. Tuttavia, tutte queste suluzioni sò accumpagnate da un jargon di vendita corporativa cusì densu chì vi vulterete rapidamente è cumincià à circà qualcosa d'altru.
L'ultima cosa chì vulete cun una basa di dati in tempu reale hè qualcosa fatta da è per e persone nantu à e scale di pagamentu di gestione.
(*) Questu hè un scherzu, ùn ci hè nunda .
I diritti di publicità
Circà per i prughjetti di debugging, un servitore per u sviluppu è l'ospitu ? Siete sicuramente u nostru cliente 🙂 I prezzi di ogni ghjornu per i servitori di diverse cunfigurazioni, licenze anti-DDoS è Windows sò digià inclusi in u prezzu.
Source: www.habr.com