Låt mig berätta en teknisk historia.
För många år sedan utvecklade jag en applikation med inbyggda samarbetsfunktioner. Det var en användarvänlig experimentstack som utnyttjade den fulla potentialen hos tidiga React och CouchDB. Den synkroniserade data i realtid via JSON . Den användes internt inom företaget, men dess breda tillämpbarhet och potential inom andra områden var tydlig.
När vi försökte sälja denna teknik till potentiella kunder stötte vi på ett oväntat hinder. I demovideon såg och fungerade vår teknik utmärkt, inga problem där. Videon visade exakt hur det fungerar och imiterade ingenting. Vi kom fram till och kodade ett realistiskt scenario för att använda programmet.
I själva verket blev detta problemet. Vår demo fungerade precis som alla andra simulerade sina applikationer. Specifikt överfördes information omedelbart från A till B, även om det var stora mediefiler. Efter att ha loggat in såg varje användare nya poster. Genom att använda applikationen kunde olika användare tydligt arbeta tillsammans i samma projekt, även om internetanslutningen avbröts någonstans i byn. Detta är implicit underförstått i alla produktvideoklipp i After Effects.
Även om alla visste vad Uppdatera-knappen var till för, förstod ingen riktigt att de webbapplikationer de bad oss bygga vanligtvis var föremål för sina egna begränsningar. Och att om de inte längre behövs så blir användarupplevelsen en helt annan. De märkte mest att de kunde "chatta" genom att lämna anteckningar till personer de pratade med, så de undrade hur detta skilde sig från till exempel Slack. Puh!
Design av vardagliga synkroniseringar
Om du har erfarenhet av mjukvaruutveckling måste det vara nervkittlande att komma ihåg att de flesta inte bara kan titta på en bild av ett gränssnitt och förstå vad det kommer att göra när de interagerar med det. För att inte tala om vad som händer i själva programmet. Veta det kan hända är till stor del resultatet av att veta vad som inte får hända och vad som inte får hända. Detta kräver inte bara vad programvaran gör, utan också hur dess enskilda delar koordineras och kommunicerar med varandra.
Ett klassiskt exempel på detta är en användare som stirrar på en spinner.gif, undrar när arbetet äntligen ska vara klart. Utvecklaren skulle ha insett att processen förmodligen satt fast och att gif:en aldrig skulle försvinna från skärmen. Den här animeringen simulerar utförandet av ett jobb, men är inte relaterat till dess tillstånd. I sådana fall gillar vissa tekniker att himla med ögonen, förvånade över omfattningen av användarförvirring. Lägg dock märke till hur många av dem som pekar på den roterande klockan och säger att den faktiskt står stilla?
Detta är kärnan i realtidsvärde. Idag används realtidsdatabaser fortfarande väldigt lite och många ser dem med misstänksamhet. De flesta av dessa databaser lutar sig kraftigt mot NoSQL-stilen, varför de vanligtvis använder Mongo-baserade lösningar, som bäst glöms bort. Men för mig innebär detta att bli bekväm med att arbeta med CouchDB, samt lära mig att designa strukturer som mer än bara en byråkrat kan fylla med data. Jag tror att jag använder min tid bättre.
Men det verkliga ämnet för det här inlägget är vad jag använder idag. Inte av val, utan på grund av likgiltigt och blint tillämpad företagspolicy. Så jag ska ge en helt rättvis och opartisk jämförelse av två närbesläktade Googles realtidsdatabasprodukter.
Båda har ordet eld i sina namn. En sak minns jag med glädje. Det andra för mig är en annan typ av eld. Jag har ingen brådska med att säga deras namn, för när jag väl gör det kommer vi att stöta på det första stora problemet: namn.
Den första heter Firebase realtidsdatabas, och andra - Firebase Cloud Firestore. Båda är produkter från Firebase-svit Google. Deras API:er kallas respektive firebase.database(…) и firebase.firestore(…).
Detta hände pga Realtidsdatabas - det är bara originalet Firebase innan det köptes av Google 2014. Då bestämde sig Google för att skapa som en parallell produkt kopiera Firebase baserad på big data-företag, och kallade det Firestore med ett moln. Jag hoppas att du inte är förvirrad än. Om du fortfarande är förvirrad, oroa dig inte, jag har själv skrivit om den här delen av artikeln tio gånger.
För du måste indikera Firebase i Firebase-frågan och Firestore i en fråga om Firebase, åtminstone för att få dig att förstå för några år sedan på Stack Overflow.
Om det fanns ett pris för den värsta namngivningsupplevelsen för mjukvaran, skulle detta definitivt vara en av utmanarna. Hamming-avståndet mellan dessa namn är så litet att det förvirrar även erfarna ingenjörer vars fingrar skriver ett namn medan deras huvuden tänker på ett annat. Det är välmenande planer som misslyckas kapitalt; de uppfyllde profetian att databasen skulle brinna. Och jag skojar inte alls. Personen som kom på detta namnschema orsakade blod, svett och tårar.
Pyrrisk seger
Man skulle kunna tro att Firestore är det ersättning Firebase, nästa generations ättling, men det skulle vara missvisande. Firestore är inte garanterat en lämplig ersättning för Firebase. Det ser ut som om någon klippte bort allt intressant från den och förvirrade det mesta av resten på olika sätt.
En snabb blick på de två produkterna kan dock förvirra dig: de verkar göra samma sak, genom i princip samma API:er och till och med i samma databassession. Skillnaderna är subtila och avslöjas endast genom noggrann jämförande studie av omfattande dokumentation. Eller när du försöker porta kod som fungerar perfekt på Firebase så att den fungerar med Firestore. Redan då får du reda på att databasgränssnittet lyser så fort du försöker dra och släppa med musen i realtid. Jag upprepar, jag skämtar inte.
Firebase-klienten är artig i den meningen att den buffrar ändringar och automatiskt försöker göra om uppdateringar som prioriterar den senaste skrivoperationen. Firestore har dock en gräns på 1 skrivoperation per dokument per användare och sekund, och denna gräns upprätthålls av servern. När du arbetar med det är det upp till dig att hitta en väg runt det och implementera en uppdateringshastighetsbegränsare, även när du bara försöker bygga din applikation. Det vill säga, Firestore är en realtidsdatabas utan en realtidsklient, som utger sig som en som använder ett API.
Här börjar vi se de första tecknen på Firestores existensberättigande. Jag kan ha fel, men jag misstänker att någon högt upp i Googles ledning tittade på Firebase efter köpet och bara sa: ”Nej, herregud, nej. Det här är oacceptabelt. Bara inte under mitt ledarskap."
Han dök upp från sina kammare och förklarade:
"Ett stort JSON-dokument? Nej. Du kommer att dela upp data i separata dokument, som vart och ett kommer att vara högst 1 megabyte i storlek."
Det verkar som att en sådan begränsning inte kommer att överleva det första mötet med någon tillräckligt motiverad användarbas. Du vet att det är det. På jobbet har vi till exempel mer än ett och ett halvt tusen presentationer, och det är helt normalt.
Med denna begränsning kommer du att tvingas acceptera det faktum att ett "dokument" i databasen inte kommer att likna något objekt som en användare kan kalla ett dokument.
"Arrayer av arrayer som rekursivt kan innehålla andra element? Nej. Arrayer kommer endast att innehålla objekt eller nummer med fast längd, som Gud avsåg."
Så om du hoppades att lägga GeoJSON i din Firestore, kommer du att upptäcka att detta inte är möjligt. Inget icke-endimensionellt är acceptabelt. Jag hoppas att du gillar Base64 och/eller JSON inom JSON.
"JSON importera och exportera via HTTP, kommandoradsverktyg eller adminpanel? Nej. Du kommer bara att kunna exportera och importera data till Google Cloud Storage. Det är så det heter nu tror jag. Och när jag säger "du" vänder jag mig bara till dem som har behörighet som projektägare. Alla andra kan gå och skapa biljetter."
Som du kan se är FireBase-datamodellen lätt att beskriva. Den innehåller ett enormt JSON-dokument som associerar JSON-nycklar med URL-sökvägar. Om du skriver med HTTP PUT в / FireBase är följande:
{
"hello": "world"
}
den GET /hello kommer att återvända "world". I princip fungerar det precis som du förväntar dig. Samling av FireBase-objekt /my-collection/:id motsvarar en JSON-ordbok {"my-collection": {...}} i roten, vars innehåll är tillgängligt i /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Detta fungerar bra om varje insats har ett kollisionsfritt ID, vilket systemet har en standardlösning för.
Databasen är med andra ord 100 % JSON(*)-kompatibel och fungerar utmärkt med HTTP, såsom CouchDB. Men i grund och botten använder du det genom ett realtids-API som abstraherar websockets, auktorisering och prenumerationer. Administratörspanelen har båda funktionerna, vilket tillåter både realtidsredigering och JSON-import/export. Om du gör samma sak i din kod kommer du att bli förvånad över hur mycket specialiserad kod som kommer att gå till spillo när du inser att patch and diff JSON löser 90 % av rutinuppgifterna för att hantera persistent state.
Firestore-datamodellen liknar JSON, men skiljer sig på vissa kritiska sätt. Jag nämnde redan bristen på arrayer inom arrayer. Modellen för undersamlingar är att de ska vara förstklassiga koncept, separata från JSON-dokumentet som innehåller dem. Eftersom det inte finns någon färdig serialisering för detta krävs en specialiserad kodsökväg för att hämta och skriva data. För att bearbeta dina egna samlingar behöver du skriva dina egna manus och verktyg. Administratörspanelen låter dig bara göra små ändringar ett fält i taget och har inga import-/exportmöjligheter.
De tog en NoSQL-databas i realtid och gjorde den till en långsam icke-SQL med auto-join och en separat icke-JSON-kolumn. Något liknande GraftQL.
Hot Java
Om Firestore skulle vara mer pålitligt och skalbart, så är ironin att den genomsnittliga utvecklaren kommer att få en mindre pålitlig lösning än att välja FireBase ur lådan. Den typ av programvara som Grumpy Database Administrator behöver kräver en nivå av ansträngning och kaliber av talang som helt enkelt är orealistisk för den nisch produkten ska vara bra på. Detta liknar hur HTML5 Canvas inte alls är en ersättning för Flash om det inte finns några utvecklingsverktyg och en spelare. Firestore är dessutom fast i en önskan om datarenhet och steril validering som helt enkelt inte stämmer överens med hur den genomsnittliga affärsanvändaren älskar att jobba: för honom är allt valfritt, för ända till slutet är allt ett utkast.
Den största nackdelen med FireBase är att klienten skapades flera år före sin tid, innan de flesta webbutvecklare visste om oföränderlighet. På grund av detta antar FireBase att du kommer att ändra data och drar därför inte nytta av användarförsedd oföränderlighet. Dessutom återanvänder den inte data i ögonblicksbilderna som den skickar till användaren, vilket gör skillnaden mycket svårare. För stora dokument är dess föränderliga diff-baserade transaktionsmekanism helt enkelt otillräcklig. Killar, det har vi redan WeakMap i JavaScript. Det är bekvämt.
Om du ger data den önskade formen och inte gör träden för voluminösa, kan detta problem kringgås. Men jag är nyfiken på om FireBase skulle vara mycket mer intressant om utvecklarna släppte ett riktigt bra klient-API som använde oföränderlighet i kombination med några seriösa praktiska råd om databasdesign. Istället verkade de försöka fixa det som inte var trasigt, och det gjorde det värre.
Jag känner inte till all logik bakom skapandet av Firestore. Att spekulera kring motiven som uppstår inne i den svarta lådan är också en del av det roliga. Denna sammanställning av två extremt lika men ojämförliga databaser är ganska sällsynt. Det är som någon trodde: "Firebase är bara en funktion som vi kan emulera i Google Cloud", men har ännu inte upptäckt konceptet att identifiera verkliga krav eller skapa användbara lösningar som uppfyller alla dessa krav. "Låt utvecklarna tänka på det. Gör bara användargränssnittet vackert... Kan du lägga till mer eld?”
Jag förstår ett par saker om datastrukturer. Jag ser definitivt konceptet "allt i ett stort JSON-träd" som ett försök att abstrahera någon känsla av storskalig struktur från databasen. Att förvänta sig att programvara helt enkelt ska klara av alla tvivelaktiga fraktaler i datastruktur är helt enkelt vansinnigt. Jag behöver inte ens föreställa mig hur illa saker kan vara, jag har gjort rigorösa kodrevisioner och Jag såg saker som ni aldrig drömt om. Men jag vet också hur bra strukturer ser ut, и . Jag kan föreställa mig en värld där Firestore verkar logisk och människorna som skapade den skulle tycka att de gjorde ett bra jobb. Men vi lever inte i den här världen.
FireBases frågestöd är dåligt av alla standarder och är praktiskt taget obefintligt. Det behöver definitivt förbättras eller åtminstone revideras. Men Firestore är inte mycket bättre eftersom det är begränsat till samma endimensionella index som finns i vanlig SQL. Om du behöver frågor som människor kör på kaotiska data behöver du fulltextsökning, filter för flera intervall och anpassad användardefinierad ordning. Vid närmare granskning är funktionerna i vanlig SQL för begränsade i sig. Dessutom är de enda SQL-frågor som människor kan köra i produktionen snabba frågor. Du behöver en anpassad indexeringslösning med smarta datastrukturer. För allt annat bör det åtminstone finnas inkrementell map-reduce eller något liknande.
Om du söker i Google Docs efter information om detta kommer du förhoppningsvis att pekas i riktning mot något som BigTable och BigQuery. Alla dessa lösningar åtföljs dock av så mycket tät företagsförsäljningsjargong att du snabbt vänder tillbaka och börjar leta efter något annat.
Det sista du vill ha med en realtidsdatabas är något som gjorts av och för personer på ledningens löneskalor.
(*) Det här är ett skämt, det finns inget som heter .
Om reklamens rättigheter
Letar efter för felsökningsprojekt, en server för utveckling och hosting? Du är definitivt vår kund 🙂 Daglig prissättning för servrar med olika konfigurationer, anti-DDoS och Windows-licenser ingår redan i priset.
Källa: will.com