Kom ek vertel 'n tegniese storie.
Baie jare gelede was ek besig om 'n toepassing te ontwikkel met samewerkingskenmerke daarin ingebou. Dit was 'n gebruikersvriendelike eksperimentele stapel wat die volle potensiaal van vroeë React en CouchDB benut het. Dit het data in reële tyd via JSON gesinchroniseer . Dit is intern binne die maatskappy gebruik, maar die breë toepaslikheid en potensiaal daarvan op ander gebiede was duidelik.
Terwyl ons probeer het om hierdie tegnologie aan potensiële kliënte te verkoop, het ons 'n onverwagte struikelblok teëgekom. In die demo-video het ons tegnologie goed gelyk en gewerk, geen probleme daar nie. Die video het presies gewys hoe dit werk en het niks nageboots nie. Ons het vorendag gekom en 'n realistiese scenario vir die gebruik van die program gekodeer.
Trouens, dit het die probleem geword. Ons demo het presies gewerk soos almal anders hul toepassings gesimuleer het. Spesifiek, inligting is onmiddellik van A na B oorgedra, selfs al was dit groot medialêers. Nadat hy aangemeld het, het elke gebruiker nuwe inskrywings gesien. Deur die toepassing te gebruik, kon verskillende gebruikers duidelik aan dieselfde projekte saamwerk, selfs al is die internetverbinding iewers in die dorp onderbreek. Dit word implisiet geïmpliseer in enige produkvideo wat in After Effects gesny is.
Al het almal geweet waarvoor die Refresh-knoppie was, het niemand regtig verstaan dat die webtoepassings wat hulle ons gevra het om te bou, gewoonlik aan hul eie beperkings onderhewig is nie. En dat as hulle nie meer nodig is nie, die gebruikerservaring heeltemal anders sal wees. Hulle het meestal opgemerk dat hulle kon “gesels” deur notas te los vir mense met wie hulle praat, en daarom het hulle gewonder hoe dit verskil van byvoorbeeld Slack. Pff!
Ontwerp van alledaagse sinchronisasies
As jy ondervinding in sagteware-ontwikkeling het, moet dit senutergend wees om te onthou dat die meeste mense nie net na 'n prentjie van 'n koppelvlak kan kyk en verstaan wat dit sal doen wanneer daar interaksie daarmee is nie. Om nie te praat van wat binne die program self gebeur nie. Weet dit kan gebeur is grootliks die gevolg van die wete wat nie kan gebeur en wat nie moet gebeur nie. Dit vereis nie net wat die sagteware doen nie, maar ook hoe sy individuele dele gekoördineer word en met mekaar kommunikeer.
'n Klassieke voorbeeld hiervan is 'n gebruiker wat na 'n spinner.gif, wonder wanneer die werk uiteindelik voltooi sal wees. Die ontwikkelaar sou besef het dat die proses waarskynlik vasgeval het en dat die gif nooit van die skerm sou verdwyn nie. Hierdie animasie simuleer die uitvoering van 'n werk, maar is nie verwant aan die toestand daarvan nie. In sulke gevalle hou sommige tegnici daarvan om hul oë te rol, verstom oor die mate van gebruikersverwarring. Let egter op hoeveel van hulle wys na die draaiende horlosie en sê dat dit eintlik stilstaan?
Dit is die essensie van intydse waarde. Deesdae word intydse databasisse nog baie min gebruik en baie mense beskou dit met agterdog. Die meeste van hierdie databasisse leun sterk na die NoSQL-styl, en daarom gebruik hulle gewoonlik Mongo-gebaseerde oplossings, wat die beste vergeet word. Vir my beteken dit egter om gemaklik met CouchDB te werk, sowel as om te leer om strukture te ontwerp wat meer as net een of ander burokraat met data kan vul. Ek dink ek gebruik my tyd beter.
Maar die eintlike onderwerp van hierdie pos is wat ek vandag gebruik. Nie uit eie keuse nie, maar as gevolg van onverskillig en blindelings toegepaste korporatiewe beleid. Ek sal dus 'n heeltemal regverdige en onbevooroordeelde vergelyking verskaf van twee nou verwante Google-intydse databasisprodukte.
Albei het die woord Vuur in hul name. Een ding onthou ek met liefde. Die tweede ding vir my is 'n ander tipe vuur. Ek is nie haastig om hul name te sê nie, want sodra ek dit doen, sal ons die eerste groot probleem raakloop: name.
Die eerste een word genoem Firebase Real-Time Database, en tweede - Firebase Cloud Firestore. Beide van hulle is produkte van Firebase-suite Google. Hul API's word onderskeidelik genoem firebase.database(…) и firebase.firestore(…).
Dit het gebeur omdat Intydse databasis - dit is net die oorspronklike Firebase voor die aankoop daarvan deur Google in 2014. Toe het Google besluit om as 'n parallelle produk te skep kopie Firebase gebaseer op groot data maatskappy, en noem dit Firestore met 'n wolk. Ek hoop jy is nog nie deurmekaar nie. As jy nog deurmekaar is, moenie bekommerd wees nie, ek het self hierdie deel van die artikel tien keer herskryf.
Want jy moet aandui Firebase in die Firebase-vraag, en Vuurwinkel in 'n vraag oor Firebase, ten minste om jou 'n paar jaar gelede op Stack Overflow te laat verstaan.
As daar 'n toekenning was vir die slegste sagteware-naamervaring, sou dit beslis een van die aanspraakmakers wees. Die Hamming-afstand tussen hierdie name is so klein dat dit selfs ervare ingenieurs verwar wie se vingers een naam tik terwyl hul koppe aan 'n ander dink. Dit is goedbedoelde planne wat klaaglik misluk; hulle het die profesie vervul dat die databasis aan die brand sou wees. En ek maak glad nie 'n grap nie. Die persoon wat met hierdie naamskema vorendag gekom het, het bloed, sweet en trane veroorsaak.
Pyrrhiese oorwinning
Mens sou dink dat Firestore is vervanging Firebase, sy volgende generasie afstammeling, maar dit sal misleidend wees. Firestore is nie gewaarborg om 'n geskikte plaasvervanger vir Firebase te wees nie. Dit lyk of iemand alles wat interessant is daaruit uitgesny het, en die meeste van die res op verskeie maniere verwar het.
'n Vinnige blik op die twee produkte kan jou egter verwar: dit lyk asof hulle dieselfde ding doen, deur basies dieselfde API's en selfs in dieselfde databasissessie. Die verskille is subtiel en word slegs aan die lig gebring deur noukeurige vergelykende studie van uitgebreide dokumentasie. Of wanneer jy kode probeer oordra wat perfek op Firebase werk sodat dit met Firestore werk. Selfs dan vind jy uit dat die databasis-koppelvlak oplig sodra jy intyds met die muis probeer sleep en los. Ek herhaal, ek maak nie 'n grap nie.
Die Firebase-kliënt is beleefd in die sin dat dit veranderinge buffer en outomaties opdaterings herprobeer wat prioriteit gee aan die laaste skryfbewerking. Firestore het egter 'n limiet van 1 skryfbewerking per dokument per gebruiker per sekonde, en hierdie limiet word deur die bediener afgedwing. Wanneer jy daarmee werk, is dit aan jou om 'n manier om dit te vind en 'n opdateringsnelheidsbeperker te implementeer, selfs wanneer jy net probeer om jou toepassing te bou. Dit wil sê, Firestore is 'n intydse databasis sonder 'n intydse kliënt, wat hom voordoen as een wat 'n API gebruik.
Hier begin ons die eerste tekens van Firestore se bestaansrede sien. Ek is dalk verkeerd, maar ek vermoed iemand hoog in Google se bestuur het ná die aankoop na Firebase gekyk en bloot gesê: “Nee, o my God, nee. Dit is onaanvaarbaar. Net nie onder my leiding nie.”
Hy het uit sy kamers verskyn en verklaar:
“Een groot JSON-dokument? Geen. Jy sal die data in aparte dokumente verdeel, wat elk nie meer as 1 megagreep groot sal wees nie.”
Dit blyk dat so 'n beperking nie die eerste ontmoeting met enige voldoende gemotiveerde gebruikersbasis sal oorleef nie. Jy weet dit is. By die werk het ons byvoorbeeld meer as een en 'n half duisend aanbiedings, en dit is heeltemal normaal.
Met hierdie beperking sal jy gedwing word om die feit te aanvaar dat een "dokument" in die databasis nie sal lyk soos enige voorwerp wat 'n gebruiker 'n dokument kan noem nie.
"Skikkings van skikkings wat rekursief ander elemente kan bevat? Geen. Skikkings sal slegs vaste-lengte voorwerpe of getalle bevat, soos God bedoel het."
So as jy gehoop het om GeoJSON in jou Firestore te plaas, sal jy vind dat dit nie moontlik is nie. Niks nie-eendimensioneel is aanvaarbaar nie. Ek hoop jy hou van Base64 en/of JSON binne JSON.
“JSON invoer en uitvoer via HTTP, opdragreëlnutsgoed of adminpaneel? Geen. Jy sal net data kan uitvoer en invoer na Google Wolkberging. Dis wat dit nou genoem word, dink ek. En as ek "jy" sê, spreek ek net diegene aan wat projekeienaar-bewyse het. Almal anders kan gaan kaartjies skep.”
Soos u kan sien, is die FireBase-datamodel maklik om te beskryf. Dit bevat een groot JSON-dokument wat JSON-sleutels met URL-paaie assosieer. As jy skryf met HTTP PUT в / FireBase is die volgende:
{
"hello": "world"
}
die GET /hello sal terugkeer "world". Basies werk dit presies soos jy sou verwag. Versameling van FireBase-voorwerpe /my-collection/:id gelykstaande aan 'n JSON-woordeboek {"my-collection": {...}} in die wortel, waarvan die inhoud beskikbaar is in /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Dit werk goed as elke insetsel 'n botsingsvrye ID het, waarvoor die stelsel 'n standaardoplossing het.
Met ander woorde, die databasis is 100% JSON(*)-versoenbaar en werk uitstekend met HTTP, soos CouchDB. Maar basies gebruik jy dit deur 'n intydse API wat websockets, magtiging en intekeninge optrek. Die administrasiepaneel het albei vermoëns, wat beide intydse redigering en JSON-invoer/uitvoer toelaat. As jy dieselfde in jou kode doen, sal jy verbaas wees oor hoeveel gespesialiseerde kode vermors sal word wanneer jy besef dat patch and diff JSON 90% van die roetine take van die hantering van aanhoudende toestand oplos.
Die Firestore-datamodel is soortgelyk aan JSON, maar verskil op sekere kritieke maniere. Ek het reeds die gebrek aan skikkings binne skikkings genoem. Die model vir sub-versamelings is dat hulle eersteklas konsepte moet wees, apart van die JSON-dokument wat dit bevat. Aangesien daar geen klaargemaakte serialisering hiervoor is nie, is 'n gespesialiseerde kodepad nodig om data te herwin en te skryf. Om jou eie versamelings te verwerk, moet jy jou eie skrifte en gereedskap skryf. Die administrasiepaneel laat jou net toe om klein veranderinge een veld op 'n slag te maak, en het nie invoer/uitvoer vermoëns nie.
Hulle het 'n intydse NoSQL-databasis geneem en dit verander in 'n stadige nie-SQL met outomatiese aansluiting en 'n aparte nie-JSON-kolom. Iets soos GraftQL.
Warm Java
As Firestore veronderstel was om meer betroubaar en skaalbaar te wees, dan is die ironie dat die gemiddelde ontwikkelaar met 'n minder betroubare oplossing sal eindig as om FireBase uit die boks te kies. Die soort sagteware wat die Grumpy Database Administrateur nodig het, vereis 'n vlak van inspanning en kaliber van talent wat eenvoudig onrealisties is vir die nis waarin die produk veronderstel is om goed te wees. Dit is soortgelyk aan hoe HTML5 Canvas glad nie 'n plaasvervanger vir Flash is as daar geen ontwikkelingsinstrumente en 'n speler is nie. Boonop is Firestore vasgevang in 'n begeerte vir datasuiwerheid en steriele validering wat eenvoudig nie ooreenstem met hoe die gemiddelde besigheidsgebruiker nie hou van werk: vir hom is alles opsioneel, want tot die einde toe is alles 'n konsep.
Die grootste nadeel van FireBase is dat die kliënt etlike jare voor sy tyd geskep is, voordat die meeste webontwikkelaars geweet het van onveranderlikheid. As gevolg hiervan, neem FireBase aan dat u die data sal verander en trek dus nie voordeel uit die onveranderlikheid wat deur die gebruiker verskaf word nie. Boonop hergebruik dit nie die data in die foto's wat dit aan die gebruiker deurgee nie, wat verskil baie moeiliker maak. Vir groot dokumente is die veranderlike verskil-gebaseerde transaksiemeganisme eenvoudig onvoldoende. Ouens, ons het reeds WeakMap in JavaScript. Dis gemaklik.
As jy die data die gewenste vorm gee en nie die bome te volumineus maak nie, dan kan hierdie probleem omseil word. Maar ek is nuuskierig of FireBase baie interessanter sou wees as die ontwikkelaars 'n baie goeie kliënt-API vrygestel het wat onveranderlikheid gekombineer het met 'n paar ernstige praktiese raad oor databasisontwerp. In plaas daarvan het dit gelyk of hulle probeer regmaak wat nie stukkend was nie, en dit het dit vererger.
Ek ken nie al die logika agter die skepping van Firestore nie. Om te bespiegel oor die motiewe wat binne die swart boks ontstaan, is ook deel van die pret. Hierdie jukstaposisie van twee uiters soortgelyke maar onvergelykbare databasisse is redelik skaars. Dit is soos iemand gedink het: "Firebase is net 'n funksie wat ons in Google Cloud kan naboots", maar het nog nie die konsep ontdek om werklike vereistes te identifiseer of nuttige oplossings te skep wat aan al daardie vereistes voldoen nie. “Laat die ontwikkelaars daaroor dink. Maak net die UI mooi... Kan jy nog vuur byvoeg?”
Ek verstaan 'n paar dinge oor datastrukture. Ek sien beslis die "alles in een groot JSON-boom" konsep as 'n poging om enige gevoel van grootskaalse struktuur uit die databasis te onttrek. Om te verwag dat sagteware eenvoudig enige twyfelagtige datastruktuurfraktale sal hanteer, is eenvoudig kranksinnig. Ek hoef nie eers te dink hoe sleg dinge kan wees nie, ek het streng kode-oudits gedoen en Ek het dinge gesien waarvan julle nooit gedroom het nie. Maar ek weet ook hoe goeie strukture lyk, и . Ek kan my 'n wêreld voorstel waar Firestore logies sou lyk en die mense wat dit geskep het sou dink hulle het 'n goeie werk gedoen. Maar ons leef nie in hierdie wêreld nie.
FireBase se navraagondersteuning is swak volgens enige standaard en bestaan feitlik nie. Dit benodig beslis verbetering of ten minste hersiening. Maar Firestore is nie veel beter nie, want dit is beperk tot dieselfde eendimensionele indekse wat in gewone SQL voorkom. As u navrae benodig wat mense op chaotiese data uitvoer, benodig u voltekssoektog, multireeksfilters en pasgemaakte gebruikergedefinieerde volgorde. By nadere ondersoek is die funksies van gewone SQL op hul eie te beperk. Boonop is die enigste SQL-navrae wat mense in produksie kan uitvoer vinnige navrae. Jy benodig 'n pasgemaakte indekseringsoplossing met deurdagte datastrukture. Vir al die ander moet daar ten minste inkrementele kaartvermindering of iets soortgelyks wees.
As jy Google Docs vir inligting hieroor soek, sal jy hopelik in die rigting van iets soos BigTable en BigQuery gewys word. Al hierdie oplossings gaan egter gepaard met soveel digte korporatiewe verkoopsjargon dat jy vinnig sal terugdraai en na iets anders begin soek.
Die laaste ding wat jy wil hê met 'n intydse databasis is iets wat gemaak is deur en vir mense op bestuursbetaalskale.
(*) Dit is 'n grap, daar is nie so iets soos .
Oor die regte van reklame
Soek vir vir ontfoutingsprojekte, 'n bediener vir ontwikkeling en hosting? Jy is beslis ons kliënt 🙂 Daaglikse pryse vir bedieners van verskeie konfigurasies, anti-DDoS en Windows-lisensies is reeds by die prys ingesluit.
Bron: will.com