Hadd meséljek el egy technikai történetet.
Sok évvel ezelőtt egy olyan alkalmazást fejlesztettem, amelybe együttműködési funkciókat építettem. Ez egy felhasználóbarát kísérleti verem volt, amely kihasználta a korai React és a CouchDB teljes potenciálját. Valós időben szinkronizálta az adatokat JSON-on keresztül . A vállalaton belül alkalmazták, de széleskörű alkalmazhatósága és lehetőségei más területeken egyértelműek voltak.
Miközben megpróbáltuk eladni ezt a technológiát potenciális ügyfeleknek, váratlan akadályba ütköztünk. A bemutató videón a technológiánk remekül nézett ki és működött, nem volt probléma. A videó pontosan megmutatta, hogyan működik, és nem imitált semmit. Kidolgoztunk és kódoltunk egy reális forgatókönyvet a program használatához.
Valójában ez lett a probléma. A bemutatónk pontosan úgy működött, ahogy mindenki más szimulálta az alkalmazásait. Pontosabban, az információ azonnal átkerült A-ból B-be, még akkor is, ha nagy médiafájlokról van szó. Bejelentkezés után minden felhasználó új bejegyzéseket látott. Az alkalmazás használatával a különböző felhasználók egyértelműen együtt dolgozhattak ugyanazon projekteken, még akkor is, ha valahol a faluban megszakadt az internetkapcsolat. Ez implicit módon benne van az After Effects bármely termékvideójában.
Annak ellenére, hogy mindenki tudta, mire való a Frissítés gomb, senki sem értette igazán, hogy az általuk készített webalkalmazásokra általában saját korlátai vonatkoznak. És hogy ha már nincs rájuk szükség, teljesen más lesz a felhasználói élmény. Leginkább azt vették észre, hogy úgy tudnak „csevegni”, hogy jegyzeteket hagynak azoknak, akikkel beszélgetnek, ezért kíváncsiak voltak, miben más ez, mint például a Slack. Fú!
A mindennapi szinkronok tervezése
Ha van tapasztalata szoftverfejlesztésben, idegtépőnek kell emlékeznie arra, hogy a legtöbb ember nem tudja csak nézni egy interfész képét, és megérteni, hogy az interfész mit fog tenni, amikor kapcsolatba lép vele. Arról nem is beszélve, hogy mi történik magában a programban. Ennek ismerete képes megtörténni nagyrészt annak az eredménye, hogy tudjuk, mi nem történhet meg, és minek nem szabad megtörténnie. Ez megköveteli nemcsak azt, hogy mit csinál a szoftver, hanem azt is, hogy egyes részei hogyan vannak összehangolva és hogyan kommunikálnak egymással.
Ennek klasszikus példája a felhasználó, aki a spinner.gif, vajon mikor készül el végre a munka. A fejlesztő rájött volna, hogy a folyamat valószínűleg elakadt, és a gif soha nem fog eltűnni a képernyőről. Ez az animáció egy feladat végrehajtását szimulálja, de nem kapcsolódik annak állapotához. Ilyenkor egyes technikusok szívesen lesütik a szemüket, elképedve a felhasználók zavarodottságának mértékén. Figyeld meg azonban, hányan mutatnak a forgó órára, és mondják, hogy az valójában álló helyzetben van?
Ez a valós idejű érték lényege. Manapság a valós idejű adatbázisokat még mindig nagyon kevesen használják, és sokan gyanakodva nézik őket. A legtöbb ilyen adatbázis erősen a NoSQL stílus felé hajlik, ezért általában Mongo alapú megoldásokat használnak, amelyeket a legjobb elfelejteni. Számomra azonban ez azt jelenti, hogy kényelmesen dolgozhatok a CouchDB-vel, valamint meg kell tanulnom olyan struktúrákat tervezni, amelyeket nem csak egy bürokrata tud megtölteni adatokkal. Azt hiszem, jobban kihasználom az időmet.
De ennek a bejegyzésnek az igazi témája az, amit ma használok. Nem akaratból, hanem a közömbösen és vakon alkalmazott vállalati politika miatt. Így két, egymással szorosan összefüggő Google valós idejű adatbázis-termék teljesen tisztességes és elfogulatlan összehasonlítását adok.
Mindkettő nevében szerepel a Tűz szó. Egy dologra szívesen emlékszem vissza. A második dolog számomra egy másfajta tűz. Nem sietek a nevük kimondásával, mert ha megteszem, az első nagy problémába ütközünk: a nevekkel.
Az elsőt úgy hívják Firebase valós idejű adatbázisés a második - Firebase Cloud Firestore. Mindkettő terméke Firebase lakosztály Google. Az API-jukat ennek megfelelően hívják firebase.database(…) и firebase.firestore(…).
Ez azért történt, mert Valós idejű adatbázis - ez csak az eredeti Firebase mielőtt a Google megvásárolta volna 2014-ben. Aztán a Google úgy döntött, hogy párhuzamos terméket készít másolat A Firebase nagy adatforgalmi vállalaton alapul, és Firestore-nak hívta felhővel. Remélem még nem vagy összezavarodva. Ha még mindig tanácstalan vagy, ne aggódj, én magam írtam át a cikknek ezt a részét tízszer.
Mert jelezni kell Firebase a Firebase kérdésben, és Firestore egy Firebase-re vonatkozó kérdésben, legalábbis néhány évvel ezelőtt a Stack Overflow-n érthető.
Ha a legrosszabb szoftverelnevezési élményért díjat kapna, akkor ez minden bizonnyal az egyik esélyes lenne. A Hamming-távolság e nevek között olyan kicsi, hogy még a tapasztalt mérnököket is megzavarja, akiknek az ujjaik beírják az egyik nevet, miközben a fejük egy másikon gondolkodik. Jó szándékú tervek ezek, amelyek csúnyán kudarcot vallanak; beteljesítették a jóslatot, miszerint égni fog az adatbázis. És egyáltalán nem viccelek. Az a személy, aki ezt az elnevezési rendszert kitalálta, vért, verejtéket és könnyeket okozott.
pirrhuszi győzelem
Azt hinné az ember, hogy a Firestore az csere Firebase, a következő generációs leszármazottja, de ez félrevezető lenne. A Firestore nem garantáltan helyettesíti a Firebase-t. Úgy tűnik, valaki minden érdekeset kivágott belőle, a többit pedig különböző módon összezavarta.
Azonban egy gyors pillantás a két termékre megzavarhatja Önt: úgy tűnik, ugyanazt csinálják, alapvetően ugyanazon API-kon keresztül, sőt ugyanabban az adatbázis-munkamenetben. A különbségek finomak, és csak a kiterjedt dokumentáció alapos összehasonlító tanulmányozása tárja fel őket. Vagy amikor olyan kódot próbál portolni, amely tökéletesen működik a Firebase-en, hogy működjön a Firestore-al. Még ekkor is rájössz, hogy az adatbázis-felület azonnal felgyullad, amint valós időben próbálja meg az egérrel húzni. Ismétlem, nem viccelek.
A Firebase-ügyfél udvarias abban az értelemben, hogy puffereli a változásokat, és automatikusan újrapróbálja azokat a frissítéseket, amelyek elsőbbséget adnak az utolsó írási műveletnek. A Firestore azonban legfeljebb 1 írási műveletet írhat be dokumentumonként és felhasználónként másodpercenként, és ezt a korlátozást a szerver kényszeríti ki. Amikor dolgozik vele, Önnek kell megtalálnia a kikerülési utat, és bevezetnie a frissítési sebesség-korlátozót, még akkor is, ha éppen az alkalmazást próbálja felépíteni. Ez azt jelenti, hogy a Firestore egy valós idejű adatbázis valós idejű kliens nélkül, amely API-t használó adatbázisnak álcázza magát.
Itt kezdjük látni a Firestore létjogosultságának első jeleit. Lehet, hogy tévedek, de gyanítom, hogy a Google vezetői közül valaki a vásárlás után ránézett a Firebase-re, és csak annyit mondott: „Nem, istenem, nem. Ez elfogadhatatlan. Csak nem az én vezetésem alatt."
Kijött a szobáiból, és kijelentette:
„Egy nagy JSON-dokumentum? Nem. Az adatokat különálló dokumentumokra osztja fel, amelyek mérete nem haladhatja meg az 1 megabájtot.
Úgy tűnik, hogy egy ilyen korlátozás nem éli túl az első találkozást a kellően motivált felhasználói bázissal. Tudod, hogy az. A munkahelyen például több mint másfélezer előadást tartunk, és ez teljesen normális.
Ezzel a korlátozással kénytelen lesz elfogadni azt a tényt, hogy az adatbázisban lévő "dokumentum" nem fog hasonlítani egyetlen olyan objektumra sem, amelyet a felhasználó dokumentumnak nevezhet.
"Tömbök tömbjei, amelyek rekurzív módon tartalmazhatnak más elemeket? Nem. A tömbök csak fix hosszúságú objektumokat vagy számokat tartalmaznak, ahogy Isten szándéka volt."
Tehát ha azt remélte, hogy a GeoJSON-t a Firestore-jába helyezi, akkor azt fogja tapasztalni, hogy ez nem lehetséges. Semmi nem egydimenziós nem elfogadható. Remélem, tetszik a Base64 és/vagy a JSON a JSON-on belül.
„JSON importálás és exportálás HTTP-n, parancssori eszközökön vagy adminisztrációs panelen keresztül? Nem. Csak adatokat exportálhat és importálhat a Google Cloud Storage szolgáltatásba. Azt hiszem, most így hívják. És amikor azt mondom, hogy „te”, akkor csak azoknak szólok, akiknek projekttulajdonos hitelesítő adatai vannak. Mindenki más mehet és készíthet jegyeket."
Amint láthatja, a FireBase adatmodellt könnyű leírni. Egy hatalmas JSON-dokumentumot tartalmaz, amely a JSON-kulcsokat URL-útvonalakhoz társítja. Ha azzal írsz HTTP PUT в / A FireBase a következő:
{
"hello": "world"
}
az GET /hello vissza fog térni "world". Alapvetően pontosan úgy működik, ahogy elvárnád. FireBase objektumok gyűjteménye /my-collection/:id egy JSON-szótárnak felel meg {"my-collection": {...}} a gyökérben, melynek tartalma ben érhető el /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Ez akkor működik jól, ha minden betétnek van ütközésmentes azonosítója, amelyre a rendszer rendelkezik egy szabványos megoldással.
Más szavakkal, az adatbázis 100%-ban JSON(*) kompatibilis, és kiválóan működik HTTP-vel, például a CouchDB-vel. De alapvetően egy valós idejű API-n keresztül használja, amely kivonja a websocketeket, az engedélyezést és az előfizetéseket. Az adminisztrációs panel mindkét funkcióval rendelkezik, lehetővé téve a valós idejű szerkesztést és a JSON importálást/exportálást. Ha ugyanezt teszed a kódodban, meg fogsz lepődni, hogy mennyi speciális kód megy kárba, amikor rájössz, hogy a patch and diff JSON megoldja a perzisztens állapot kezelésének rutinfeladatainak 90%-át.
A Firestore adatmodell hasonló a JSON-hoz, de néhány kritikus szempontból eltér. Már említettem a tömbök hiányát a tömbökön belül. Az algyűjtemények modellje szerint első osztályú fogalmaknak kell lenniük, elkülönülve az őket tartalmazó JSON-dokumentumtól. Mivel erre nincs kész szerializáció, az adatok lekéréséhez és írásához speciális kódútvonal szükséges. Saját gyűjteményeinek feldolgozásához saját szkripteket és eszközöket kell megírnia. Az adminisztrációs panel csak egy mezőben teszi lehetővé a kis módosítások végrehajtását, és nem rendelkezik importálási/exportálási lehetőségekkel.
Vettek egy valós idejű NoSQL adatbázist, és lassú nem SQL-vé alakították, automatikus csatlakozással és külön nem JSON oszloppal. Valami olyan, mint a GraftQL.
Forró Java
Ha a Firestore-nak megbízhatóbbnak és skálázhatóbbnak kellett volna lennie, akkor az irónia az, hogy az átlagos fejlesztők kevésbé megbízható megoldást kapnak, mint a FireBase-t. Az a fajta szoftver, amelyre a Grumpy adatbázis-adminisztrátornak szüksége van, olyan szintű erőfeszítést és tehetséget igényel, amely egyszerűen irreális abban a résben, amelyben a terméknek jónak kell lennie. Ez hasonló ahhoz, hogy a HTML5 Canvas egyáltalán nem helyettesíti a Flash-t, ha nincsenek fejlesztői eszközök és lejátszó. Ezenkívül a Firestore belemerült az adattisztaság és a steril érvényesítés iránti vágyba, amely egyszerűen nem illeszkedik az átlagos üzleti felhasználókhoz. szeret dolgozni: neki minden nem kötelező, mert a végsőkig minden csak piszkozat.
A FireBase fő hátránya, hogy a klienst több évvel kora előtt hozták létre, még azelőtt, hogy a legtöbb webfejlesztő tudott volna a megváltoztathatatlanságról. Emiatt a FireBase azt feltételezi, hogy Ön módosítja az adatokat, ezért nem használja ki a felhasználó által biztosított változatlanságot. Ezenkívül nem használja fel újra a pillanatképek adatait, amelyeket átad a felhasználónak, ami sokkal nehezebbé teszi a differenciálást. Nagy dokumentumok esetén a változtatható diff-alapú tranzakciós mechanizmus egyszerűen nem megfelelő. Srácok, már megvan WeakMap JavaScriptben. Kényelmes.
Ha megadja az adatoknak a kívánt formát, és nem teszi túl terjedelmessé a fákat, akkor ez a probléma megkerülhető. De kíváncsi vagyok, hogy a FireBase sokkal érdekesebb lenne-e, ha a fejlesztők egy igazán jó kliens API-t adnának ki, amely változatlanságot és komoly gyakorlati tanáccsal kombinál az adatbázis-tervezésben. Ehelyett úgy tűnt, hogy megpróbálták megjavítani azt, ami nem romlott el, és ez csak tovább rontott.
Nem ismerem a Firestore létrehozásának minden logikáját. A móka része a fekete dobozban felmerülő motívumokról való találgatás is. Két rendkívül hasonló, de összehasonlíthatatlan adatbázis ilyen szembeállítása meglehetősen ritka. Mintha valaki azt gondolta volna: "A Firebase csak egy funkció, amelyet emulálni tudunk a Google Cloudban", de még nem fedezte fel a valós követelmények azonosításának koncepcióját vagy olyan hasznos megoldások létrehozását, amelyek megfelelnek ezeknek a követelményeknek. „A fejlesztők gondolkodjanak ezen. Csak szépítsd a felhasználói felületet... Tudsz még tüzet rakni?”
Pár dolgot értek az adatstruktúrákkal kapcsolatban. A „mindent egy nagy JSON-fában” koncepciót határozottan úgy tekintem, mint egy kísérletet arra, hogy elvonja az adatbázisból a nagyméretű struktúrák bármely értelmét. Azt várni, hogy egy szoftver egyszerűen megbirkózik bármely kétes adatszerkezetű fraktállal, egyszerűen őrültség. El sem kell képzelnem, milyen rossz lehet a dolog, szigorú kódauditokat végeztem, ill Olyan dolgokat láttam, amelyekről ti emberek álmodni sem mertek. De azt is tudom, hogy néznek ki a jó szerkezetek, и . El tudok képzelni egy olyan világot, ahol a Firestore logikusnak tűnik, és az emberek, akik létrehozták, azt gondolják, hogy jó munkát végeztek. De mi nem ebben a világban élünk.
A FireBase lekérdezési támogatása minden szabvány szerint gyenge, és gyakorlatilag nem is létezik. Mindenképpen javításra vagy legalább átdolgozásra szorul. De a Firestore nem sokkal jobb, mert ugyanazokra az egydimenziós indexekre korlátozódik, amelyek a sima SQL-ben találhatók. Ha olyan lekérdezésekre van szüksége, amelyeket az emberek kaotikus adatokon futtatnak, akkor teljes szöveges keresésre, több tartományú szűrőkre és egyéni, felhasználó által meghatározott sorrendre van szüksége. Közelebbről megvizsgálva, a sima SQL funkciói önmagukban túlságosan korlátozottak. Ezen túlmenően az éles környezetben az emberek csak a gyors lekérdezéseket futtathatják. Egyéni indexelési megoldásra lesz szüksége átgondolt adatstruktúrákkal. Minden máshoz legalább növekményes térképcsökkentés vagy valami hasonló kellene.
Ha a Google Dokumentumokban keres ezzel kapcsolatos információkat, akkor remélhetőleg valami olyan irányába mutat, mint a BigTable és a BigQuery. Mindezeket a megoldásokat azonban olyan sűrű vállalati értékesítési szakzsargon kíséri, hogy gyorsan visszafordul, és elkezd valami mást keresni.
A valós idejű adatbázissal az utolsó dolog, amit a vezetői fizetési mérlegen dolgozók készítettek, és azok számára.
(*) Ez egy vicc, ilyen nincs .
A Reklám Jogairól
Keresni hibakeresési projektekhez, szerver fejlesztéshez és hostinghoz? Biztosan ügyfelünk vagy 🙂 Különféle konfigurációjú szerverek napi árait, anti-DDoS és Windows licencek már benne vannak az árban.
Forrás: will.com