Questo database è in fiamme…

Lasciate che vi racconti una storia tecnica.

Molti anni fa, stavo sviluppando un'app con funzionalità integrate di collaborazione. Era un esperimento comodo che utilizzava il pieno potenziale del primo React e di CouchDB. Sincronizzava i dati in tempo reale tramite JSON. OT. Venne utilizzato nel lavoro interno dell'azienda, ma l'ampia applicabilità e il potenziale in altri settori erano evidenti.

Cercando di vendere questa tecnologia a clienti potenziali, ci siamo imbattuti in un ostacolo inaspettato. Nel video dimostrativo, la nostra tecnologia appariva e funzionava bene, qui non c'erano problemi. Il video mostrava esattamente come funzionava, senza alcuna simulazione. Abbiamo elaborato e codificato uno scenario di utilizzo realistico dell'app.


In realtà, questo divenne un problema. Il nostro demo funzionava esattamente come tutti gli altri facevano con le proprie applicazioni. In particolare, le informazioni venivano trasmesse istantaneamente da A a B, anche se si trattava di grandi file multimediali. Dopo aver effettuato il login, ogni utente vedeva le nuove registrazioni. Con l'app, diversi utenti potevano collaborare chiaramente su progetti specifici, anche in caso di disconnessione di Internet in una qualche località sperduta. Ciò è implicitamente suggerito in qualsiasi video sul prodotto montato in After Effects.

Nonostante tutti sapessero a cosa servisse il pulsante di aggiornamento, nessuno sembrava comprendere che le web app che ci chiedevano di creare erano generalmente soggette ai propri limiti. E che se non servissero più, l'esperienza utente sarebbe stata completamente diversa. In genere, notavano che si poteva "chattare", lasciando messaggi agli interlocutori, e quindi si chiedevano in cosa si differenziasse, ad esempio, da Slack. Uff!

Design delle sincronizzazioni quotidiane

Se hai già esperienza nello sviluppo software, dovrebbe irritarti il dover ricordare che la maggior parte delle persone non può semplicemente guardare un'immagine dell'interfaccia e capire cosa farà interagendo con essa. Per non parlare di ciò che accade all'interno stesso del programma. La consapevolezza di cosa può succedere — è in gran parte il risultato della conoscenza di ciò che non può e non dovrebbe accadere. Questo richiede modello mentale non solo di ciò che fa il software, ma anche di come le sue parti sono collegate e comunicano tra loro.

Un esempio classico di questo è l'utente che, per venti minuti, guarda spinner.gif, chiedendosi quando finalmente il lavoro si concluderà. Lo sviluppatore avrebbe capito che il processo probabilmente si era bloccato e che il gif non sarebbe mai scomparso dallo schermo. Questa animazione imita il completamento del lavoro, ma non è correlata al suo stato. In situazioni simili, alcuni tecnici amano alzare gli occhi al cielo, stupiti dalla misura dell'illusione degli utenti. Tuttavia, notate chi tra loro indica gli orologi che girano e dice che in realtà sono fermi?

Qui risiede il valore del tempo reale. Al giorno d'oggi, i database in tempo reale sono ancora utilizzati molto poco e molti li guardano con sospetto. La maggior parte di questi database tende ad inclinarsi verso lo stile NoSQL, il che porta generalmente a utilizzare soluzioni basate su Mongo, che è meglio dimenticare. Tuttavia, per me significa lavorare comodamente con CouchDB e apprendere a progettare strutture che possano essere riempite da dati non solo da qualche burocrate. Penso di trascorrere il mio tempo in modo più ottimale.

Ma il vero tema di questo post è ciò che utilizzo oggi. Non per scelta, ma a causa di una politica aziendale adottata con indifferenza e cecità. Quindi fornirò un confronto Completamente Onesto e Imparziale di due prodotti strettamente correlati per lavorare con i database in tempo reale di Google.

