Lit my in technysk ferhaal fertelle.
In protte jierren lyn ûntwikkele ik in applikaasje mei gearwurkingsfunksjes ynboud. It wie in brûkerfreonlike eksperimintele stapel dy't profitearre fan it folsleine potensjeel fan iere React en CouchDB. It syngronisearre gegevens yn echte tiid fia JSON . It waard yntern brûkt binnen it bedriuw, mar de brede tapasberens en potinsjeel op oare gebieten wie dúdlik.
Wylst wy besykje dizze technology te ferkeapjen oan potinsjele kliïnten, tsjinkamen wy in ûnferwacht obstakel. Yn 'e demo-fideo seach en wurke ús technology geweldich, gjin problemen dêr. De fideo liet krekt sjen hoe't it wurket en imitearre neat. Wy kamen mei en kodearre in realistysk senario foar it brûken fan it programma.
Yn feite waard dit it probleem. Us demo wurke krekt sa't elkenien har applikaasjes simulearren. Spesifyk waard ynformaasje daliks oerbrocht fan A nei B, sels as it grutte mediabestannen wiene. Nei it oanmelden seach elke brûker nije yngongen. Mei de applikaasje koene ferskillende brûkers dúdlik gearwurkje oan deselde projekten, sels as de ynternetferbining earne yn it doarp ûnderbrutsen wie. Dit wurdt ymplisyt ymplisyt yn elke produktfideo besunige yn After Effects.
Sels hoewol elkenien wist wêr't de knop Ferfarskje foar wie, begriep gjinien echt dat de webapplikaasjes dy't se ús fregen om te bouwen gewoanlik ûnderwurpen wiene oan har eigen beheiningen. En dat as se net mear nedich binne, de brûkersûnderfining folslein oars sil wêze. Se merkten meastentiids op dat se "petelje" koene troch notysjes efter te litten foar minsken mei wa't se prate, dat se fregen har ôf hoe't dit oars wie fan bygelyks Slack. Pff!
Untwerp fan deistige synchronisaasjes
As jo ûnderfining hawwe yn softwareûntwikkeling, moat it senuweftich wêze om te ûnthâlden dat de measte minsken net gewoan nei in ôfbylding fan in ynterface kinne sjen en begripe wat it sil dwaan as se dermei ynteraksje. Net te hawwen oer wat der binnen it programma sels bart. Kennis dat kin barre is foar in grut part it resultaat fan witten wat net kin en wat net barre moat. Dit fereasket net allinnich wat de software docht, mar ek hoe't syn yndividuele dielen wurde koördinearre en kommunisearje mei elkoar.
In klassyk foarbyld fan dit is in brûker stjer op in spinner.gif, benijd wannear't it wurk einlings klear wêze sil. De ûntwikkelder soe realisearre hawwe dat it proses wierskynlik fêst siet en dat de gif nea fan it skerm ferdwine soe. Dizze animaasje simulearret de útfiering fan in baan, mar is net besibbe oan syn steat. Yn sokke gefallen, guon techies graach roll harren eagen, fernuvere oer de omfang fan brûkers betizing. Let lykwols op hoefolle fan harren wize op de draaiende klok en sizze dat it eins stil is?
Dit is de essinsje fan real-time wearde. Tsjintwurdich wurde realtime databases noch heul min brûkt en in protte minsken sjogge se mei erchtinken. De measte fan dizze databases leanje swier nei de NoSQL-styl, en dêrom brûke se meastentiids Mongo-basearre oplossingen, dy't it bêste fergetten wurde. Foar my betsjuttet dit lykwols noflik te wurkjen mei CouchDB, lykas ek learje om struktueren te ûntwerpen dy't mear dan allinich in burokraat kin folje mei gegevens. Ik tink dat ik myn tiid better brûke.
Mar it echte ûnderwerp fan dizze post is wat ik hjoed brûke. Net troch kar, mar troch ûnferskillich en blyn tapast bedriuwsbelied. Dat ik sil in folslein earlike en ûnbidige fergeliking leverje fan twa nau besibbe Google real-time databankprodukten.
Beide hawwe it wurd Fire yn har nammen. Ien ding herinner ik my goed. It twadde ding foar my is in oar type fjoer. Ik ha gjin haast om har nammen te sizzen, want as ik it ienris doch, komme wy it earste grutte probleem tsjin: nammen.
De earste wurdt neamd Firebase Real-Time Database, en twadde - Firebase Cloud Firestore. Beide fan harren binne produkten út Firebase suite Google. Harren API's wurde respektivelik neamd firebase.database(…) и firebase.firestore(…).
Dit barde omdat Real-Time Database - it is gewoan it orizjineel Firebase foar syn oankeap troch Google yn 2014. Doe besleat Google om as parallel produkt te meitsjen kopy Firebase basearre op grutte data bedriuw, en neamde it Firestore mei in wolk. Ik hoopje dat jo noch net yn 'e war binne. As jo noch yn 'e war binne, meitsje jo gjin soargen, ik sels haw dit diel fan it artikel tsien kear opnij skreaun.
Want jo moatte oanjaan Firebase yn 'e Firebase fraach, en Firestore yn in fraach oer Firebase, teminsten om jo in pear jier lyn te begripen op Stack Overflow.
As d'r in priis wie foar de minste ûnderfining foar nammen fan software, soe dit perfoarst ien fan 'e kandidaten wêze. De Hamming-ôfstân tusken dizze nammen is sa lyts dat it sels betûfte yngenieurs betizet waans fingers ien namme typearje wylst har hollen nei in oare tinke. Dit binne goedbedoelde plannen dy't jammerdearlik mislearje; se ferfolle de profesije dat de databank yn 'e brân stean soe. En ik meitsje gjin grapke. De persoan dy't mei dit nammeskema kaam, feroarsake bloed, swit en triennen.
Pyrrhic oerwinning
Men soe tinke dat Firestore is substitution Firebase, syn folgjende generaasje neisiet, mar dat soe misliedend wêze. Firestore wurdt net garandearre in geskikte ferfanging foar Firebase. It liket derop dat ien der alles ynteressant út hat knipt, en it measte fan 'e rest op ferskate manieren betize hat.
In rappe blik op de twa produkten kin jo lykwols betize meitsje: se lykje itselde ding te dwaan, troch yn prinsipe deselde API's en sels yn deselde databank sesje. De ferskillen binne subtyl en wurde allinich iepenbiere troch soarchfâldige ferlykjende stúdzje fan wiidweidige dokumintaasje. Of as jo besykje koade te portearjen dy't perfekt wurket op Firebase, sadat it wurket mei Firestore. Sels dan fine jo dat de databankynterface opljochtet sa gau as jo besykje te slepen en te fallen mei de mûs yn realtime. Ik werhelje, ik meitsje gjin grapke.
De Firebase-kliïnt is beleefd yn 'e sin dat it wizigingen buffert en automatysk updates opnij besiket dy't prioriteit jouwe oan de lêste skriuwoperaasje. Firestore hat lykwols in limyt fan 1 skriuwoperaasje per dokumint per brûker per sekonde, en dizze limyt wurdt hanthavene troch de tsjinner. As jo mei wurkje, is it oan jo om der in manier om te finen en in beheiner foar fernijingsrate te implementearjen, sels as jo gewoan besykje jo applikaasje te bouwen. Dat is, Firestore is in real-time databank sûnder in real-time client, dy't masquerades as ien mei help fan in API.
Hjir begjinne wy de earste tekens fan Firestore's raison d'être te sjen. Ik kin it ferkeard hawwe, mar ik fermoedzje dat immen heech yn it management fan Google Firebase nei de oankeap seach en gewoan sei: "Nee, oh myn God, nee. Dit is net akseptabel. Net ûnder myn lieding."
Hy ferskynde út syn keamers en ferklearre:
"Ien grut JSON-dokumint? Nee. Jo sille de gegevens splitst yn aparte dokuminten, elk fan dy sil net mear as 1 megabyte yn grutte wêze.
It liket derop dat sa'n beheining de earste moeting mei elke genôch motivearre brûkersbasis net sil oerlibje. Jo witte dat it is. Op it wurk hawwe wy bygelyks mear as oardeltûzen presintaasjes, en dit is folslein normaal.
Mei dizze beheining sille jo twongen wurde om it feit te akseptearjen dat ien "dokumint" yn 'e databank net liket op in objekt dat in brûker in dokumint kin neame.
"Arrays fan arrays dy't rekursyf oare eleminten kinne befetsje? Nee. Arrays sille allinich objekten of nûmers fan fêste lingte befetsje, lykas God bedoelde."
Dus as jo hopen GeoJSON yn jo Firestore te pleatsen, sille jo fine dat dit net mooglik is. Neat net-iendiminsjonaal is akseptabel. Ik hoopje dat jo Base64 en / of JSON binnen JSON leuk fine.
"JSON ymportearje en eksportearje fia HTTP, kommandorigelark of adminpaniel? Nee. Jo sille allinich gegevens kinne eksportearje en ymportearje nei Google Cloud Storage. Sa hjit it no, tink ik. En as ik "jo" sis, sprekke ik allinich oan dyjingen dy't bewiisbrieven fan projekteigners hawwe. Elkenien kin gean en kaartsjes meitsje."
Lykas jo kinne sjen, is it FireBase-gegevensmodel maklik te beskriuwen. It befettet ien enoarm JSON-dokumint dat JSON-kaaien assosjearret mei URL-paden. As jo skriuwe mei HTTP PUT в / FireBase is it folgjende:
{
"hello": "world"
}
De GET /hello sil weromkomme "world". Yn prinsipe wurket it krekt lykas jo soene ferwachtsje. Samling fan FireBase-objekten /my-collection/:id lykweardich oan in JSON wurdboek {"my-collection": {...}} yn 'e root, wêrfan de ynhâld beskikber is yn /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Dit wurket prima as elk ynfoegje hat in botsing-frij ID, dêr't it systeem hat in standert oplossing foar.
Mei oare wurden, de databank is 100% JSON(*) kompatibel en wurket geweldich mei HTTP, lykas CouchDB. Mar yn prinsipe brûke jo it fia in real-time API dy't websockets, autorisaasje en abonneminten abstrahert. It adminpaniel hat beide mooglikheden, wêrtroch sawol real-time bewurkjen as JSON ymportearje / eksportearje kinne. As jo dogge itselde yn jo koade, do silst wêze ferrast oer hoefolle spesjalisearre koade wurdt fergriemd as jo realisearje dat patch en diff JSON oplost 90% fan de routine taken fan it behanneljen fan persistente steat.
It Firestore-gegevensmodel is fergelykber mei JSON, mar ferskilt op guon krityske manieren. Ik haw al it ûntbrekken fan arrays binnen arrays neamd. It model foar sub-kolleksjes is dat se earste klasse begripen binne, los fan it JSON-dokumint dat se befettet. Sûnt d'r is gjin klearmakke serialisaasje foar dit, is in spesjalisearre koadepaad nedich om gegevens op te heljen en te skriuwen. Om jo eigen kolleksjes te ferwurkjen, moatte jo jo eigen skripts en ark skriuwe. It adminpaniel lit jo allinich lytse feroaringen meitsje ien fjild tagelyk, en hat gjin ymport- / eksportmooglikheden.
Se namen in real-time NoSQL-database en feroare it yn in trage net-SQL mei auto-join en in aparte net-JSON-kolom. Iets as GraftQL.
Hot Java
As Firestore betrouberer en skalberber soe wêze, dan is de irony dat de gemiddelde ûntwikkelder mei in minder betroubere oplossing einiget dan it kiezen fan FireBase út it fak. It soarte software dat de Grumpy Database Administrator nedich is, fereasket in nivo fan ynspanning en kaliber fan talint dat gewoan ûnrealistysk is foar de niche wêryn it produkt goed moat wêze. Dit is gelyk oan hoe't HTML5 Canvas hielendal gjin ferfanging is foar Flash as d'r gjin ûntwikkelingsark en in spiler binne. Boppedat is Firestore bedutsen yn in winsk foar gegevenssuverens en sterile falidaasje dy't gewoan net oerienkomt mei hoe't de gemiddelde saaklike brûker hâldt fan wurkjen: foar him is alles fakultatyf, want oant it ein is alles in ûntwerp.
It wichtichste neidiel fan FireBase is dat de kliïnt ferskate jierren foar syn tiid makke is, foardat de measte webûntwikkelders wisten oer ûnferoarlikens. Hjirtroch giet FireBase derfan út dat jo de gegevens sille feroarje en makket dêrom gjin foardiel fan troch brûkers levere ûnferoarlikens. Derneist brûkt it de gegevens net opnij yn 'e snapshots dy't it trochjûn oan de brûker, wat it ferskil folle dreger makket. Foar grutte dokuminten is it mutable diff-basearre transaksjemeganisme gewoan net genôch. Jonges, wy hawwe al WeakMap yn JavaSkript. It is noflik.
As jo de gegevens de winske foarm jouwe en de beammen net te voluminous meitsje, dan kin dit probleem omseame wurde. Mar ik bin nijsgjirrich as FireBase folle nijsgjirriger soe wêze as de ûntwikkelders in echt goede client-API útbrochten dy't ûnferoarlikens brûkte kombineare mei wat serieus praktysk advys oer database-ûntwerp. Ynstee, se like te besykjen te reparearjen wat wie net brutsen, en dat makke it slimmer.
Ik wit net alle logika efter de skepping fan Firestore. Spekulearje oer de motiven dy't ûntsteane binnen de swarte doaze is ek diel fan 'e wille. Dizze njonkenstelling fan twa ekstreem ferlykbere, mar net te fergelykjen databases is frij seldsum. As soe immen tocht: "Firebase is gewoan in funksje dy't wy kinne emulearje yn Google Cloud", mar hat it konsept noch net ûntdutsen fan it identifisearjen fan echte easken of it meitsjen fan nuttige oplossingen dy't foldogge oan al dy easken. "Lit de ûntwikkelders der oer neitinke. Meitsje de UI gewoan moai ... Kinne jo mear fjoer tafoegje?"
Ik begryp in pear dingen oer gegevensstruktueren. Ik sjoch perfoarst it konsept "alles yn ien grutte JSON-beam" as in besykjen om elk gefoel fan grutskalige struktuer út 'e databank te abstraheren. Ferwachtsje fan software om gewoan om te gean mei elke dubieuze fractal datastruktuer is gewoan dwylsinnich. Ik hoech net iens foar te stellen hoe min dingen koe wêze, Ik haw dien strange koade audits en Ik seach dingen dêr't jim minsken noait fan dreamden. Mar ik wit ek hoe goede struktueren der útsjen, и . Ik kin my in wrâld foarstelle wêr't Firestore logysk soe lykje en de minsken dy't it makken soene tinke dat se in goede baan diene. Mar wy libje net yn dizze wrâld.
FireBase's query-stipe is min troch elke standert en is praktysk net-besteand. It moat perfoarst ferbettering of op syn minst revyzje nedich wêze. Mar Firestore is net folle better, om't it is beheind ta deselde iendiminsjonale yndeksen fûn yn gewoane SQL. As jo fragen nedich binne dy't minsken op chaotyske gegevens útfiere, hawwe jo folsleine tekstsykjen, filters mei meardere berik, en oanpaste brûker-definieare oardering nedich. By tichterby ynspeksje binne de funksjes fan gewoane SQL op har eigen te beheind. Derneist binne de ienige SQL-fragen dy't minsken kinne útfiere yn produksje snelle queries. Jo sille in oanpaste yndeksearingsoplossing nedich hawwe mei tûke gegevensstruktueren. Foar al it oare soe d'r teminsten inkrementele kaartfermindering wêze moatte as sokssawat.
As jo Google Docs sykje foar ynformaasje oer dit, sille jo hooplik wurde wiisd yn 'e rjochting fan iets lykas BigTable en BigQuery. Al dizze oplossingen wurde lykwols begelaat troch safolle ticht bedriuwsferkeapjargon dat jo fluch weromdraaie en begjinne nei wat oars te sykjen.
It lêste wat jo wolle mei in real-time databank is wat makke troch en foar minsken op managementbetelskalen.
(*) Dit is in grap, der is net sa'n ding as .
Oer de rjochten fan 'e advertinsje
Sykje om foar debuggen projekten, in tsjinner foar ûntwikkeling en hosting? Jo binne perfoarst ús kliïnt 🙂 Deistige prizen foar tsjinners fan ferskate konfiguraasjes, anty-DDoS en Windows lisinsjes binne al opnaam yn de priis.
Boarne: www.habr.com