Hayaan akong magkwento ng teknikal na kuwento.
Maraming taon na ang nakalilipas, gumagawa ako ng isang application na may mga tampok sa pakikipagtulungan na nakapaloob dito. Isa itong user-friendly na pang-eksperimentong stack na sinamantala ang buong potensyal ng maagang React at CouchDB. Nag-synchronize ito ng data sa real time sa pamamagitan ng JSON . Ito ay ginamit sa loob ng kumpanya, ngunit ang malawak na kakayahang magamit at potensyal nito sa ibang mga lugar ay malinaw.
Habang sinusubukang ibenta ang teknolohiyang ito sa mga potensyal na kliyente, nakatagpo kami ng hindi inaasahang balakid. Sa demo na video, ang aming teknolohiya ay tumingin at gumana nang mahusay, walang mga problema doon. Ang video ay nagpakita nang eksakto kung paano ito gumagana at hindi ginaya ang anuman. Nakabuo kami at nag-code ng isang makatotohanang senaryo para sa paggamit ng programa.
Sa katunayan, ito ang naging problema. Eksaktong gumana ang aming demo sa paraan ng pag-simulate ng iba sa kanilang mga application. Sa partikular, ang impormasyon ay agad na inilipat mula A hanggang B, kahit na ito ay malalaking media file. Pagkatapos mag-log in, ang bawat user ay nakakita ng mga bagong entry. Gamit ang application, ang iba't ibang mga user ay maaaring magtulungan nang malinaw sa parehong mga proyekto, kahit na ang koneksyon sa Internet ay nagambala sa isang lugar sa nayon. Ito ay implicitly na ipinahiwatig sa anumang produkto na video cut sa After Effects.
Kahit na alam ng lahat kung para saan ang Refresh button, walang nakakaunawa na ang mga web application na hiniling nila sa amin na buuin ay karaniwang napapailalim sa sarili nilang mga limitasyon. At na kung hindi na sila kailangan, ang karanasan ng user ay magiging ganap na naiiba. Karamihan sa mga ito ay napansin na maaari silang "mag-chat" sa pamamagitan ng pag-iiwan ng mga tala para sa mga taong kausap nila, kaya nagtaka sila kung paano ito naiiba sa, halimbawa, Slack. Phew!
Disenyo ng pang-araw-araw na pag-sync
Kung mayroon kang karanasan sa pag-develop ng software, ito ay dapat maging nerve-wracking na tandaan na karamihan sa mga tao ay hindi maaaring tumingin lamang sa isang larawan ng isang interface at maunawaan kung ano ang gagawin nito kapag nakikipag-ugnayan dito. Hindi banggitin kung ano ang nangyayari sa loob mismo ng programa. Kaalaman yan maaari Ang mangyayari ay higit sa lahat ay resulta ng pag-alam kung ano ang hindi maaaring mangyari at kung ano ang hindi dapat mangyari. Nangangailangan ito hindi lamang kung ano ang ginagawa ng software, kundi pati na rin kung paano ang mga indibidwal na bahagi nito ay coordinated at nakikipag-usap sa isa't isa.
Ang isang klasikong halimbawa nito ay isang user na nakatingin sa a spinner.gif, iniisip kung kailan matatapos ang gawain. Napagtanto ng developer na ang proseso ay malamang na natigil at ang gif ay hindi kailanman mawawala sa screen. Ginagaya ng animation na ito ang pagsasagawa ng isang trabaho, ngunit hindi nauugnay sa estado nito. Sa ganitong mga kaso, ang ilang mga techie ay gustong iikot ang kanilang mga mata, na namangha sa lawak ng pagkalito ng gumagamit. Gayunpaman, pansinin kung ilan sa kanila ang tumuturo sa umiikot na orasan at sabihin na ito ay talagang nakatigil?
Ito ang kakanyahan ng real-time na halaga. Sa mga araw na ito, ang mga real-time na database ay kakaunti pa ring ginagamit at maraming tao ang tumitingin sa kanila nang may hinala. Karamihan sa mga database na ito ay nakasandal nang husto sa istilo ng NoSQL, kaya naman kadalasan ay gumagamit sila ng mga solusyong batay sa Mongo, na pinakamainam na nakalimutan. Gayunpaman, para sa akin ito ay nangangahulugan ng pagiging komportable na magtrabaho kasama ang CouchDB, pati na rin ang pag-aaral na magdisenyo ng mga istruktura na higit pa sa ilang burukrata ay maaaring punan ng data. Sa tingin ko mas ginagamit ko ang oras ko.
Ngunit ang totoong paksa ng post na ito ay ang ginagamit ko ngayon. Hindi sa pamamagitan ng pagpili, ngunit dahil sa walang malasakit at bulag na inilapat na mga patakaran ng korporasyon. Kaya magbibigay ako ng Ganap na Patas at Walang pinapanigan na paghahambing ng dalawang malapit na nauugnay na produkto ng Google real-time na database.
Parehong may salitang Apoy sa kanilang mga pangalan. Isang bagay na naaalala ko. Ang pangalawang bagay para sa akin ay ibang uri ng apoy. Hindi ako nagmamadaling sabihin ang kanilang mga pangalan, dahil kapag nagawa ko na, tatakbo tayo sa unang malaking problema: mga pangalan.
Ang una ay tinawag Real-Time na Database ng Firebase, at pangalawa - Firebase Cloud Firestore. Pareho silang mga produkto mula sa Firebase suite Google. Ang kanilang mga API ay tinatawag ayon sa pagkakabanggit firebase.database(β¦) ΠΈ firebase.firestore(β¦).
Nangyari ito dahil Real-Time na Database - original lang yan Firebase bago ito binili ng Google noong 2014. Pagkatapos ay nagpasya ang Google na lumikha bilang isang parallel na produkto kopya Ang Firebase ay batay sa malaking kumpanya ng data, at tinawag itong Firestore na may cloud. Sana hindi ka pa nalilito. Kung nalilito ka pa rin, huwag mag-alala, sampung beses kong isinulat muli ang bahaging ito ng artikulo.
Dahil kailangan mong ipahiwatig Firebase sa tanong ng Firebase, at Firestore sa isang tanong tungkol sa Firebase, kahit man lang para maintindihan ka ilang taon na ang nakalipas sa Stack Overflow.
Kung may award para sa pinakamasamang karanasan sa pagbibigay ng pangalan sa software, tiyak na isa ito sa mga kalaban. Ang distansya ng Hamming sa pagitan ng mga pangalang ito ay napakaliit na nalilito kahit sa mga may karanasang inhinyero na ang mga daliri ay nagta-type ng isang pangalan habang ang kanilang mga ulo ay nag-iisip tungkol sa isa pa. Ito ay mga planong may mabuting layunin na mabibigo; tinupad nila ang propesiya na masusunog ang database. At hindi ako nagbibiro. Nagdulot ng dugo, pawis at luha ang taong gumawa ng ganitong pamamaraan ng pagpapangalan.
Pyrrhic na tagumpay
Iisipin ng isa na ang Firestore ay kapalit Firebase, ang susunod na henerasyong inapo nito, ngunit mapanlinlang iyon. Hindi ginagarantiyahan ang Firestore na maging angkop na kapalit para sa Firebase. Mukhang may nag-cut ng lahat ng kawili-wili mula rito, at nalito ang karamihan sa iba sa iba't ibang paraan.
Gayunpaman, ang isang mabilis na sulyap sa dalawang produkto ay maaaring malito sa iyo: tila ginagawa nila ang parehong bagay, sa pamamagitan ng karaniwang parehong mga API at kahit na sa parehong session ng database. Ang mga pagkakaiba ay banayad at inihayag lamang sa pamamagitan ng maingat na paghahambing na pag-aaral ng malawak na dokumentasyon. O kapag sinusubukan mong i-port ang code na gumagana nang perpekto sa Firebase para gumana ito sa Firestore. Kahit na pagkatapos ay nalaman mo na ang interface ng database ay umiilaw sa sandaling subukan mong i-drag at i-drop gamit ang mouse sa real time. Uulitin ko, hindi ako nagbibiro.
Ang kliyente ng Firebase ay magalang sa kahulugan na nag-buffer ito ng mga pagbabago at awtomatikong sumusubok muli ng mga update na nagbibigay ng priyoridad sa huling operasyon ng pagsulat. Gayunpaman, ang Firestore ay may limitasyon na 1 write operation bawat dokumento bawat user bawat segundo, at ang limitasyong ito ay ipinapatupad ng server. Kapag nagtatrabaho dito, nasa sa iyo na maghanap ng paraan sa pag-iwas dito at magpatupad ng limiter ng rate ng pag-update, kahit na sinusubukan mo lang na buuin ang iyong application. Ibig sabihin, ang Firestore ay isang real-time na database na walang real-time na kliyente, na nagpapanggap bilang isa gamit ang isang API.
Dito nagsisimula kaming makita ang mga unang palatandaan ng raison d'Γͺtre ng Firestore. Maaaring mali ako, ngunit pinaghihinalaan ko na ang isang mataas sa pamamahala ng Google ay tumingin sa Firebase pagkatapos ng pagbili at simpleng sinabi, "Hindi, oh my God, hindi. Ito ay hindi katanggap-tanggap. Hindi lang sa ilalim ng aking pamumuno."
Siya ay nagpakita mula sa kanyang mga silid at ipinahayag:
"Isang malaking dokumento ng JSON? Hindi. Hahatiin mo ang data sa magkakahiwalay na mga dokumento, na ang bawat isa ay hindi hihigit sa 1 megabyte ang laki."
Tila ang gayong limitasyon ay hindi makakaligtas sa unang pakikipagtagpo sa anumang sapat na motivated na base ng gumagamit. Alam mo na. Sa trabaho, halimbawa, mayroon kaming higit sa isa at kalahating libong mga presentasyon, at ito ay Ganap na Normal.
Sa limitasyong ito, mapipilitan kang tanggapin ang katotohanan na ang isang "dokumento" sa database ay hindi magiging katulad ng anumang bagay na maaaring tawagan ng isang user sa isang dokumento.
"Mga array ng mga array na maaaring recursively maglaman ng iba pang mga elemento? Hindi. Ang mga array ay maglalaman lamang ng mga bagay o numero na nakapirming haba, gaya ng nilayon ng Diyos."
Kaya kung umaasa kang ilagay ang GeoJSON sa iyong Firestore, malalaman mong hindi ito posible. Walang katanggap-tanggap na non-one-dimensional. Sana ay magustuhan mo ang Base64 at/o JSON sa loob ng JSON.
βPag-import at pag-export ng JSON sa pamamagitan ng HTTP, command line tool o admin panel? Hindi. Magagawa mo lang mag-export at mag-import ng data sa Google Cloud Storage. Iyon ang tawag ngayon, sa tingin ko. At kapag sinabi kong "ikaw," tinutugunan ko lamang ang mga may kredensyal ng May-ari ng Proyekto. Ang iba ay maaaring pumunta at lumikha ng mga tiket."
Gaya ng nakikita mo, ang modelo ng data ng FireBase ay madaling ilarawan. Naglalaman ito ng isang malaking dokumento ng JSON na nag-uugnay ng mga JSON key sa mga path ng URL. Kung sumulat ka kasama ng HTTP PUT Π² / Ang FireBase ay ang sumusunod:
{
"hello": "world"
}
Pagkatapos GET /hello babalik "world". Talaga ito ay gumagana nang eksakto tulad ng iyong inaasahan. Koleksyon ng mga bagay sa FireBase /my-collection/:id katumbas ng isang diksyunaryo ng JSON {"my-collection": {...}} sa ugat, ang mga nilalaman nito ay magagamit sa /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Gumagana ito nang maayos kung ang bawat insert ay may collision-free ID, kung saan ang system ay may karaniwang solusyon.
Sa madaling salita, ang database ay 100% JSON(*) compatible at mahusay na gumagana sa HTTP, gaya ng CouchDB. Ngunit karaniwang ginagamit mo ito sa pamamagitan ng isang real-time na API na kumukuha ng mga websocket, awtorisasyon, at mga subscription. Ang admin panel ay may parehong mga kakayahan, na nagbibigay-daan sa parehong real-time na pag-edit at JSON import/export. Kung gagawin mo ang parehong sa iyong code, magugulat ka sa kung gaano karaming espesyal na code ang masasayang kapag napagtanto mong nalulutas ng patch at diff JSON ang 90% ng mga nakagawiang gawain ng paghawak ng patuloy na estado.
Ang modelo ng data ng Firestore ay katulad ng JSON, ngunit naiiba sa ilang kritikal na paraan. Nabanggit ko na ang kakulangan ng mga arrays sa loob ng mga arrays. Ang modelo para sa mga sub-collections ay para sa mga ito na maging first class na mga konsepto, na hiwalay sa JSON na dokumento na naglalaman ng mga ito. Dahil walang nakahanda na serialization para dito, kinakailangan ang isang espesyal na landas ng code upang mabawi at magsulat ng data. Para maproseso ang sarili mong mga koleksyon, kailangan mong magsulat ng sarili mong mga script at tool. Pinapayagan ka lamang ng admin panel na gumawa ng maliliit na pagbabago nang paisa-isa, at walang mga kakayahan sa pag-import/pag-export.
Kumuha sila ng real-time na database ng NoSQL at ginawa itong mabagal na non-SQL na may auto-join at isang hiwalay na column na hindi JSON. Isang bagay tulad ng GraftQL.
Mainit na Java
Kung ang Firestore ay dapat na maging mas maaasahan at nasusukat, kung gayon ang kabalintunaan ay ang karaniwang developer ay magkakaroon ng hindi gaanong maaasahang solusyon kaysa sa pagpili ng FireBase sa labas ng kahon. Ang uri ng software na kailangan ng Grumpy Database Administrator ay nangangailangan ng antas ng pagsisikap at kalibre ng talento na sadyang hindi makatotohanan para sa angkop na lugar kung saan dapat na mahusay ang produkto. Ito ay katulad ng kung paano hindi kapalit ng Flash ang HTML5 Canvas kung walang mga tool sa pag-develop at isang player. Bukod dito, ang Firestore ay nababalot sa isang pagnanais para sa kadalisayan ng data at sterile validation na sadyang hindi umaayon sa kung paano ang karaniwang gumagamit ng negosyo mahilig magtrabaho: para sa kanya ang lahat ay opsyonal, dahil hanggang sa huli ang lahat ay draft.
Ang pangunahing kawalan ng FireBase ay ang kliyente ay nilikha ng ilang taon bago ang panahon nito, bago pa alam ng karamihan sa mga web developer ang tungkol sa kawalan ng pagbabago. Dahil dito, ipinapalagay ng FireBase na babaguhin mo ang data at samakatuwid ay hindi sinasamantala ang immutability na ibinigay ng user. Bukod pa rito, hindi nito muling ginagamit ang data sa mga snapshot na ipinapasa nito sa user, na nagpapahirap sa diff. Para sa malalaking dokumento, hindi sapat ang nababagong diff-based na mekanismo ng transaksyon nito. Guys, meron na tayo WeakMap sa JavaScript. Ito ay komportable.
Kung bibigyan mo ang data ng nais na hugis at huwag gawin ang mga puno na masyadong makapal, kung gayon ang problemang ito ay maaaring maiiwasan. Ngunit curious ako kung magiging mas kawili-wili ang FireBase kung ang mga developer ay naglabas ng isang napakahusay na API ng kliyente na gumamit ng immutability na sinamahan ng ilang seryosong praktikal na payo sa disenyo ng database. Sa halip, tila sinubukan nilang ayusin ang hindi nasira, at iyon ay nagpalala.
Hindi ko alam ang lahat ng lohika sa likod ng paglikha ng Firestore. Ang pag-iisip tungkol sa mga motibo na lumitaw sa loob ng itim na kahon ay bahagi din ng kasiyahan. Ang pagtatambal na ito ng dalawang lubhang magkatulad ngunit hindi maihahambing na mga database ay medyo bihira. Parang may naisip: "Ang Firebase ay isang function lamang na maaari nating tularan sa Google Cloud", ngunit hindi pa natutuklasan ang konsepto ng pagtukoy sa mga kinakailangan sa totoong mundo o paggawa ng mga kapaki-pakinabang na solusyon na nakakatugon sa lahat ng kinakailangang iyon. "Hayaan ang mga developer na mag-isip tungkol dito. Pagandahin mo lang ang UI... Pwede ka bang magdagdag ng apoy?β
Naiintindihan ko ang ilang bagay tungkol sa mga istruktura ng data. Talagang nakikita ko ang konsepto ng "lahat ng bagay sa isang malaking puno ng JSON" bilang isang pagtatangka na i-abstract ang anumang kahulugan ng malakihang istraktura mula sa database. Ang pag-asa sa software na makayanan lamang ang anumang kahina-hinalang fractal ng istruktura ng data ay sadyang nakakabaliw. Hindi ko na kailangang isipin kung gaano kasama ang mga bagay, nakagawa na ako ng mahigpit na pag-audit ng code at Nakita ko ang mga bagay na hindi mo pinangarap. Ngunit alam ko rin kung ano ang hitsura ng magagandang istruktura, ΠΈ . Maaari kong isipin ang isang mundo kung saan ang Firestore ay tila lohikal at ang mga taong lumikha nito ay mag-iisip na sila ay gumawa ng isang mahusay na trabaho. Ngunit hindi tayo nabubuhay sa mundong ito.
Ang suporta sa query ng FireBase ay mahirap sa anumang pamantayan at halos wala. Ito ay tiyak na nangangailangan ng pagpapabuti o hindi bababa sa rebisyon. Ngunit hindi gaanong mas mahusay ang Firestore dahil limitado ito sa parehong mga one-dimensional na index na matatagpuan sa plain SQL. Kung kailangan mo ng mga query na pinapatakbo ng mga tao sa magulong data, kailangan mo ng full-text na paghahanap, multi-range na mga filter, at custom na pag-order na tinukoy ng user. Sa mas malapit na pagsisiyasat, ang mga function ng plain SQL ay masyadong limitado sa kanilang sarili. Bukod pa rito, ang tanging SQL query na maaaring patakbuhin ng mga tao sa produksyon ay mga mabilis na query. Kakailanganin mo ng custom na solusyon sa pag-index na may mga istruktura ng matalinong data. Para sa lahat ng iba pa, dapat mayroong kahit na incremental na pagbawas ng mapa o katulad na bagay.
Kung maghahanap ka sa Google Docs para sa impormasyon tungkol dito, sana ay ituro ka sa direksyon ng isang bagay tulad ng BigTable at BigQuery. Gayunpaman, ang lahat ng mga solusyon na ito ay sinamahan ng napakaraming makakapal na corporate sales jargon na mabilis kang babalik at magsimulang maghanap ng iba pa.
Ang huling bagay na gusto mo sa isang real-time na database ay isang bagay na ginawa ng at para sa mga taong nasa management pay scale.
(*) Joke ito, walang ganyan .
Sa Mga Karapatan ng Pag-advertise
Naghahanap ng para sa mga proyekto sa pag-debug, isang server para sa pagpapaunlad at pagho-host? Siguradong ikaw ang aming kliyente π Ang pang-araw-araw na pagpepresyo para sa mga server ng iba't ibang mga pagsasaayos, mga anti-DDoS at mga lisensya sa Windows ay kasama na sa presyo.
Pinagmulan: www.habr.com