Entrambi hanno la parola Fire nei loro nomi. Uno lo ricordo con affetto. L'altro per me è un altro tipo di fuoco. Non ho fretta di dire i loro nomi, perché appena lo farò, ci troveremo di fronte al primo grande problema: i nomi.

Il primo si chiama Firebase Real-Time Database, e il secondo è Firebase Cloud Firestore. Entrambi sono prodotti della Firebase suite di Google. Le loro API sono chiamate, rispettivamente, firebase.database(…) e firebase.firestore(…).

È andata così perché Real-Time Database è semplicemente la versione originale di Firebase prima della sua acquisizione da parte di Google nel 2014. Poi, in Google, hanno deciso di creare un prodotto parallelo, una copia di Firebase basata sui big data dell'azienda, e l'hanno chiamata Firestore con cloud. Spero che non vi siate già persi. Se vi siete persi, non preoccupatevi, ho riscritto questa parte dell'articolo dieci volte.

Perché è necessario specificare Firebase riguardo a Firebase, e Firestore riguardo a Firebase, almeno per essere compresi alcuni anni fa su Stack Overflow.

Se ci fosse un premio per il peggior naming dei prodotti software, questo caso sarebbe sicuramente uno dei candidati. La distanza di Hamming tra questi nomi è così ridotta che confonde anche ingegneri esperti, le cui dita digitano un nome mentre la mente pensa a un altro. Questi sono piani falliti con grande clamore, concepiti con le migliori intenzioni; hanno adempiuto alla profezia che la banca dati sarebbe andata in fiamme. E non sto affatto scherzando. La persona che ha ideato tale schema di denominazione è stata la causa di sangue, sudore e lacrime.

Vittoria di Pirro

Si potrebbe pensare che Firestore sia una sostituzione di Firebase, il suo discendente di nuova generazione, ma sarebbe un errore. Firestore non può assolutamente essere considerato una sostituzione di Firebase. Sembra che qualcuno abbia rimosso tutto ciò che era interessante e abbia confuso gran parte di ciò che è rimasto in vari modi.

Tuttavia, uno sguardo superficiale ai due prodotti potrebbe confonderti: sembrano fare la stessa cosa, attraverso API sostanzialmente identiche e persino nella stessa sessione di database. Le differenze sono poco evidenti e si scoprono solo mediante un attento studio comparativo della documentazione dettagliata. O quando cerchi di portare un codice che funziona perfettamente su Firebase, affinché funzioni con Firestore. Già in quel momento scopri che l'interfaccia del database si accende non appena cerchi di eseguire il drag-and-drop in tempo reale. Ripeto, non sto scherzando.

Il client Firebase è gentile nel senso che bufferizza le modifiche e esegue automaticamente il tentativo di aggiornamenti, dando priorità all'ultima operazione di scrittura. Tuttavia, Firestore ha un limite di 1 operazione di scrittura per documento per utente al secondo, e questo limite è imposto dal server. Quando lavori con esso, devi trovare tu stesso un modo per aggirarlo e implementare un limitatore della frequenza degli aggiornamenti, anche quando stai semplicemente cercando di creare la tua applicazione. Vale a dire, Firestore è un database in tempo reale senza un client in tempo reale, che si maschera da tale attraverso l'API.

Con questo iniziamo a vedere i primi segni del senso di esistere di Firestore. Forse mi sbaglio, ma sospetto che qualcuno in alto nella dirigenza di Google, dopo aver acquistato Firebase, abbia semplicemente detto: «No, Dio mio, no. È inaccettabile. Non sotto la mia supervisione».

È uscito dalle sue stanze e ha proclamato:

«Un grande documento JSON? No. Dovete suddividere i dati in documenti separati, ognuno dei quali avrà una dimensione massima di 1 megabyte».

Sembra che tale limite non sopravvivrà al primo incontro con qualsiasi base utenti sufficientemente motivata. Lo sai che è così. Da noi, per esempio, abbiamo oltre mille e cinquecento presentazioni, ed è assolutamente normale.

Con tale limite, dovrete rassegnarvi al fatto che un «documento» nel database non assomiglierà a nessun oggetto che l'utente possa definire un documento.

