Më lejoni të tregoj një histori teknike.
Shumë vite më parë kam zhvilluar një aplikacion me funksione bashkëpunimi të integruara. Ishte një eksperiment i përshtatshëm me një institut të plotë të potencialit të React dhe CouchDB të hershëm. Ai sinkronizonte të dhënat në kohë reale përmes JSON . Ajo u përdor në punën e brendshme të kompanisë, megjithatë aplikueshmëria e gjerë dhe potenciali në fusha të tjera ishin të qarta.
Duke u përpjekur të shesim këtë teknologji klientëve të mundshëm, u përballëm me një pengesë të papritur. Në videon e demonstrimit, teknologjia jonë dukej dhe funksiononte shkëlqyeshëm, këtu nuk kishte asnjë problem. Videoja tregonte pikërisht se si funksionon dhe nuk ishte asgjë e imituar. Ne shpikëm dhe kodifikuam një skenar realistik për aplikacionin.
Në të vërtetë, kjo ishte problemi. Demoja jonë punonte pikërisht siç imitonin të gjithë aplikacionet e tyre. Në veçanti, informacioni shpërndahej menjëherë nga A në B, edhe nëse ishin skedarë të mëdhenj multimedial. Pas hyrjes në sistem, çdo përdorues shihte regjistrimet e reja. Me anë të aplikacionit, përdorues të ndryshëm mund të punonin së bashku qartë mbi të njëjtat projekte, edhe në rastin e lidhjeve të ndërprera të Internetit diku në fshat. Në një formë të paqartë, diçka e tillë nënkuptohet në çdo video të prishur në After Effects për produktin.
Megjithëse të gjithë e dinin për çfarë do ishte butoni Refresh, askush nuk kuptonte në të vërtetë se aplikacionet web që na kërkojnë të krijojmë, zakonisht kanë kufizimet e veta. Dhe se nëse ato nuk do të duheshin më, përvoja e përdoruesit do të ishte krejt tjetër. Kryesisht ata vërejtën se mund të "bisedonin", duke lënë shënime për të tjerët, e për këtë, pyetën se çfarë e dallonte këtë, për shembull nga Slack. Uf-f-f!
Dizajni i sinkronizimeve të përditshme
NĂ«se keni pĂ«rvojĂ« nĂ« zhvillimin e softuerit, duhet t'ju shqetĂ«sojĂ« nevoja pĂ«r tĂ« mbajtur mend se shumica e njerĂ«zve nuk mund ta shohin thjesht njĂ« pamje tĂ« ndĂ«rfaqes dhe tĂ« kuptojnĂ« se çfarĂ« do tĂ« bĂ«jnĂ« kur ndĂ«rveprojnĂ« me tĂ«. PĂ«r tĂ« mos pĂ«rmendur se çfarĂ« ndodh brenda vetĂ« programit. TĂ« dini se çfarĂ« mund mund tĂ« ndodhĂ« â nĂ« shumĂ« mĂ«nyra Ă«shtĂ« rezultat i njohurive se çfarĂ« nuk mund tĂ« ndodhĂ« dhe çfarĂ« nuk duhet tĂ« ndodhĂ«. PĂ«r kĂ«tĂ« nevojitet jo vetĂ«m pĂ«r atĂ« qĂ« bĂ«n softueri, por edhe pĂ«r mĂ«nyrĂ«n se si janĂ« tĂ« harmonizuara dhe komunikojnĂ« mesazhet e saj individuale.
Një shembull klasik i kësaj është një përdorues që, për njëzet minuta, e shikon spinner.gif, duke u habitur se kur do të përfundojë puna. Një zhvillues do të kuptonte se procesi, me siguri, është ngrirë dhe se gif-i nuk do të zhduket nga ekrani. Kjo animacion imiton kryerjen e punës, por nuk është e lidhur me gjendjen e saj. Në raste të tilla, disa teknikë shpesh e shohin dhe habitin me shkallën e gabimit të përdoruesve. Por, vëreni, kush prej tyre tregon për orët e rrotullimit dhe thotë se ato në të vërtetë janë të palëvizshme?
Kjo është thelbi i vlerës së kohës reale. Sot, bazat e të dhënave në kohë reale përdoren shumë pak, dhe shumë njerëz i shohin ato me dyshim. Shumica e këtyre bazave të të dhënave e ndjekin stilin NoSQL, duke sjellë zgjidhje të bazuara në Mongo, për të cilat do të ishte më mirë të harrohen. Megjithatë, për mua kjo do të thotë komfort në punën me CouchDB, si dhe studimin e projektimit të strukturave që do të jenë në gjendje të mbushen me të dhëna nga ndonjë burokrat. Mendoj se po e shpenzoj kohën time më shumë në mënyrë optimale.
Por tema e vërtetë e këtij postimi është ajo që unë po përdor sot. Jo nga zgjedhja ime, por për shkak të politikës korporative të aplikuar indiferent dhe verbërisht. Prandaj, do të jap një Krahasim të Ndershëm dhe të Paanshëm të dy produkteve të ngushta të lidhura për punën me bazat e të dhënave në kohë reale të Google.
TĂ« dyja kanĂ« fjalĂ«n Fire nĂ« emrat e tyre. NjĂ«ra mĂ« kujton me dashuri. E dyta pĂ«r mua Ă«shtĂ« njĂ« lloj tjetĂ«r flake. Nuk po nxitohem tĂ« them emrat e tyre, sepse sapo ta bĂ«j kĂ«tĂ«, do tĂ« takohemi me problemin e parĂ« tĂ« madh â emrat.
E para quhet Firebase Real-Time Database, ndĂ«rsa e dyta â Firebase Cloud Firestore. TĂ« dyja janĂ« produkte nga Firebase suite Google. API-tĂ« e tyre quhen, pĂ«rkatĂ«sisht, firebase.database(âŠ) dhe firebase.firestore(âŠ).
Kjo ndodhi sepse Real-Time Database â Ă«shtĂ« thjesht origjinal Firebase para blerjes nga Google nĂ« vitin 2014. Pastaj nĂ« Google vendosĂ«n tĂ« krijonin si njĂ« produkt paralel njĂ« kopje tĂ« Firebase duke pĂ«rdorur big data tĂ« kompanisĂ«, dhe e quajtĂ«n Firestore with a cloud. Shpresoj qĂ« tĂ« mos jeni ngatĂ«rruar ende. NĂ«se jeni ngatĂ«rruar, mos u shqetĂ«soni, unĂ« e kam rishkruar kĂ«tĂ« pjesĂ« tĂ« artikullit dhjetĂ« herĂ«.
Sepse duhet të tregoni Firebase në pyetjen për Firebase, dhe Firestore në pyetjen për Firebase, të paktën që të kuptoheni disa vite më parë në Stack Overflow.
Nëse do të ekzistonte një çmim për emërtimin më të keq të produkteve softuerike, ky rast do të ishte patjetër një nga pretenduesit. Distanca Hamming mes këtyre emrave është kaq e vogël, saqë ngatërrohet edhe për inxhinierët më të përvojshëm, të cilët shkruajnë një emër, ndërkohë që mendja e tyre mendon për një tjetër. Këto janë plane të dështuara për të cilat ishin menduar qëllime të mira; ato realizuan profetësinë se databaza do të ishte në flakë. Dhe nuk po bëj shaka. Njeriut që krijoi një skemë emërtimi të tillë i dha shkak për gjak, djersë dhe lot.
Fitorja e Pirros
Mund të mendohet se Firestore është zëvendësim i Firebase, pasardhësi i tij i brezit të ardhshëm, por kjo do të ishte një iluzion. Firestore nuk i përshtatet me siguri rolit të zëvendësuesit të Firebase. Duket se dikush e ka prerë atë nga gjithçka interesante, dhe pjesën e mbetur e ka ngatërruar në mënyra të ndryshme.
Një shikim i shpejtë në dy produkte mund t'ju ngatërrojë: duket se ato bëjnë të njëjtën gjë, duke përdorur kryesisht API të njëjta dhe madje në të njëjtën seancë të bazës së të dhënave. Diferencat janë të dukshme vetëm me një studim të kujdesshëm krahasues të dokumentacionit të gjerë. Ose kur përpiqeni të portoni një kod që punon perfekt në Firebase, që të funksionojë me Firestore. Që atëherë, zbulohet se ndërfaqja e bazës së të dhënave ndizet sapo provoni të realizoni tërheqjen e mausit në kohë reale. E përsëris, nuk po shaka.
Klienti i Firebase është i sjellshëm në atë kuptim që ai bufëron ndryshimet dhe kryen automatikisht përsëritjen e përpjekjeve të azhurnimit, ku prioriteti i jepet operacionit të fundit të shkruajtur. Megjithatë, Firestore ka një kufizim prej 1 operacioni të shkruar për dokument për përdorues në sekondë, dhe ky kufizim vendoset nga serveri. Kur punoni me të, ju vetë duhet të gjeni një mënyrë për ta anashkaluar atë dhe të implementoni një kufizues frekuence azhurnimesh, madje edhe kur thjesht po përpiqeni të krijoni aplikacionin tuaj. Pra, Firestore është një bazë të dhënash në kohë reale pa një klient të kohës reale, e cila maskohet si e tillë përmes API-së.
Këtu fillojmë të shohim shenjat e para të kuptimit të ekzistencës së Firestore. Ndoshta jam gabim, por dyshoj se dikush lart në udhëheqjen e Google shikoi pas blerjes në Firebase dhe thjesht tha: "Jo, o Zot, jo. Kjo është e papranueshme. Vetëm jo nën drejtimin tim."
Ai doli nga dhomat e tij dhe shpalli:
"Një dokument i madh JSON? Jo. Ju do t'i ndani të dhënat në dokumente të veçanta, secili prej të cilëve do të ketë një madhësi prej jo më shumë se 1 megabajt."
Duket se një kufizim i till nuk do të mbijetojë përballë një baze përdoruesish të mjaftueshme. Ju e dini që është kështu. Në punën tonë, për shembull, kemi mbi njëmijë e pesëqind prezantime, dhe kjo është Plotësisht e Normalizuar.
Me një kufizim të tillë, do të jeni të detyruar të pranoni se një "dokumenti" në bazën e të dhënave nuk do të ngjajë me asnjë objekt që përdoruesi mund ta quajë dokument.
«Matrica të matricave, që mund të përmbajnë recursivisht elemente të tjera? Jo. Matrica do të përmbajnë vetëm objekte ose numra me gjatësi fikse, siç është menduar nga Zoti.»
Prandaj, nëse shpresonit të vendosni GeoJSON tuaj në Firestore, do të zbuloni se kjo është e pamundur. Asgjë një-dimensional nuk është e lejueshme. Shpresoj se ju pëlqen Base64 dhe/ose JSON brenda JSON.
«Importi dhe eksporti i JSON përmes HTTP, mjetet e linjës së komandës ose panelin e administratorit? Jo. Ju do të jeni në gjendje të eksportoni dhe importoni vetëm të dhëna në Google Cloud Storage. Kështu duket se quhet tani. Dhe kur thoni "ju", unë i drejtohem vetëm atyre që kanë autorizim si Pronari i Projektit. Të gjithë të tjerët mund të shkojnë dhe të krijojnë tiket.»
Si e shihni, modeli i të dhënave FireBase është i lehtë për t'u përshkruar. Ai përmban një dokument të madh JSON që lidh çelësat e JSON me rrugët URL. Nëse shkruani duke përdorur HTTP PUT në / FireBase si më poshtë:
{
"hello": "world"
} Atëherë GET /hello do të kthejë "world". Në thelb, kjo funksionon ashtu siç e prisni. Koleksioni i objekteve FireBase /my-collection/:id është ekvivalente me një fjalor JSON {"my-collection": {...}} në rrënjë, përmbajtja e të cilit është e aksesueshme në /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Kjo funksionon shkëlqyeshëm, nëse çdo futje ka ID pa kolizione, për çka sistemi ka një zgjidhje standarde.
Me fjalë të tjera, baza e të dhënave është 100% e përputhshme me JSON (*) dhe punon shkëlqyeshëm me HTTP, për shembull, me CouchDB. Por kryesisht e përdorni atë përmes API-së së kohës reale, e cila absktron websockets, autorizimin dhe abonimet. Paneli i administratorit ka të dyja mundësitë, duke lejuar si modifikimet në kohë reale ashtu edhe importimin/eksportimin e JSON. Nëse në kodin tuaj do të qëndroni besnik ndaj të njëjtës, do të befasoheni se sa shumë kod të specializuar do të humbni, kur të kuptoni se patch dhe diff JSON lejojnë zgjidhjen e 90% të detyrave rutine për menaxhimin e gjendjes së qëndrueshme.
Modeli i të dhënave Firestore është i ngjashëm me JSON, por ndryshon në disa aspekte kritikë. Unë e kam përmendur tashmë mungesën e array-ve brenda array-ve. Modeli i sub-collections përqendrohet në bërjen e tyre koncepte të klasës së parë, të ndara nga dokumenti JSON që i përmban ato. Për këtë, nuk ka një serializim të gatshëm, prandaj kërkohet një rrugë e specializuar për ekzekutimin e kodit për të marrë dhe shkruar të dhëna. Për të menaxhuar koleksionet e veta, duhet të shkruani skriptet dhe instrumentet tuaja. Panelet e administratorit lejojnë vetëm ndryshime të vogla për një fushë në çdo herë dhe nuk kanë mundësi importi/exporti.
Ata morën një bazë të dhënash NoSQL në kohë reale dhe e kthen në një non-SQL të ngadaltë me auto-mëbashkimin dhe një kolonë të veçantë jo-JSON. Diçka në stilin e GraftQL.
Java e nxehtë
NĂ«se Firestore duhet tĂ« bĂ«het mĂ« i besueshĂ«m dhe i shkallĂ«zueshĂ«m, ironia Ă«shtĂ« se njĂ« zhvillues mesatar do tĂ« marrĂ« njĂ« zgjidhje mĂ« tĂ« paqĂ«ndrueshme se sa do tĂ« kishte marrĂ« me FireBase "nga kutia". Softueri qĂ« i nevojitet njĂ« Administratori tĂ« Bezdisur tĂ« BazĂ«s sĂ« tĂ« DhĂ«nave kĂ«rkon njĂ« nivel pĂ«rpjekjeje dhe kualifikimi specialistĂ«sh, qĂ« Ă«shtĂ« thjesht e pa realizueshme pĂ«r niĆĂ«n ku supozohet tĂ« ketĂ« njĂ« produkt tĂ« mirĂ«. Kjo Ă«shtĂ« si tĂ« thuash se HTML5 Canvas nuk Ă«shtĂ« njĂ« zĂ«vendĂ«sim pĂ«r Flash, nĂ«se nuk ka mjete zhvillimi dhe lojtarĂ«. MĂ« shumĂ«, Firestore Ă«shtĂ« e bllokuar nĂ« pĂ«rpjekjen pĂ«r pastĂ«rtinĂ« e tĂ« dhĂ«nave dhe validimin steril, qĂ« thjesht nuk pĂ«rkon me mĂ«nyrĂ«n se si pĂ«rdoruesi mesatar i biznesit i pĂ«lqen tĂ« punojĂ«: pĂ«r tĂ«, nuk ka asgjĂ« tĂ« panevojshme, sepse deri nĂ« fund gjithçka Ă«shtĂ« njĂ« skicĂ«.
Dobësia kryesore e FireBase është se klienti u krijua disa vite më herët se sa duhej, akoma para se shumica e zhvilluesve të uebit të dinin mbi imutabilitetin. Si rezultat, FireBase supozon se do të ndryshoni të dhënat dhe prandaj nuk shfrytëzon avantazhet që ofrohet nga imutabiliteti i përdoruesit. Për më tepër, ai nuk ripërdor të dhënat në snapshot-et që i dërgon përdoruesit, duke e bërë shumë më të vështirë kryerjen e difeve. Për dokumentet e mëdha, mekanizmi i tij i transaksioneve i bazuar në difet e ndryshueshme është thjesht i papërshtatshëm. O njerëz, ne tashmë e kemi WeakMap në JavaScript. Kjo është e dobishme.
Nëse u jepni të dhënave formën e duhur dhe nuk i bëni pemët tepër të mëdha, atëherë mund ta shmangni këtë problem. Por më intereson, do të ishte FireBase shumë më irrënsishëm nëse zhvilluesit do të lëshonin një API klienti në të vërtetë të mirë, që përdor imutabilitetin në kombinim me këshilla të mira praktikë për strukturën e bazave të të dhënave. Në vend të kësaj, duket se ata përpiqen të riparojnë atë që nuk është thyer, dhe kjo e bën situatën më të keqe.
Nuk e di tĂ«rĂ« logjikĂ«n qĂ« qĂ«ndronte nĂ« krijimin e Firestore. Reflekset mbi motivet qĂ« lindin brenda njĂ« kuti tĂ« zezĂ« janĂ« gjithashtu njĂ« pjesĂ« e argĂ«timit. NjĂ« pĂ«rballje e tillĂ« mes dy bazave tĂ« tĂ« dhĂ«nash jashtĂ«zakonisht tĂ« ngjashme, por tĂ« pa krahasueshme, Ă«shtĂ« shumĂ« e rrallĂ«. ĂshtĂ« sikur dikush mendoi: «Firebase Ă«shtĂ« thjesht njĂ« funksion qĂ« mund ta emulojmĂ« nĂ« Google Cloud», por ende nuk e ka zbuluar konceptin e pĂ«rcaktimit tĂ« kĂ«rkesave tĂ« botĂ«s reale apo krijimin e zgjidhjeve tĂ« dobishme qĂ« pĂ«rmbushin tĂ« gjitha kĂ«to kĂ«rkesa. «LĂ«re kĂ«tĂ« tĂ« mendojnĂ« zhvilluesit. Thjesht bĂ«jeni UI tĂ« bukur⊠ĂfarĂ« do tĂ« thoshte nĂ«se do tĂ« shtonim mĂ« shumĂ« zjarr?»
UnĂ« kuptoj disa gjĂ«ra rreth strukturave tĂ« tĂ« dhĂ«nave. E shoh qartĂ« se koncepti i «gjithçka nĂ« njĂ« pemĂ« tĂ« madhe JSON» Ă«shtĂ« njĂ« pĂ«rpjekje pĂ«r tĂ« abstaraktuar nga baza e tĂ« dhĂ«nave çdo ndjenjĂ« tĂ« njĂ« strukture tĂ« madhe. TĂ« presĂ«sh qĂ« software-i tĂ« pĂ«rballojĂ« çdo fraktal tĂ« dyshimtĂ« tĂ« strukturĂ«s sĂ« tĂ« dhĂ«nave â Ă«shtĂ« thjesht çmenduri. Nuk mĂ« nevojitet as imagjinata pĂ«r tĂ« kuptuar se sa keq mund tĂ« jetĂ«, kam zhvilluar audite tĂ« rrepta tĂ« kodit dhe kam parĂ« gjĂ«ra qĂ« ju, njerĂ«zit, nuk i keni Ă«ndĂ«rruar. Por mĂ«soj gjithashtu se si duken strukturat e mira, dhe . Mund tĂ« imagjinoj njĂ« botĂ« nĂ« tĂ« cilĂ«n Firestore do tĂ« dukej mjaft logjike, dhe ata qĂ« e krijuan atĂ« do tĂ« mendonin se kishin bĂ«rĂ« njĂ« punĂ« tĂ« mirĂ«. Por ne nuk jetojmĂ« nĂ« kĂ«tĂ« botĂ«.
Mbështetje për ndërtimin e pyetjeve në FireBase është e dobët sipas çdo standardi, praktikisht nuk ekziston. Ajo sigurisht që kërkon përmirësim ose të paktën rishikim. Por Firestore nuk është shumë më e mirë, pasi është e kufizuar nga të njëjtat indekse njëdimensionalë që ka SQL-i i thjeshtë. Nëse ju nevojiten pyetje që njerëzit bëjnë me të dhëna kaotike, atëherë kërkohet kërkim i plotë, filtra për disa intervale dhe një renditje e rastit e përcaktuar nga përdoruesi. Duke shqyrtuar me kujdes funksionet e SQL-it të thjeshtë, ato vetë janë shumë të kufizuara. Për më tepër, pyetjet e vetme SQL që njerëzit mund të kryejnë në prodhim janë pyetje të shpejta. Ju do të keni nevojë për një zgjidhje të specializuar për indeksimin me struktura të dhënash të menduara mirë. Për gjithçka tjetër, të paktën duhet të ketë një map-reduce incremental ose diçka të ngjashme.
Nëse kërkoni informacione në dokumentet e Google-it, shpresoj se do t'ju udhëzojnë në diçka si BigTable dhe BigQuery. Megjithatë, të gjitha këto zgjidhje shoqërohen me një volum të madhe të zhargonit të korporatave, kështu që do të ktheheni shpejt mbrapa dhe do të filloni të kërkoni diçka tjetër.
E fundit që ju nevojitet në rastin e një databaze real-time është diçka e krijuar nga njerëzit dhe për njerëzit, që funksionon sipas një skeme pagese për menaxhimin.
(*) ĂshtĂ« njĂ« shaka, nuk ka njĂ« koncept si .
Si reklamë
KĂ«rkoni pĂ«r debugimin e projekteve, njĂ« server pĂ«r zhvillim dhe hostim? Ju jeni klienti ynĂ« i saktĂ« đ Ămime pĂ«r ditĂ« pĂ«r serverĂ«t me konfiguracione tĂ« ndryshme, antiDDoS dhe licenca Windows tashmĂ« tĂ« pĂ«rfshira nĂ« çmim.
Burimi: habr.com
