Dovoľte mi povedať technický príbeh.
Pred mnohými rokmi som vyvíjal aplikáciu so zabudovanými funkciami spolupráce. Bol to užívateľsky prívetivý experimentálny zásobník, ktorý využíval plný potenciál skorých React a CouchDB. Synchronizoval dáta v reálnom čase cez JSON . Používal sa interne v rámci spoločnosti, no jeho široká použiteľnosť a potenciál v iných oblastiach bola jasná.
Pri pokuse predať túto technológiu potenciálnym klientom sme narazili na nečakanú prekážku. V demo videu naša technológia vyzerala a fungovala skvele, žiadne problémy. Video presne ukázalo, ako to funguje a nič nenapodobňovalo. Vymysleli sme a nakódovali realistický scenár používania programu.
V skutočnosti sa to stalo problémom. Naše demo fungovalo presne tak, ako všetci ostatní simulovali svoje aplikácie. Konkrétne, informácie boli okamžite prenesené z A do B, aj keď išlo o veľké mediálne súbory. Po prihlásení sa každému používateľovi zobrazili nové záznamy. Pomocou aplikácie mohli rôzni používatelia jasne spolupracovať na rovnakých projektoch, aj keď bolo niekde v dedine prerušené internetové pripojenie. Toto je implicitne zahrnuté v akomkoľvek produktovom videu zostrihanom v After Effects.
Hoci každý vedel, na čo slúži tlačidlo Obnoviť, nikto v skutočnosti nechápal, že webové aplikácie, o ktorých zostavenie nás požiadali, zvyčajne podliehajú ich vlastným obmedzeniam. A že ak už nebudú potrebné, používateľský zážitok bude úplne iný. Väčšinou si všimli, že môžu „chatovať“ zanechávaním poznámok ľuďom, s ktorými sa rozprávali, a tak ich zaujímalo, ako sa to líši od napríklad Slacka. Fíha!
Dizajn každodenných synchronizácií
Ak máte skúsenosti s vývojom softvéru, musí byť nervy drásajúce si uvedomiť, že väčšina ľudí sa nemôže len pozrieť na obrázok rozhrania a pochopiť, čo urobí pri interakcii s ním. Nehovoriac o tom, čo sa deje vo vnútri samotného programu. Vedomosti, že plechovka stať je do značnej miery výsledkom poznania toho, čo sa nemôže stať a čo by sa stať nemalo. To si vyžaduje nielen to, čo softvér robí, ale aj to, ako sú jeho jednotlivé časti koordinované a navzájom komunikujú.
Klasickým príkladom toho je používateľ hľadiaci na a spinner.gif, zvedavý, kedy budú práce konečne dokončené. Vývojár by si uvedomil, že proces sa pravdepodobne zasekol a že gif nikdy nezmizne z obrazovky. Táto animácia simuluje vykonávanie úlohy, ale nesúvisí s jej stavom. V takýchto prípadoch niektorí technici radi prevracajú očami, prekvapení mierou zmätku používateľov. Všimnite si však, koľkí z nich ukazujú na rotujúce hodiny a hovoria, že v skutočnosti stoja?
Toto je podstata hodnoty v reálnom čase. V súčasnosti sú databázy v reálnom čase stále veľmi málo využívané a veľa ľudí sa na ne pozerá s nedôverou. Väčšina týchto databáz sa výrazne prikláňa k štýlu NoSQL, a preto zvyčajne používajú riešenia založené na Mongo, na ktoré je najlepšie zabudnúť. Pre mňa to však znamená pohodlne pracovať s CouchDB, ako aj naučiť sa navrhovať štruktúry, ktoré dokáže naplniť dátami nielen nejaký byrokrat. Myslím, že svoj čas využívam lepšie.
Ale skutočnou témou tohto príspevku je to, čo používam dnes. Nie z vlastnej vôle, ale kvôli ľahostajne a slepo uplatňovanej firemnej politike. Poskytnem teda úplne spravodlivé a nezaujaté porovnanie dvoch úzko súvisiacich databázových produktov Google v reálnom čase.
Obaja majú v názve slovo Oheň. Na jednu vec rád spomínam. Druhá vec je pre mňa iný typ ohňa. Neponáhľam sa povedať ich mená, pretože keď to urobím, narazíme na prvý veľký problém: mená.
Prvý sa volá Databáza v reálnom čase Firebasea druhá - Firebase Cloud Firestore. Oba sú produkty z Súprava Firebase Google. Ich API sa nazývajú resp firebase.database(…) и firebase.firestore(…).
Stalo sa to preto Databáza v reálnom čase - je to len originál Firebase pred jeho kúpou spoločnosťou Google v roku 2014. Potom sa Google rozhodol vytvoriť ako paralelný produkt kópia Firebase je založená na veľkej dátovej spoločnosti a nazvala ju Firestore s cloudom. Dúfam, že ešte nie ste zmätení. Ak ste stále zmätení, nebojte sa, sám som túto časť článku prepísal desaťkrát.
Pretože musíte uviesť Firebase v otázke Firebase a Ohnisko v otázke o Firebase, aspoň aby ste pochopili pred pár rokmi na Stack Overflow.
Ak by existovalo ocenenie za najhoršiu skúsenosť s pomenovaním softvéru, toto by bol určite jeden z uchádzačov. Hammingova vzdialenosť medzi týmito menami je taká malá, že mätie aj skúsených inžinierov, ktorých prsty píšu jedno meno, zatiaľ čo ich hlavy premýšľajú o inom. Sú to dobre mienené plány, ktoré žalostne zlyhajú; splnili proroctvo, že databáza bude v plameňoch. A to si vôbec nerobím srandu. Osoba, ktorá prišla s touto schémou pomenovania, spôsobila krv, pot a slzy.
Pyrrhické víťazstvo
Človek by si myslel, že Firestore je výmena Firebase, jeho potomok ďalšej generácie, ale to by bolo zavádzajúce. Firestore nie je zaručené ako vhodná náhrada za Firebase. Vyzerá to tak, že niekto z nej vystrihol všetko zaujímavé a väčšinu zvyšku rôznymi spôsobmi poplietol.
Krátky pohľad na tieto dva produkty vás však môže zmiasť: zdá sa, že robia to isté, v podstate prostredníctvom rovnakých rozhraní API a dokonca v rovnakej databázovej relácii. Rozdiely sú jemné a odhalí ich až starostlivé porovnávacie štúdium rozsiahlej dokumentácie. Alebo keď sa pokúšate preniesť kód, ktorý perfektne funguje na Firebase, aby fungoval s Firestore. Aj vtedy zistíte, že rozhranie databázy sa rozsvieti hneď, ako sa pokúsite pretiahnuť myšou v reálnom čase. Opakujem, nežartujem.
Klient Firebase je zdvorilý v tom zmysle, že ukladá zmeny do vyrovnávacej pamäte a automaticky sa pokúša o aktualizácie, ktoré uprednostňujú poslednú operáciu zápisu. Firestore má však limit 1 operácie zápisu na dokument na používateľa za sekundu a tento limit vynucuje server. Pri práci s ním je len na vás, ako ho obísť a implementovať obmedzovač rýchlosti aktualizácie, aj keď sa práve snažíte zostaviť svoju aplikáciu. To znamená, že Firestore je databáza v reálnom čase bez klienta v reálnom čase, ktorý sa maskuje ako databáza využívajúca API.
Tu začíname vidieť prvé náznaky raison d'être Firestore. Možno sa mýlim, ale mám podozrenie, že niekto vysoko z vedenia Google sa po kúpe pozrel na Firebase a jednoducho povedal: „Nie, bože, nie. To je neprijateľné. Len nie pod mojím vedením."
Vyšiel zo svojich komnát a vyhlásil:
„Jeden veľký dokument JSON? Nie Údaje rozdelíte do samostatných dokumentov, z ktorých každý nebude mať veľkosť väčšiu ako 1 megabajt.“
Zdá sa, že takéto obmedzenie neprežije prvé stretnutie s akoukoľvek dostatočne motivovanou užívateľskou základňou. Vieš, že je. V práci máme napríklad viac ako jeden a pol tisíc prezentácií, a to je úplne normálne.
S týmto obmedzením budete nútení akceptovať fakt, že jeden „dokument“ v databáze sa nebude podobať žiadnemu objektu, ktorý by používateľ mohol nazvať dokumentom.
„Polia polí, ktoré môžu rekurzívne obsahovať ďalšie prvky? Nie Polia budú obsahovať iba predmety alebo čísla s pevnou dĺžkou, ako to Boh zamýšľal."
Ak ste teda dúfali, že GeoJSON umiestnite do svojho Firestore, zistíte, že to nie je možné. Nič, čo nie je jednorozmerné, nie je prijateľné. Dúfam, že sa vám páči Base64 a / alebo JSON v rámci JSON.
„Import a export JSON cez HTTP, nástroje príkazového riadka alebo panel správcu? Nie Údaje budete môcť exportovať a importovať iba do úložiska Google Cloud Storage. Tak sa to tuším teraz volá. A keď hovorím „vy“, oslovujem len tých, ktorí majú poverenia vlastníka projektu. Všetci ostatní môžu ísť a vytvárať lístky.“
Ako vidíte, dátový model FireBase sa dá ľahko opísať. Obsahuje jeden obrovský dokument JSON, ktorý spája kľúče JSON s cestami URL. Ak píšete s HTTP PUT в / FireBase je nasledujúci:
{
"hello": "world"
}
potom GET /hello vráti sa "world". V podstate to funguje presne tak, ako by ste očakávali. Zbierka objektov FireBase /my-collection/:id ekvivalentné slovníku JSON {"my-collection": {...}} v koreni, ktorého obsah je dostupný v /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Funguje to dobre, ak má každá vložka bezkolízne ID, pre ktoré má systém štandardné riešenie.
Inými slovami, databáza je 100% kompatibilná s JSON(*) a funguje skvele s HTTP, ako je CouchDB. V zásade ho však používate prostredníctvom rozhrania API v reálnom čase, ktoré abstrahuje webové zásuvky, autorizáciu a predplatné. Správcovský panel má obe možnosti a umožňuje úpravy v reálnom čase aj import/export JSON. Ak urobíte to isté vo svojom kóde, budete prekvapení, koľko špecializovaného kódu sa premrhá, keď si uvedomíte, že patch a diff JSON rieši 90 % rutinných úloh spracovania pretrvávajúceho stavu.
Dátový model Firestore je podobný JSON, ale líši sa v niektorých kritických smeroch. Už som spomenul nedostatok polí v poliach. Modelom pre podkolekcie je, aby boli prvotriednymi konceptmi, oddelenými od dokumentu JSON, ktorý ich obsahuje. Keďže na to neexistuje žiadna pripravená serializácia, na získavanie a zapisovanie údajov je potrebná špecializovaná cesta kódu. Na spracovanie vlastných kolekcií si musíte napísať vlastné skripty a nástroje. Správcovský panel vám umožňuje vykonávať malé zmeny iba v jednom poli a nemá možnosti importu/exportu.
Vzali databázu NoSQL v reálnom čase a zmenili ju na pomalú non-SQL s automatickým pripojením a samostatným stĺpcom bez JSON. Niečo ako GraftQL.
Horúca Java
Ak mal byť Firestore spoľahlivejší a škálovateľnejší, potom je iróniou, že priemerný vývojár skončí s menej spoľahlivým riešením, ako je výber FireBase hneď po vybalení. Softvér, ktorý potrebuje správca databázy Grumpy, si vyžaduje úroveň úsilia a talentu, ktorý je jednoducho nereálny pre oblasť, v ktorej má byť produkt dobrý. Je to podobné, ako keď HTML5 Canvas vôbec nenahrádza Flash, ak neexistujú žiadne vývojárske nástroje a prehrávač. Firestore je navyše utopený v túžbe po čistote údajov a sterilnej validácii, ktorá jednoducho nezodpovedá tomu, ako priemerný podnikový používateľ rád pracuje: pre neho je všetko voliteľné, pretože až do konca je všetko návrh.
Hlavnou nevýhodou FireBase je, že klient bol vytvorený niekoľko rokov pred svojou dobou, kým väčšina webových vývojárov nevedela o nemennosti. Z tohto dôvodu FireBase predpokladá, že zmeníte údaje, a preto nevyužíva výhodu nemennosti poskytovanej používateľom. Okrem toho opätovne nepoužíva údaje v snímkach, ktoré odovzdáva používateľovi, čo značne sťažuje porovnávanie. Pre veľké dokumenty je jeho premenlivý transakčný mechanizmus založený na rozdieloch jednoducho neadekvátny. Chlapci, už máme WeakMap v JavaScripte. Je to pohodlné.
Ak dáte údajom požadovaný tvar a nerobíte stromy príliš objemnými, potom sa tento problém dá obísť. Som však zvedavý, či by FireBase bola oveľa zaujímavejšia, keby vývojári vydali skutočne dobré klientske API, ktoré by využívalo nemennosť v kombinácii s niektorými serióznymi praktickými radami o návrhu databázy. Namiesto toho sa zdalo, že sa snažia opraviť to, čo nebolo pokazené, a tým to bolo ešte horšie.
Nepoznám všetku logiku, ktorá stojí za vytvorením Firestore. Špekulovanie o motívoch, ktoré vznikajú vo vnútri čiernej skrinky, je tiež súčasťou zábavy. Toto porovnanie dvoch extrémne podobných, ale neporovnateľných databáz je pomerne zriedkavé. Akoby si niekto myslel: „Firebase je len funkcia, ktorú môžeme napodobniť v Google Cloud“, ale ešte neobjavil koncept identifikácie skutočných požiadaviek alebo vytvárania užitočných riešení, ktoré spĺňajú všetky tieto požiadavky. „Nech si to vývojári premyslia. Len urobte používateľské rozhranie krásne... Môžete pridať viac ohňa?“
Rozumiem niekoľkým veciam o dátových štruktúrach. Koncept „všetko v jednom veľkom strome JSON“ rozhodne vnímam ako pokus abstrahovať z databázy akýkoľvek zmysel pre rozsiahlu štruktúru. Očakávať od softvéru, že sa jednoducho vyrovná s akýmkoľvek pochybným fraktálom dátovej štruktúry, je jednoducho šialené. Nemusím si ani predstavovať, aké zlé veci môžu byť, urobil som prísne audity kódu a Videl som veci, o ktorých sa vám ani nesnívalo. Ale tiež viem, ako vyzerajú dobré štruktúry, и . Viem si predstaviť svet, kde by sa Firestore zdalo logické a ľudia, ktorí ho vytvorili, by si mysleli, že odviedli dobrú prácu. Ale nežijeme v tomto svete.
Podpora dopytov FireBase je podľa akéhokoľvek štandardu slabá a prakticky neexistuje. Určite to potrebuje zlepšenie alebo aspoň revíziu. Firestore však nie je oveľa lepší, pretože je obmedzený na rovnaké jednorozmerné indexy, aké sa nachádzajú v obyčajnom SQL. Ak potrebujete dopyty, ktoré ľudia spúšťajú na chaotických údajoch, potrebujete fulltextové vyhľadávanie, filtre s viacerými rozsahmi a vlastné užívateľom definované zoradenie. Pri bližšom skúmaní sú funkcie obyčajného SQL príliš obmedzené samy o sebe. Okrem toho jediné SQL dotazy, ktoré môžu ľudia spustiť v produkcii, sú rýchle dotazy. Budete potrebovať vlastné riešenie indexovania s inteligentnými dátovými štruktúrami. Pre všetko ostatné by malo existovať aspoň inkrementálne zmenšenie mapy alebo niečo podobné.
Ak o tom budete hľadať informácie v Dokumentoch Google, dúfajme, že vás nasmeruje niečo ako BigTable a BigQuery. Všetky tieto riešenia však sprevádza taký hutný firemný predajný žargón, že sa rýchlo otočíte späť a začnete hľadať niečo iné.
Posledná vec, ktorú by ste chceli s databázou v reálnom čase, je niečo, čo vytvorili ľudia na platových stupňoch manažmentu a pre nich.
(*) To je vtip, nič také neexistuje .
O právach reklamy
Hľadám pre ladiace projekty, server pre vývoj a hosting? Určite ste naším klientom 🙂 Denné ceny serverov rôznych konfigurácií, anti-DDoS a Windows licencií sú už zahrnuté v cene.
Zdroj: hab.com