Dopustite mi da ispričam tehničku priču.
Prije mnogo godina razvijao sam aplikaciju s funkcijama za zajednički rad. Bio je to praktičan eksperimentalni razdjelnik koji je koristio punu sposobnost ranog Reacta i CouchDB-a. U realnom vremenu je sinkronizirao podatke putem JSON-a. . Koristila se unutar tvrtke, no široka primjenjivost i potencijal u drugim područjima bili su očiti.
Pokušavajući prodati ovu tehnologiju potencijalnim klijentima, naišli smo na neočekivanu prepreku. U demo videu naša tehnologija izgleda i funkcionira odlično, tu nema problema. Video prikazuje upravo to kako radi, i u njemu ništa nije imitirano. Osmislili smo i kodirali realističan scenarij primjene programa.
Zapravo, to je i postao problem. Naš demo je radio upravo onako kako su svi drugi imitirali rad svojih aplikacija. Konkretno, informacije su se odmah prenosile od A do B, čak i kada su u pitanju velike medijske datoteke. Nakon prijave, svaki korisnik je mogao vidjeti nove unose. Pomoću aplikacije različiti korisnici mogli su zajedno raditi jasno na istim projektima, čak i u slučaju prekidanih internetskih veza negdje u selu. Ova implicirana ideja prisutna je u svakom videu o proizvodu koji je rezan u After Effectsu.
Iako su svi znali čemu služi gumb za osvježavanje, nitko nije u potpunosti razumio da su web aplikacije, koje od nas traže da ih razvijamo, obično podložne vlastitim ograničenjima. I da ako više nisu potrebne, iskustvo korisnika će biti potpuno drugačije. Uglavnom su primijetili da mogu 'chatati', ostavljajući poruke drugima, pa su se pitali čime se to razlikuje, na primjer, od Slacka. Uf-f-f!
Dizajn svakodnevnih sinkronizacija
Ako već imate iskustva u razvoju softvera, tada vam mora biti iritantno sjećati se da većina ljudi ne može samo pogledati sliku sučelja i razumjeti što će raditi kad s njim interagiraju. Ne govorim o tome što se događa unutar same aplikacije. Znanje o tome može što će se dogoditi — u velikoj mjeri je rezultat saznanja o tome što se ne može dogoditi i što se ne bi smjelo dogoditi. To zahtijeva ne samo ono što softver radi, nego i kako su njegovi dijelovi usklađeni i međusobno komuniciraju.
Klasičan primjer toga je korisnik koji dvadeset minuta gleda na spinner.gif, pitajući se kada će konačno završiti rad. Programer bi shvatio da je proces vjerojatno zapet i da gif nikada neće nestati s ekrana. Ova animacija imitira napredovanje rada, ali nije povezana s njegovim stanjem. U takvim slučajevima neki tehničari vole prevrnuti očima, zadivljeni razinom zablude korisnika. Međutim, primijetite, tko od njih pokazuje na vrteće satove i tvrdi da oni zapravo miruju?
U tome leži suština vrijednosti stvarnog vremena. Danas se baze podataka u stvarnom vremenu i dalje koriste vrlo rijetko, a mnogi ih gledaju sumnjičavo. Većina takvih baza podataka aktivno se naginje prema NoSQL stilu, zbog čega se obično koriste rješenja temeljena na Mongo, o kojima je najbolje zaboraviti. Međutim, za mene to znači udobnost rada s CouchDB-om, kao i istraživanje dizajniranja struktura koje će moći ispunjavati podacima ne samo neki birokrat. Mislim da optimiziranije trošim svoje vrijeme.
Ali prava tema ovog posta je ono što danas koristim. Ne po svom izboru, već zbog ravnodušno i slijepo primjenjivane korporativne politike. Stoga ću pružiti Potpuno Pošteno i Objektivno uspoređivanje dva usko povezana proizvoda za rad s bazama podataka u stvarnom vremenu iz Googlea.
Oba imaju riječ Fire u nazivu. Jedno se sjećam s ljubavlju. Drugo za mene predstavlja drugu vrstu vatre. Ne žurim s izgovaranjem njihovih naziva, jer čim to učinim, suočit ćemo se s prvim velikim problemom — imenima.
Prvi se zove Firebase Real-Time Database, a drugi — Firebase Cloud Firestore. Oboth su proizvodi iz Firebase suite Googlea. Njihova API-ja nazivaju se, redom, firebase.database(…) i firebase.firestore(…).
To se dogodilo jer je Real-Time Database — to je jednostavno izvorni Firebase prije nego što ga je Google kupio 2014. godine. Tada je Google odlučio stvoriti paralelni proizvod kao kopiju Firebase na temelju big data kompanije, i nazvao ga Firestore s oblakom. Nadam se da se još niste zbunili. Ako ste se ipak zbunili, ne brinite, sam sam deset puta prepisivao ovaj dio članka. Jer je potrebno navesti
Jer je potrebno navesti Firebase u pitanju Firebase, i Firestore u vezi s Firebase, barem da vas razumiju prije nekoliko godina na Stack Overflowu.
Da postoji nagrada za najgore imenovanje softverskih proizvoda, ovaj slučaj bi zasigurno bio jedan od kandidata. Hammingova udaljenost između ovih imena je toliko mala da zbunjuje čak i iskusne inženjere, čiji prsti kucaju jedno ime, dok misli lutaju prema drugom. To su planovi koji su propali s velikim intenzitetom, smišljeni s najboljim namjerama; ispunili su proricanje da će baza podataka izgorjeti. I ne šalim se. Osoba koja je smislila takav sustav imenovanja postala je uzrok krvi, znoja i suza.
Pirova pobjeda
Moglo bi se pomisliti da je Firestore zamjena Firebase, njegov sljedeći generacijski potomak, ali to bi bila zabluda. Firestore nikako nije prikladan kao zamjena za Firebase. Izgleda kao da je netko izvadio sve zanimljivo iz njega, a većinu preostaloga izmiješao na razne načine.
Međutim, brz pogled na dva proizvoda može vas zbuniti: čini se da rade isto, kroz uglavnom iste API-je i čak u istoj sesiji baza podataka. Razlike su nevidljive i otkrivaju se samo pri detaljnom usporednom proučavanju opsežne dokumentacije. Ili kada pokušavate portirati kod koji savršeno radi na Firebaseu da bi funkcionirao s Firestoreom. Već tada otkrivate da su sučelja baza podataka u problemu čim pokušate izvršiti povlačenje mišem u stvarnom vremenu. Ponovno, ne šalim se.
Firebase klijent je obazriv u smislu da kešira promjene i automatski ponavlja pokušaje ažuriranja, pri čemu se prioritet daje posljednjoj operaciji zapisivanja. Međutim, Firestore ima ograničenje od 1 operacije zapisivanja po dokumentu po korisniku u sekundi, a to ograničenje postavlja poslužitelj. Kada radite s njim, sami morate pronaći način da ga zaobiđete i implementirate ograničivač brzine ažuriranja, čak i kad samo pokušavate izraditi svoju aplikaciju. Drugim riječima, Firestore je baza podataka u stvarnom vremenu bez klijenta u stvarnom vremenu, koja se pretvara u takvu pomoću API-ja.
Time počinjemo vidjeti prve znakove smisla postojanja Firestore-a. Možda griješim, ali sumnjam da je netko visoko u upravi Googlea pogledao nakon kupnje Firebasea i jednostavno rekao: „Ne, bože moj, ne. To je neprihvatljivo. Samo ne pod mojim vodstvom.“
Pojavio se iz svojih odaja i proglasio:
„Jedan veliki JSON dokument? Ne. Podijelit ćete podatke na odvojene dokumente, od kojih će svaki biti veličine ne veće od 1 megabajta.“
Izgleda da takvo ograničenje neće preživjeti prvo suočavanje s bilo kojom dovoljno motiviranom bazom korisnika. Znate da je to točno. U našem poslu, na primjer, imamo više od dvije i pol tisuće prezentacija, i to je sasvim normalno.
S takvim ograničenjem bit ćete primorani pomiriti se s činjenicom da jedan „dokument“ u bazi podataka neće nalikovati ni jednom objektu koji bi korisnik mogao nazvati dokumentom.
„Mase nizova koji mogu rekurzivno sadržavati druge elemente? Ne. Nizovi će sadržavati samo objekte ili brojeve fiksne dužine, kako je zamislio Gospodin.“
Stoga, ako ste se nadali da ćete staviti svoj Firestore GeoJSON, otkrit ćete da to nije moguće. Ništa višedimenzionalno nije dozvoljeno. Nadam se da volite Base64 i/ili JSON unutar JSON-a.
„Uvoz i izvoz JSON-a putem HTTP-a, alati naredbenog retka ili administrativna ploča? Ne. Možete samo izvoziti i uvoziti podatke u Google Cloud Storage. Tako, čini se, sada zovu. I kada kažem 'vi', obraćam se samo onima koji imaju ovlasti Project Owner. Svi ostali mogu ići i otvoriti tikete.“
Kao što vidite, model podataka FireBase-a lako je opisati. Sadrži jedan ogroman JSON dokument koji povezuje JSON ključeve s URL putanjama. Ako zapišete pomoću HTTP PUT u / FireBase sljedeće:
{
"hello": "world"
} Onda GET /hello vratit će "world". Uglavnom to funkcionira onako kako očekujete. Kolekcija objekata FireBase-a /my-collection/:id ekvivalentna je JSON rječniku {"my-collection": {...}} u korijenu, čiji je sadržaj dostupan u /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}To funkcionira odlično, ako svaki umetak ima ID bez kolizija, za što sustav ima standardno rješenje.
Drugim riječima, baza podataka je 100% kompatibilna s JSON (*) i odlično funkcionira s HTTP-om, primjerice s CouchDB. No, u osnovi je koristite putem API-a u stvarnom vremenu, koji apstrahira websockets, autorizaciju i pretplate. Administratorska ploča ima obje mogućnosti, omogućujući uređivanje u stvarnom vremenu i uvoz/izvoz JSON-a. Ako se u svom kodu pridržavate istog, iznenadit ćete se koliko će specijaliziranog koda nestati kada shvatite da patch i diff JSON omogućuju rješavanje 90% rutinskih zadataka obrade trajnog stanja.
Model podataka Firestore sličan je JSON-u, ali se u nekim ključnim aspektima razlikuje od njega. Već sam spomenuo odsutnost nizova unutar nizova. Model podkolekcija podrazumijeva da su oni prvoklasne koncepcije, odvojene od JSON dokumenta koji ih sadrži. Budući da za ovo ne postoji gotova serijalizacija, za dohvat i zapis podataka potrebna je specijalizirana putanja izvršavanja koda. Za obradu vlastitih kolekcija potrebno je pisati vlastite skripte i alate. Administratorska ploča omogućava vam da unesete samo male promjene po polju odjednom i nema mogućnosti uvoza/izvoza.
Uzeli su NoSQL bazu podataka u stvarnom vremenu i pretvorili je u sporu ne-SQL bazu s automatskim spajanjem i odvojenim stupcem koji nije JSON. Nešto poput GraftQL.
Vruća Java
Ako je Firestore trebao postati pouzdaniji i skalabilniji, ironija je u tome što prosječni programer dobiva manje pouzdano rješenje nego kada bira FireBase 'iz kutije'. Softver koji je potreban Mrzovoljnom Administratoru Baze Podataka zahtijeva takvu razinu napora i kalibra stručnjaka da je to jednostavno nerealno za nišu u kojoj bi, pretpostavljam, trebao biti dobar proizvod. To je kao da HTML5 Canvas zapravo nije zamjena za Flash ako nema alata za razvoj i playera. Štoviše, Firestore je zapao u težnju za čistoćom podataka i sterilnom validacijom, što jednostavno ne odgovara načinu na koji prosječan poslovni korisnik voli raditi: za njega nije obavezno, jer je do samog kraja sve zapravo nacrt.
Glavni nedostatak FireBase-a je to što je klijent razvijen nekoliko godina prije vremena, još prije nego što su većina web programera saznala za imutabilnost. Zbog toga FireBase pretpostavlja da ćete mijenjati podatke, stoga ne koristi prednosti imutabilnosti koju korisnici osiguravaju. Također, ne koristi podatke ponovo u proslijeđenim korisničkim snimcima, zbog čega je razlika (diff) daleko složenija. Za velike dokumente njegov mehanizam transakcija temeljen na promjenjivim razlikama jednostavno nije adekvatan. Ljudi, već imamo WeakMap u JavaScriptu. To je praktično.
Ako se podacima pruži pravi oblik, i ne prave se drveća prevelikima, ovaj problem se može zaobići. No, zanima me, bi li FireBase bio mnogo zanimljiviji da su developeri izdali zaista dobar klijentski API, koji bi koristio imutabilnost zajedno s ozbiljnim praktičnim savjetom o strukturi baza podataka. Umjesto toga, čini se da su pokušali popraviti ono što nije pokvareno, i od toga je postalo lošije.
Ne znam svu logiku koja je stajala iza stvaranja Firestore-a. Razmišljanja o motivima unutar crne kutije također su dio zabave. Takvo suprotstavljanje dviju izuzetno sličnih, ali neusporedivih baza podataka se pojavljuje prilično rijetko. Kao da je netko pomislio: „Firebase je jednostavno funkcija koju možemo emulirati u Google Cloud“, ali pritom još nije otkrio koncept definiranja zahtjeva iz stvarnog svijeta ili stvaranja korisnih rješenja koja zadovoljavaju sve te zahtjeve. „Neka o tome razmišljaju developeri. Samo učinite UI lijepim… A da li se može dodati više vatre?“
Razumijem nekoliko stvari o strukturama podataka. Jasno vidim da je koncept „sve u jednom velikom JSON stablu“ pokušaj da se iz baze podataka odstrani bilo kakav osjećaj velike strukture. Očekivati da softver jednostavno riješi bilo koji sumnjivi fraktal strukture podataka je jednostavno ludilo. Ne trebam ni zamišljati koliko loše sve to može biti, radio sam stroge revizije koda i vidio sam stvari o kojima vi, ljudi, niste ni sanjali. No, također znam kako izgledaju dobre strukture, i Mogu zamisliti svijet u kojem bi Firestore djelovao potpuno razumno, a njegovi stvoritelji smatrali bi da su obavili dobar posao. No, ne živimo u tom svijetu.
Podrška za izgradnju upita u FireBase je slaba prema bilo kojim standardima, praktički je ne postoji. Definitivno zahtijeva poboljšanja ili barem reviziju. No, Firestore nije mnogo bolji jer je ograničen na iste jednodimenzionalne indekse koji postoje u jednostavnom SQL-u. Ako su vam potrebni upiti koje ljudi izvode s kaotičnim podacima, potrebna vam je puna tekstna pretraga, filtri po više raspona i proizvoljan redoslijed koji korisnici mogu postaviti. U pažljivom pregledu, osnovne SQL funkcije su same po sebi previše ograničene. Osim toga, jedini SQL upiti koje ljudi mogu izvoditi u produkciji su brzi upiti. Trebat će vam specijalizirano rješenje za indeksiranje s promišljenim strukturama podataka. Za sve ostalo, barem bi trebao biti inkrementalni map-reduce ili nešto slično.
Ako potražite informacije o ovome u Googleovim dokumentima, nadam se da će vam ukazati put prema nečemu poput BigTable i BigQuery. Međutim, sva ta rješenja dolaze s tolikom količinom gustog korporativnog žargona, da ćete se brzo vratiti natrag i početi tražiti nešto drugo.
Posljednje što vam treba u slučaju baze podataka u stvarnom vremenu je nešto stvoreno od strane ljudi i za ljude, koje funkcionira prema platnim skalama menadžmenta.
(*) To je šala, ne postoji takav pojam kao .
U okviru reklame
Tražite poslužitelj za razvoj i hosting koji će vam pomoći u debagiranju projekata? Vi ste definitivno naš klijent 🙂 Naplata poslužitelja raznih konfiguracija po danu, antiDDoS i Windows licence su već uključeni u cijenu.
Izvor: habr.com