«Array di array, che possono ricorsivamente contenere altri elementi? No. Gli array conterranno solo oggetti o numeri di lunghezza fissa, come previsto dal Signore».

Quindi, se speravate di inserire il vostro GeoJSON in Firestore, scoprirete che è impossibile. È inammissibile qualsiasi cosa multidimensionale. Spero che vi piaccia Base64 e/o JSON all'interno di JSON.

«Importazione ed esportazione JSON tramite HTTP, strumenti da riga di comando o pannello di amministrazione? No. Potrete solo esportare e importare dati in Google Cloud Storage. Così, sembra che si chiami ora. E quando dico 'voi', mi riferisco solo a coloro che hanno i diritti di Project Owner. Tutti gli altri possono andare a creare ticket.»

Come vedete, il modello dati FireBase è facile da descrivere. Contiene un unico enorme documento JSON, che collega le chiavi JSON con i percorsi URL. Se registrate usando HTTP PUT in / FireBase il seguente:

{
  "hello": "world"
}

Allora GET /hello restituirà "world". Fondamentalmente, funziona esattamente come vi aspettate. La collezione di oggetti FireBase /my-collection/:id è equivalente a un dizionario JSON {"my-collection": {...}} nella root, il cui contenuto è accessibile in /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

Funziona perfettamente se ogni inserimento ha ID senza collisioni, per cui nel sistema c'è una soluzione standard.

In altre parole, il database è compatibile al 100% con JSON (*) e funziona bene con HTTP, ad esempio con CouchDB. Ma, principalmente, lo usi tramite un'API in tempo reale, che astrae i websockets, l'autenticazione e le sottoscrizioni. Il pannello di amministrazione ha entrambe le funzionalità, permettendo sia la modifica in tempo reale che l'importazione/esportazione di JSON. Se nel tuo codice segui lo stesso approccio, rimarrai sorpreso di quanto codice specializzato scomparirà, quando capirai che patch e diff JSON risolvono il 90% delle attività di routine nella gestione dello stato persistente.

Il modello di dati Firestore è simile a JSON, ma differisce in alcuni aspetti critici. Ho già menzionato l'assenza di array all'interno di array. Il modello delle sub-collection è progettato affinché siano concetti di prima classe, separati dal documento JSON che le contiene. Poiché non esiste una serializzazione pronta per questo, è necessaria una via di esecuzione del codice specializzata per leggere e scrivere dati. Per gestire le proprie collezioni è necessario scrivere script e strumenti personalizzati. Il pannello di amministrazione consente di apportare solo piccole modifiche a un campo alla volta e non offre possibilità di importazione/esportazione.

Hanno preso un database NoSQL in tempo reale e lo hanno trasformato in un lento non-SQL con auto-unione e una colonna separata non-JSON. Qualcosa nello stile di GraftQL.

Java caldo

Se Firestore dovesse diventare più affidabile e scalabile, l'ironia è che il developer medio otterrà una soluzione meno affidabile rispetto a FireBase "out of the box". Il software necessario a un Amministratore di Database Brontolone richiede un livello di impegno e di competenza tali da risultare semplicemente irrealistico per la nicchia in cui, presumibilmente, dovrebbe esistere un buon prodotto. È simile a come l’HTML5 Canvas non possa sustituire Flash se non ci sono strumenti di sviluppo e un lettore. Inoltre, Firestore è afflitta da un eccesso di attenzione alla purezza dei dati e alla convalida sterile, che semplicemente non è in linea con il modo in cui un utente aziendale medio ama lavorare: per lui tutto è superfluo, perché fino alla fine tutto è un progetto in bozza.

