Bila ez çîrokek teknîkî vebêjim.
Gelek sal berê, min serîlêdanek bi taybetmendiyên hevkariyê yên ku tê de hatine çêkirin pêşde dibir. Ew stûnek ezmûnî ya bikarhêner-heval bû ku ji hemî potansiyela destpêkê ya React û CouchDB sûd werdigirt. Ew daneyên di demek rast de bi navgîniya JSON ve hevdem kir . Ew di hundurê pargîdaniyê de hate bikar anîn, lê serîlêdan û potansiyela wê ya berfireh li deverên din diyar bû.
Dema ku em hewl didin ku vê teknolojiyê bifroşin xerîdarên potansiyel, em rastî astengiyek nediyar hatin. Di vîdyoya demo de, teknolojiya me pir xuya bû û xebitî, li wir pirsgirêk tune. Vîdyoyê tam nîşan da ku ew çawa dixebite û tiştek teqlîd nekir. Me ji bo karanîna bernameyê senaryoyek realîst peyda kir û kod kir.
Di rastiyê de, ev pirsgirêk bû. Demoya me tam bi awayê ku her kesê din serîlêdanên xwe simul kir xebitî. Bi taybetî, agahdarî tavilê ji A-ya B hate veguheztin, hetta ew pelên medyayê yên mezin bûn. Piştî têketinê, her bikarhêner navnîşên nû dîtin. Bi karanîna serîlêdanê, bikarhênerên cihêreng dikarin bi zelalî li ser heman projeyan bi hev re bixebitin, tevî ku pêwendiya Înternetê li cîhek gund qut bû. Ev di her vîdyoyek hilberek ku di After Effects de hatî qut kirin de bi eşkere tête destnîşan kirin.
Her çend her kes dizanibû ku bişkoka Refresh ji bo çi ye, kesî bi rastî fêm nekir ku serîlêdanên webê yên ku wan ji me xwestin ku em çêbikin bi gelemperî di bin sînorên xwe de ne. Û ku heke ew êdî hewce nebin, dê ezmûna bikarhêner bi tevahî cûda be. Wan bi piranî ferq kir ku ew dikarin bi hiştina notan ji bo kesên ku pê re dipeyivin re "chat" bikin, ji ber vê yekê wan meraq kir ku ev ji, mînakî, Slack çawa cûda ye. Heyf!
Sêwirana hevdengên rojane
Ger ezmûna we di pêşkeftina nermalavê de hebe, pêdivî ye ku meriv ji bîr mekin ku pir kes nekarin tenê li wêneyek navberekê binihêrin û fam bikin ku ew ê çi bike dema ku pê re têkilî daynin. Nebêjin ka di hundurê bernameyê bixwe de çi diqewime. Dizanin ku dikare diqewime bi piranî encama zanîna ku çi nabe û çi nabe ye. Ev hewce dike ne tenê tiştê ku nermalavê dike, lê di heman demê de beşên wê yên ferdî jî çawa bi hevûdu re têne hevrêz kirin û danûstandinê dikin.
Mînakek klasîk a vê yekê bikarhênerek e ku li a dinêre spinner.gif, meraq dike kengê kar dê di dawiyê de biqede. Pêşvebir dê fêm bikira ku pêvajo belkî asê mabû û ku gif dê çu carî ji ekranê winda nebe. Ev anîmasyon pêkanîna karekî simule dike, lê bi rewşa wê ve ne girêdayî ye. Di rewşên weha de, hin teknolojî hez dikin ku çavên xwe bizivirînin, ji ber asta tevliheviya bikarhêner ecêbmayî dimînin. Lêbelê, bala xwe bidin çend ji wan demjimêra zivirî nîşan didin û dibêjin ku ew bi rastî bêdeng e?
Ev cewhera nirxa rast-dem e. Van rojan, databasên dema rast hîn jî pir hindik têne bikar anîn û gelek kes wan bi guman dibînin. Piraniya van databasan bi giranî ber bi şêwaza NoSQL ve diçin, ji ber vê yekê ew bi gelemperî çareseriyên bingehîn ên Mongo bikar tînin, yên ku çêtirîn têne ji bîr kirin. Lêbelê, ji bo min ev tê vê wateyê ku meriv bi CouchDB re rehet xebitî, û her weha fêrbûna sêwirana strukturên ku ji tenê hin burokrat dikarin bi daneyan tijî bikin. Ez difikirim ku ez wextê xwe çêtir bikar tînim.
Lê mijara rastîn a vê postê ev e ku ez îro bikar tînim. Ne bi bijartinê, lê ji ber polîtîkayên pargîdanî yên bi xemsarî û kor têne sepandin. Ji ber vê yekê ez ê berhevokek Bi tevahî Adil û Bêalî ya du hilberên databasa rastîn ên Google-ê yên ku ji nêz ve têkildar in peyda bikim.
Di navên herduyan de peyva Agir heye. Tiştek bi xweş tê bîra min. Tişta duyemîn ji bo min celebek agir e. Ez ecele nakim ku navên wan bibêjim, ji ber ku gava ez bikim, em ê bi pirsgirêka yekem a mezin re rû bi rû bimînin: nav.
Yekem tê gotin Firebase Database Rast-Time, û duyemîn - Firebase Cloud Firestore. Her du jî berhemên ji suite Firebase Gûgil. API-yên wan bi rêzdarî têne gotin firebase.database(…) и firebase.firestore(…).
Ev çêbû ji ber Daneyên Rast-Time - ew tenê orjînal e Firebase berî kirîna wê ji hêla Google ve di sala 2014 de. Piştre Google biryar da ku wekî hilberek paralel biafirîne kopî Firebase li ser bingeha pargîdaniya daneyên mezin, û jê re Firestore bi ewr re digotin. Ez hêvî dikim ku hûn hîn ne tevlihev bûne. Ger hûn hîn jî tevlihev in, meraq nekin, min bi xwe ev beşa gotarê deh caran ji nû ve nivîsand.
Ji ber ku hûn hewce ne ku destnîşan bikin Firebase di pirsa Firebase, û Firestore di pirsek di derbarê Firebase de, bi kêmanî ji bo ku hûn çend sal berê li ser Stack Overflow fêm bikin.
Ger xelatek ji bo ezmûna navê nermalavê ya herî xirab hebûya, ev ê bê guman yek ji pêşbazan be. Dûrahiya Hamming a di navbera van navan de ew qas hindik e ku ew endezyarên xwedî ezmûn jî tevlihev dike ku tiliyên wan navekî dinivîsînin dema ku serê wan li ser navekî din difikirin. Ev planên bi niyeta baş in ku bi ser nekevin; wan pêxembertiya ku databas wê di agir de be, pêk anîn. Û ez qet henek nakim. Kesê ku bi vê pilana navkirinê derketiye holê, bûye sedema xwîn, xwel û hêstiran.
Serketina Pyrrhic
Mirov dikare bifikire ku Firestor e şûna Firebase, dûndana wê ya nifşê din, lê ew ê xapînok be. Firestore ne garantî ye ku ji bo Firebase veguherînek maqûl be. Wusa dixuye ku kesek her tiştê balkêş jê biriye, û piraniya yên mayî bi awayên cihêreng tevlihev kiriye.
Lêbelê, nihêrînek bilez li du hilberan dibe ku we tevlihev bike: ew dixuye ku heman tiştî dikin, bi bingehîn heman API-yan û tewra di heman danişîna databasê de. Cûdahî nazik in û tenê bi lêkolîna berawirdî ya bi baldarî ya belgeyên berfireh têne eşkere kirin. An jî gava ku hûn hewl didin ku koda ku bi rengek bêkêmasî li ser Firebase-ê dixebite veguhezînin da ku ew bi Firestore re bixebite. Dûv re jî hûn fêhm dikin ku gava ku hûn hewl didin ku di wextê rast de bi mişkê re kaş bikin û dakêşin pêveka databasê ronî dibe. Ez dubare dikim, ez henek nakim.
Muwekîlê Firebase bi wate ye ku ew guheztinan tampon dike û bixweber nûvekirinên ku pêşîniyê didin operasyona nivîsandina paşîn ji nû ve diceribîne. Lêbelê, Firestore xwedan sînorek 1 operasyona nivîsandinê ji bo her bikarhênerek her çirkeyek heye, û ev sînor ji hêla serverê ve tê bicîh kirin. Dema ku hûn pê re dixebitin, li ser we ye ku hûn rêyek li dora wê bibînin û sînordarek rêjeya nûvekirinê bicîh bînin, tewra gava ku hûn tenê hewl didin ku serîlêdana xwe ava bikin. Ango, Firestore databasek rast-dem e bêyî xerîdarek rast-demê, ku wekî yek bi karanîna API-ê tê xuyang kirin.
Li vir em dest bi dîtina nîşanên yekem ên raison d'être ya Firestore dikin. Dibe ku ez xelet bim, lê ez guman dikim ku kesek di rêveberiya Google-ê de bilind e piştî kirînê li Firebase mêze kir û bi hêsanî got, "Na, Xwedayê min, na. Ev nayê qebûlkirin. Tenê ne di bin serokatiya min de ye."
Ew ji odeya xwe derket û got:
"Yek belgeyek mezin a JSON? Na. Hûn ê daneyan li belgeyên cihê dabeş bikin, ku mezinahiya her yek ji wan ji 1 megabyte ne zêdetir be."
Wusa dixuye ku sînorkirinek wusa dê di hevdîtina yekem de bi bingehek bikarhênerek têra xwe motîf re sax neke. Hûn dizanin ew e. Mînakî, di xebatê de, ji hezar û nîvan zêdetir pêşniyarên me hene, û ev bi tevahî normal e.
Bi vê sînordarkirinê, hûn ê neçar bimînin ku vê rastiyê qebûl bikin ku yek "belge" di databasê de dê neşibe tiştek ku bikarhênerek dikare wekî belgeyek binav bike.
"Rêbazên rêzikên ku dikarin bi paşverû hêmanên din vehewînin? Na. Li gorî ku Xwedê xwestiye, array tenê tiştên bi dirêjahî an hejmar hene.
Ji ber vê yekê heke we hêvî dikir ku hûn GeoJSON têxin nav Firestore xwe, hûn ê bibînin ku ev ne mumkin e. Tiştekî ne-yekalî nayê qebûlkirin. Ez hêvî dikim ku hûn di nav JSON de Base64 û / an JSON hez dikin.
"JSON bi HTTP, amûrên rêzika fermanê an panela rêveberiyê ve tê import û hinardekirin? Na. Hûn ê tenê karibin daneyan ji Google Cloud Storage re derxînin û derxînin. Ez wisa difikirim ku niha jê re tê gotin. Û gava ku ez dibêjim "tu", ez tenê xîtabî kesên ku pêbaweriyên Xwediyê Projeyê hene dikim. Her kesên din dikarin biçin û bilêtan çêbikin."
Wekî ku hûn dikarin bibînin, modela daneya FireBase hêsan e ku were ravekirin. Ew yek belgeyek mezin a JSON heye ku bişkojkên JSON bi rêyên URL-ê re têkildar dike. Ger hûn binivîsin HTTP PUT в / FireBase jêrîn e:
{
"hello": "world"
}
The GET /hello dê vegere "world". Di bingeh de ew tam wekî ku hûn hêvî dikin dixebite. Berhevkirina tiştên FireBase /my-collection/:id wekheviya ferhenga JSON {"my-collection": {...}} di kokê de, naveroka ku tê de heye /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Ev baş dixebite ger her têxê nasnameyek bê pevçûn hebe, ku pergalê jê re çareseriyek standard heye.
Bi gotinek din, databas 100% JSON (*) lihevhatî ye û bi HTTP-ê re, wekî CouchDB, baş dixebite. Lê di bingeh de hûn wê bi navgînek API-ya rast-dem-ê ya ku websockets, destûr û aboneyan vedihewîne bikar tînin. Panela rêveberê her du kapasîteyên xwe hene, ku hem guherandina rast-dem û hem jî JSON import/export dike. Ger hûn di koda xwe de heman tiştî bikin, hûn ê şaş bimînin ka çiqas koda pispor dê winda bibe dema ku hûn fêhm bikin ku patch û cûda JSON% 90 ji karên rûtîn ên birêvebirina dewleta domdar çareser dike.
Modela daneya Firestore mîna JSON e, lê di hin awayên krîtîk de cûda dibe. Min berê jî behs nebûna array di nav rêzan de kir. Modela ji bo jêr-koleksiyonan ew e ku ew têgînên çîna yekem bin, ji belgeya JSON ya ku wan vedihewîne veqetînin. Ji ber ku ji bo vê serialîzasyonek amade tune, ji bo wergirtin û nivîsandina daneyan rêyek kodek pispor hewce ye. Ji bo ku hûn berhevokên xwe bişopînin, hûn hewce ne ku nivîs û amûrên xwe binivîsin. Panela rêveberiyê tenê dihêle hûn di yek gavê de guheztinên piçûk bikin, û ne xwediyê kapasîteyên import / hinardekirinê ne.
Wan danegehek NoSQL-ya rast-ê hilda û ew veguherand ne-SQL-ya hêdî ya bi tevlîheviya xweser û stûnek ne-JSON-ê veqetandî. Tiştek mîna GraftQL.
Java germ
Ger Firestore diviyabû ku pêbawertir û berbelavtir be, wê hingê îroniya ev e ku pêşdebirê navîn dê ji bijartina FireBase ji derveyî vebijarka çareseriyek kêmtir pêbawer bi dawî bibe. Cûreyek nermalava ku Rêvebirê Database ya Grumpy hewce dike astek hewildan û jêhatîbûnê hewce dike ku ji bo cîhê ku hilber jê re tê xwestin baş be bi tenê nerealîst e. Ev dişibihe ku çawa HTML5 Canvas ji bo Flash-ê qet ne cîhgirek e heke amûrên pêşkeftinê û lîstikvanek tune be. Digel vê yekê, Firestore di nav xwestekek paqijiya daneyê û pejirandina sterîl de ye ku bi tenê bi bikarhênerê karsaziya navînî re hevûdu nake. ji xebatê hez dike: ji bo wî her tişt vebijarkî ye, ji ber ku heta dawiyê her tişt pêşnivîsek e.
Kêmasiya sereke ya FireBase ev e ku xerîdar çend sal berî dema xwe hate afirandin, berî ku piraniya pêşdebirên malperê di derbarê neguhêrbariyê de zanibin. Ji ber vê yekê, FireBase texmîn dike ku hûn ê daneyan biguhezînin û ji ber vê yekê sûd ji neguhezbariya ku ji hêla bikarhêner ve hatî peyda kirin nagire. Wekî din, ew daneyên di dîmenên ku ji bikarhêner re derbas dike ji nû ve bikar nayîne, ku ev cûdahiyê pir dijwartir dike. Ji bo belgeyên mezin, mekanîzmaya danûstendina wê ya guhêrbar bi tenê ne bes e. Guys, me jixwe heye WeakMap di JavaScript de. Rehet e.
Ger hûn daneyan şeklê xwestinê bidin û daran pir mezin nekin, wê hingê ev pirsgirêk dikare were dorpêç kirin. Lê ez meraq dikim gelo FireBase dê pir balkêştir be ger pêşdebiran API-ya xerîdarek bi rastî baş serbest berdan ku neguhêrbariyê digel hin şîretên pratîkî yên cidî li ser sêwirana databasê bikar tîne. Di şûna wê de, wan dixuye ku hewl didin ku tiştê neşikestî rast bikin, û vê yekê xirabtir kir.
Ez hemû mantiqa li pişt afirandina Firestore nizanim. Spekulasyona li ser motîvên ku di hundurê qutiya reş de derdikevin jî beşek ji kêfê ye. Ev hevberdana du databasên pir dişibin hev lê bêhempa pir kêm e. Mîna ku kesek fikirî: "Firebase tenê fonksiyonek e ku em dikarin di Google Cloud de mîna hev bikin", lê hîna têgeha nasîna hewcedariyên cîhana rastîn an afirandina çareseriyên bikêr ên ku hemî wan hewcedariyên bicîh tîne kifş nekiriye. "Bila pêşdebiran li ser wê bifikirin. Tenê UI xweş bikin... Ma hûn dikarin agirê zêdetir lê zêde bikin?”
Ez çend tiştan di derbarê strukturên daneyê de fam dikim. Ez bê guman têgîna "her tişt di yek dara mezin a JSON de" wekî hewldanek ji bo jêbirina her têgehek avahiyek mezin ji databasê dibînim. Hêviya nermalavê ku bi hêsanî bi her fraktalek daneya gumanbar re mijûl bibe bi tenê dîn e. Tewra ne hewce ye ku ez xeyal bikim ka tiştên çiqas xirab dikarin bibin, min kontrolên kodê yên hişk kiriye û Min tiştên ku we mirov qet xeyal nedikir dît. Lê ez jî dizanim ku strukturên baş çawa xuya dikin, и . Ez dikarim cîhanek bifikirim ku Firestore wê mentiqî xuya bike û mirovên ku wê afirandine dê bifikirin ku wan karek baş kiriye. Lê em li vê dinyayê najîn.
Piştgiriya lêpirsînê ya FireBase ji hêla her standardî ve xizan e û bi pratîkî tune ye. Ew bê guman pêdivî bi başbûnê an bi kêmî ve nûvekirinê heye. Lê Firestore ne pir çêtir e ji ber ku ew bi heman navnîşên yek-alî yên ku di SQL-ya sade de têne dîtin sînorkirî ye. Ger ji we re pirsên ku mirov li ser daneyên kaotîk dimeşînin hewce ne, hûn hewceyê lêgerîna tev-nivîsê, fîlterên pir-range, û fermana xwerû ya ku ji hêla bikarhêner ve hatî destnîşankirin hewce ne. Li ser vekolînek nêzîk, fonksiyonên SQL-ya sade bi serê xwe pir sînordar in. Wekî din, tenê pirsên SQL yên ku mirov dikarin di hilberînê de bimeşînin, pirsên bilez in. Hûn ê hewceyê çareseriyek navnîşek xwerû ya bi strukturên daneya ramanî bin. Ji bo her tiştê din, divê bi kêmanî nexşerê-kêmkirin an tiştek mîna wê hebe.
Ger hûn li Google Docs ji bo agahdariya li ser vê yekê bigerin, hûn hêvîdar in ku hûn di rêça tiştek mîna BigTable û BigQuery de werin destnîşan kirin. Lêbelê, van hemî çareseriyan bi jargonên firotanê yên pargîdanî yên ewqas zexm re têne hev kirin ku hûn ê zû paşde vegerin û dest bi lêgerîna tiştek din bikin.
Tişta paşîn a ku hûn bi databasek rast-dem re dixwazin tiştek e ku ji hêla û ji bo mirovên li ser pîvanên dravê rêveberiyê têne çêkirin.
(*) Ev henek e, tiştekî wisa tune .
Li Mafên Malperê
Pê gerîyan ji bo projeyên debugging, serverek ji bo pêşveçûn û mêvandariyê? Hûn bê guman muwekîlê me ne 🙂 Bihayê rojane ji bo serverên cûrbecûr mîhengan, lîsansên dijî-DDoS û Windows-ê jixwe di bihayê de hene.
Source: www.habr.com