Permeteu-me explicar una història tècnica.
Fa molts anys, estava desenvolupant una aplicació amb funcions de col·laboració incorporades. Era una pila experimental fàcil d'utilitzar que aprofitava tot el potencial de React i CouchDB primerencs. Ha sincronitzat les dades en temps real mitjançant JSON . S'utilitzava internament a l'empresa, però la seva àmplia aplicabilitat i potencial en altres àmbits era evident.
Mentre intentàvem vendre aquesta tecnologia a clients potencials, ens vam trobar amb un obstacle inesperat. Al vídeo de demostració, la nostra tecnologia semblava i funcionava molt bé, sense cap problema. El vídeo mostrava exactament com funciona i no imitava res. Hem creat i codificat un escenari realista per utilitzar el programa.
De fet, aquest es va convertir en el problema. La nostra demostració funcionava exactament de la mateixa manera que tothom simulava les seves aplicacions. Concretament, la informació es va transferir instantàniament d'A a B, encara que es tractés de fitxers multimèdia grans. Després d'iniciar sessió, cada usuari va veure entrades noves. Mitjançant l'aplicació, diferents usuaris podien treballar junts clarament en els mateixos projectes, encara que la connexió a Internet s'hagués interromput en algun lloc del poble. Això està implícit implícit en qualsevol tall de vídeo de producte a After Effects.
Tot i que tothom sabia per a què servia el botó Actualitzar, ningú no entenia realment que les aplicacions web que ens demanaven que creéssim normalment estaven subjectes a les seves pròpies limitacions. I que si ja no es necessiten, l'experiència de l'usuari serà completament diferent. Principalment es van adonar que podien "xerrar" deixant notes per a la gent amb qui parlaven, així que es van preguntar en què era diferent de, per exemple, Slack. Uf!
Disseny de sincronitzacions diàries
Si teniu experiència en desenvolupament de programari, ha de ser nerviós recordar que la majoria de la gent no només pot mirar una imatge d'una interfície i entendre què farà en interactuar amb ella. Per no parlar del que passa dins del mateix programa. Saber això llauna passar és en gran part el resultat de saber què no pot passar i què no hauria de passar. Això requereix no només el que fa el programari, sinó també com les seves parts individuals es coordinen i es comuniquen entre elles.
Un exemple clàssic d'això és un usuari mirant a spinner.gif, preguntant-se quan acabaran finalment els treballs. El desenvolupador s'hauria adonat que probablement el procés estava encallat i que el gif mai desapareixeria de la pantalla. Aquesta animació simula l'execució d'un treball, però no està relacionada amb el seu estat. En aquests casos, a alguns tècnics els agrada posar els ulls en blanc, sorpresos de l'abast de la confusió dels usuaris. Tanmateix, observeu quants d'ells apunten al rellotge giratori i diuen que en realitat està estacionari?
Aquesta és l'essència del valor en temps real. Actualment, les bases de dades en temps real són encara molt poc utilitzades i molta gent les veu amb sospita. La majoria d'aquestes bases de dades s'inclinen molt cap a l'estil NoSQL, per això solen utilitzar solucions basades en Mongo, que és millor oblidar. Tanmateix, per a mi això significa sentir-me còmode treballant amb CouchDB, així com aprendre a dissenyar estructures que més que un buròcrata pugui omplir de dades. Crec que estic utilitzant millor el meu temps.
Però el veritable tema d'aquesta publicació és el que estic fent servir avui. No per elecció, sinó per les polítiques corporatives aplicades de manera indiferent i cega. Per tant, oferiré una comparació completament justa i imparcial de dos productes de bases de dades de Google en temps real molt relacionats.
Tots dos tenen la paraula Foc en els seus noms. Una cosa que recordo amb afecte. La segona cosa per a mi és un tipus de foc diferent. No tinc pressa per dir els seus noms, perquè un cop ho faci, ens trobarem amb el primer gran problema: els noms.
El primer es diu Base de dades en temps real de Firebase, i segon - Firebase Cloud Firestore. Tots dos són productes de Suite Firebase Google. Les seves API s'anomenen respectivament firebase.database(…) и firebase.firestore(…).
Això va passar perquè Base de dades en temps real - Només és l'original Base de dades abans de la seva compra per Google el 2014. Llavors Google va decidir crear com a producte paral·lel còpia Firebase es basa en una empresa de big data i l'anomena Firestore amb un núvol. Espero que encara no estiguis confós. Si encara esteu confós, no us preocupeu, jo mateix he reescrit aquesta part de l'article deu vegades.
Perquè cal indicar Base de dades a la pregunta de Firebase i Firestore en una pregunta sobre Firebase, almenys per fer-vos entendre fa uns anys a Stack Overflow.
Si hi hagués un premi a la pitjor experiència de denominació de programari, aquest seria sens dubte un dels contendents. La distància de Hamming entre aquests noms és tan petita que confon fins i tot els enginyers experimentats els dits dels quals escriuen un nom mentre els seus caps pensen en un altre. Són plans ben intencionats que fracassen miserablement; van complir la profecia que la base de dades estaria en flames. I no estic en broma gens. La persona que va inventar aquest esquema de noms va causar sang, suor i llàgrimes.
Victòria pírrica
Es podria pensar que Firestore ho és reemplaçament Firebase, el seu descendent de pròxima generació, però això seria enganyós. No es garanteix que Firestore sigui un substitut adequat de Firebase. Sembla que algú n'ha retallat tot allò interessant i ha confós la majoria de la resta de diverses maneres.
Tanmateix, un cop d'ull ràpid als dos productes us pot confondre: sembla que fan el mateix, bàsicament mitjançant les mateixes API i fins i tot en la mateixa sessió de base de dades. Les diferències són subtils i només es revelen mitjançant un acurat estudi comparatiu d'una àmplia documentació. O quan intenteu portar un codi que funcioni perfectament a Firebase perquè funcioni amb Firestore. Fins i tot llavors descobreixes que la interfície de la base de dades s'il·lumina tan bon punt intentes arrossegar i deixar anar amb el ratolí en temps real. Repeteixo, no faig broma.
El client de Firebase és educat en el sentit que guarda els canvis i torna a provar automàticament les actualitzacions que donen prioritat a l'última operació d'escriptura. Tanmateix, Firestore té un límit d'1 operació d'escriptura per document per usuari i segon, i el servidor imposa aquest límit. Quan treballeu amb ell, depèn de vosaltres trobar una manera d'evitar-lo i implementar un limitador de velocitat d'actualització, fins i tot quan només esteu intentant crear la vostra aplicació. És a dir, Firestore és una base de dades en temps real sense un client en temps real, que es fa passar per una que utilitza una API.
Aquí comencem a veure els primers indicis de la raó de ser de Firestore. Potser m'equivoco, però sospito que algú alt en la gestió de Google va mirar Firebase després de la compra i simplement va dir: "No, Déu meu, no. Això és inacceptable. Simplement no sota el meu lideratge".
Va sortir de les seves cambres i va declarar:
"Un gran document JSON? No. Dividiràs les dades en documents separats, cadascun dels quals no tindrà una mida superior a 1 megabyte".
Sembla que aquesta limitació no sobreviurà a la primera trobada amb cap base d'usuaris prou motivada. Ja saps que ho és. A la feina, per exemple, tenim més d'un miler i mig de presentacions, i això és totalment normal.
Amb aquesta limitació, us veureu obligats a acceptar el fet que un "document" de la base de dades no s'assemblarà a cap objecte que un usuari pugui anomenar un document.
"Matrius de matrius que poden contenir de manera recursiva altres elements? No. Les matrius només contindran objectes o números de longitud fixa, com Déu volia".
Per tant, si teníeu l'esperança de posar GeoJSON al vostre Firestore, trobareu que això no és possible. Res no unidimensional és acceptable. Espero que us agradi Base64 i/o JSON dins de JSON.
"Importació i exportació de JSON mitjançant HTTP, eines de línia d'ordres o tauler d'administració? No. Només podreu exportar i importar dades a Google Cloud Storage. Així és com es diu ara, crec. I quan dic "tu", només em dirigeixo a aquells que tenen credencials de propietari del projecte. Tots els altres poden anar a crear entrades".
Com podeu veure, el model de dades de FireBase és fàcil de descriure. Conté un document JSON enorme que associa claus JSON amb camins d'URL. Si escrius amb HTTP PUT в / FireBase és el següent:
{
"hello": "world"
}
El GET /hello tornarà "world". Bàsicament funciona exactament com esperaries. Col·lecció d'objectes FireBase /my-collection/:id equivalent a un diccionari JSON {"my-collection": {...}} a l'arrel, el contingut del qual està disponible a /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Això funciona bé si cada inserció té una identificació sense col·lisions, per a la qual el sistema té una solució estàndard.
En altres paraules, la base de dades és 100% compatible amb JSON (*) i funciona molt bé amb HTTP, com ara CouchDB. Però bàsicament l'utilitzeu a través d'una API en temps real que resumeix els websockets, l'autorització i les subscripcions. El tauler d'administració té ambdues capacitats, que permeten tant l'edició en temps real com la importació/exportació de JSON. Si feu el mateix al vostre codi, us sorprendrà la quantitat de codi especialitzat que es malgastarà quan us adoneu que el pedaç i la diferència JSON resol el 90% de les tasques rutinàries de gestió de l'estat persistent.
El model de dades de Firestore és similar a JSON, però difereix d'algunes maneres crítiques. Ja he esmentat la manca de matrius dins de matrius. El model de les subcol·leccions és que siguin conceptes de primera classe, separats del document JSON que els conté. Com que no hi ha una serialització preparada per a això, es requereix una ruta de codi especialitzada per recuperar i escriure dades. Per processar les vostres pròpies col·leccions, heu d'escriure els vostres propis scripts i eines. El tauler d'administració només us permet fer petits canvis d'un camp a la vegada i no té capacitats d'importació/exportació.
Van agafar una base de dades NoSQL en temps real i la van convertir en una lent no SQL amb unió automàtica i una columna independent no JSON. Alguna cosa com GraftQL.
Java calenta
Si se suposava que Firestore era més fiable i escalable, la ironia és que el desenvolupador mitjà acabarà amb una solució menys fiable que escollir FireBase fora de la caixa. El tipus de programari que necessita l'administrador de bases de dades Grumpy requereix un nivell d'esforç i un calibre de talent que simplement no són realistes per al nínxol en què se suposa que és bo el producte. Això és semblant a com HTML5 Canvas no substitueix en absolut Flash si no hi ha eines de desenvolupament i un reproductor. A més, Firestore està embolicat en un desig de puresa de dades i validació estèril que simplement no s'alinea amb com l'usuari de negoci mitjà. li encanta treballar: per a ell tot és opcional, perquè fins al final tot és un esborrany.
El principal desavantatge de FireBase és que el client es va crear diversos anys abans del seu temps, abans que la majoria de desenvolupadors web coneguessin la immutabilitat. Per això, FireBase assumeix que canviareu les dades i, per tant, no aprofita la immutabilitat proporcionada per l'usuari. A més, no reutilitza les dades de les instantànies que passa a l'usuari, cosa que dificulta molt la diferència. Per a documents grans, el seu mecanisme de transacció basat en diferències mutables és simplement inadequat. Nois, ja ho tenim WeakMap en JavaScript. És còmode.
Si doneu a les dades la forma desitjada i no feu que els arbres siguin massa voluminosos, aquest problema es pot evitar. Però tinc curiositat per saber si FireBase seria molt més interessant si els desenvolupadors llancés una API de client molt bona que utilitzi la immutabilitat combinada amb alguns consells pràctics seriosos sobre el disseny de bases de dades. En canvi, semblava que intentaven arreglar allò que no estava trencat, i això ho va empitjorar.
No conec tota la lògica darrere de la creació de Firestore. Especular sobre els motius que sorgeixen dins de la caixa negra també forma part de la diversió. Aquesta juxtaposició de dues bases de dades extremadament similars però incomparables és força rara. És com algú pensava: "Firebase és només una funció que podem emular a Google Cloud", però encara no ha descobert el concepte d'identificar els requisits del món real o crear solucions útils que compleixin tots aquests requisits. "Que els desenvolupadors hi pensin. Fes que la IU sigui bonica... Pots afegir més foc?"
Entenc un parell de coses sobre les estructures de dades. Definitivament, veig el concepte "tot en un gran arbre JSON" com un intent d'abstraure qualsevol sentit d'estructura a gran escala de la base de dades. Esperar que el programari faci front a qualsevol estructura de dades dubtosa fractal és simplement una bogeria. Ni tan sols m'he d'imaginar com de dolentes podrien ser les coses, he fet auditories de codi rigoroses i Vaig veure coses que mai heu somiat. Però també sé com són les bones estructures, и . Puc imaginar un món on Firestore semblaria lògic i la gent que el va crear pensaria que va fer una bona feina. Però no vivim en aquest món.
El suport de consultes de FireBase és deficient per a qualsevol estàndard i és pràcticament inexistent. Definitivament necessita una millora o almenys una revisió. Però Firestore no és molt millor perquè es limita als mateixos índexs unidimensionals que es troben a l'SQL normal. Si necessiteu consultes que la gent executi sobre dades caòtiques, necessiteu cerca de text complet, filtres de diversos rangs i ordres personalitzats definits per l'usuari. En una inspecció més detinguda, les funcions de l'SQL normal són massa limitades per si soles. A més, les úniques consultes SQL que les persones poden executar en producció són les consultes ràpides. Necessitareu una solució d'indexació personalitzada amb estructures de dades intel·ligents. Per a la resta, almenys hi hauria d'haver una reducció de mapes incremental o alguna cosa semblant.
Si cerqueu a Google Docs informació sobre això, esperem que us apuntin cap a alguna cosa com ara BigTable i BigQuery. Tot i això, totes aquestes solucions s'acompanyen d'un argot tan dens de vendes corporatives que ràpidament tornaràs enrere i començaràs a buscar una altra cosa.
L'últim que voleu amb una base de dades en temps real és quelcom fet per i per a persones amb escales salarials de gestió.
(*) Això és una broma, no n'hi ha .
Sobre els drets de publicitat
Buscant per a projectes de depuració, un servidor per al desenvolupament i l'allotjament? Definitivament ets el nostre client 🙂 Els preus diaris per a servidors de diverses configuracions, llicències anti-DDoS i Windows ja estan inclosos en el preu.
Font: www.habr.com