Il principale svantaggio di FireBase è che il client è stato creato diversi anni prima del suo tempo, ancor prima che la maggior parte degli sviluppatori web scoprisse l'immutabilità. Per questo motivo, FireBase presume che tu stia modificando i dati e quindi non sfrutta i vantaggi offerti dall'immutabilità. Inoltre, non riutilizza i dati negli snapshot inviati all'utente, il che rende molto più difficile eseguire un diff. Per documenti di grandi dimensioni, il suo meccanismo di transazione basato su diff mutabili è semplicemente inadeguato. Ragazzi, abbiamo già WeakMap in JavaScript. È conveniente.

Se dai ai dati la forma giusta e non rendi gli alberi troppo voluminosi, puoi aggirare questo problema. Ma sono curioso di sapere se FireBase sarebbe molto più interessante se gli sviluppatori avessero rilasciato una vera e propria API client che utilizza l'immutabilità combinata con consigli pratici seri sulla struttura dei database. Invece, sembra che abbiano cercato di riparare ciò che non era rotto, e questo ha reso tutto peggiore.

Non conosco tutta la logica che ha portato alla creazione di Firestore. Speculare sulle motivazioni che sorgono all'interno di una black box è anch'essa parte del divertimento. Questa contrapposizione tra due database estremamente simili ma incomparabili è piuttosto rara. È come se qualcuno avesse pensato: «Firebase è semplicemente una funzione che possiamo emulare in Google Cloud», ma a quel punto non aveva ancora scoperto il concetto di definire i requisiti del mondo reale o di creare soluzioni utili che soddisfino tutti questi requisiti. «Lascia che ci pensino gli sviluppatori. Fai semplicemente l'interfaccia utente bella... E si può aggiungere più fuoco?»

Capisco un paio di cose riguardo alle strutture dati. Vedo chiaramente che il concetto di «tutto in un grande albero JSON» è un tentativo di astrarre da un database qualsiasi sentore di una struttura su larga scala. Aspettarsi che il software si occupi di qualsiasi dubbio frattale della struttura dati è pura follia. Non ho nemmeno bisogno di immaginare quanto possa essere malvagio tutto, ho eseguito audit rigorosi del codice e ho visto cose che voi umani non potete nemmeno immaginare.Ma so anche come appaiono buone strutture, come utilizzarle e e perché è necessario farlo.. Posso immaginare un mondo in cui Firestore sembrerebbe del tutto logico e le persone che l'hanno creata penserebbero di aver fatto un buon lavoro. Ma non viviamo in questo mondo.

Il supporto alla costruzione di query in FireBase è scarso secondo qualsiasi standard, praticamente non esiste. Ha sicuramente bisogno di miglioramenti o perlomeno di una revisione. Ma Firestore non è molto meglio, poiché è limitato agli stessi indici unidimensionali che si trovano in un semplice SQL. Se hai bisogno di query che le persone eseguono con dati disordinati, sono richiesti la ricerca testuale completa, filtri su più intervalli e un ordine definito liberamente dall'utente. Esaminando da vicino le funzionalità del semplice SQL, si scopre che esse sono troppo limitate. Inoltre, le uniche query SQL che le persone possono eseguire in produzione sono le query rapide. Avrai bisogno di una soluzione specializzata per l'indicizzazione con strutture dati ben progettate. Per tutto il resto, almeno dovrebbe esserci un map-reduce incrementale o qualcosa di simile.

Se cerchi informazioni al riguardo nella documentazione di Google, spero che ti indirizzino verso qualcosa come BigTable e BigQuery. Tuttavia, tutte queste soluzioni sono accompagnate da una quantità di gergo aziendale così fitta che tornerai rapidamente indietro e inizierai a cercare qualcos'altro.

Ultima cosa di cui hai bisogno se stai lavorando con un database in tempo reale è qualcosa creato da persone e per persone che lavorano su scala salariale per una direzione.

(*) È uno scherzo, non esiste un concetto come compatibilità al 100% con JSON.

In base alla pubblicità

Stai cercando VDS un server per lo sviluppo e il deployment dei tuoi progetti? Sei sicuramente il nostro cliente 🙂 Tariffe giornaliere per server di varie configurazioni, antiDDoS e licenze Windows già incluse nel prezzo.

Fonte: habr.com