Ayo kula nyritakake crita teknis.
Akeh taun kepungkur, aku ngembangake aplikasi kanthi fitur kolaborasi sing dibangun. Iku tumpukan eksperimen sing pangguna-loropaken sing njupuk kauntungan saka potensial lengkap React awal lan CouchDB. Iku nyelarasake data ing wektu nyata liwat JSON . Iki digunakake sacara internal ing perusahaan, nanging ditrapake lan potensial ing wilayah liyane wis jelas.
Nalika nyoba adol teknologi iki menyang klien potensial, kita nemoni alangan sing ora dikarepake. Ing video demo, teknologi kita katon lan kerjane apik, ora ana masalah. Video kasebut nuduhake cara kerjane lan ora niru apa-apa. We teka munggah karo lan kode skenario nyata kanggo nggunakake program.
Nyatane, iki dadi masalah. Tur kita kerjane persis kaya wong liya nggawe simulasi aplikasi kasebut. Khusus, informasi langsung ditransfer saka A menyang B, sanajan file media gedhe. Sawise mlebu, saben pangguna ndeleng entri anyar. Nggunakake aplikasi kasebut, pangguna sing beda-beda bisa kerja bareng kanthi jelas ing proyek sing padha, sanajan sambungan Internet diganggu ing endi wae ing desa kasebut. Iki diwenehake kanthi implisit ing potongan video produk ing After Effects.
Sanajan kabeh wong ngerti apa tombol Refresh, ora ana sing ngerti yen aplikasi web sing dijaluk dibangun biasane tundhuk watesan dhewe. Lan yen ora dibutuhake maneh, pengalaman pangguna bakal beda banget. Biasane dheweke ngeweruhi yen dheweke bisa "ngobrol" kanthi ninggalake cathetan kanggo wong sing diajak guneman, mula dheweke kepengin weruh kepiye bedane, contone, Slack. Phew!
Desain sinkronisasi saben dina
Yen sampeyan duwe pengalaman ing pangembangan piranti lunak, iku kudu syaraf-wracking kanggo elinga sing paling wong ora mung bisa ndeleng gambar saka antarmuka lan ngerti apa bakal nindakake nalika sesambungan karo. Ora kanggo sebutno apa mengkono nang program dhewe. Kawruh sing bisa kedaden umume minangka asil saka ngerti apa sing ora bisa kelakon lan apa sing ora kudu kelakon. Iki mbutuhake ora mung apa piranti lunak, nanging uga carane bagean individu sing tumata lan komunikasi karo saben liyane.
Conto klasik iki yaiku pangguna sing nyawang a spinner.gif, kepingin weruh kapan karya bakal rampung. Pangembang bakal ngerti yen proses kasebut bisa uga macet lan gif ora bakal ilang saka layar. Animasi iki simulates eksekusi proyek, nanging ora ana hubungane karo negara. Ing kasus kaya mengkono, sawetara teknisi seneng muter mripat, gumun ing ombone kebingungan pangguna. Nanging, sok dong mirsani carane akeh wong nuduhake jam puteran lan ngomong sing iku bener stasioner?
Iki minangka inti saka nilai wektu nyata. Dina iki, basis data wektu nyata isih jarang digunakake lan akeh wong sing curiga. Umume basis data iki condong banget marang gaya NoSQL, mula biasane nggunakake solusi adhedhasar Mongo, sing paling lali. Nanging, kanggo kula iki tegese dadi nyaman nggarap CouchDB, uga sinau kanggo ngrancang struktur sing luwih saka sawetara birokrat bisa ngisi data. Aku mikir aku nggunakake wektu luwih apik.
Nanging topik nyata kiriman iki yaiku sing dakgunakake saiki. Ora dening pilihan, nanging amarga indifferently lan wuta kabijakan perusahaan. Dadi, aku bakal nyedhiyakake perbandingan sing Adil lan Ora Bias saka rong produk basis data wektu nyata Google sing raket banget.
Loro-lorone duwe tembung Geni ing jenenge. Siji bab aku elinga fondly. Sing nomer loro kanggo aku yaiku jinis geni sing beda. Aku ora cepet-cepet nyebutake jenenge, amarga yen aku nindakake, kita bakal nemoni masalah gedhe sing pertama: jeneng.
Sing pisanan diarani Firebase Real-Time Database, lan nomer loro - Firebase Cloud Firestore. Loro-lorone produk saka Firebase suite Google. API kasebut diarani masing-masing firebase.database(β¦) ΠΈ firebase.firestore(β¦).
Iki kedadeyan amarga Database Real-Time - iku mung asli Firebase sadurunge dituku dening Google ing 2014. Banjur Google mutusake nggawe minangka produk paralel nyalin Firebase adhedhasar perusahaan data gedhe, lan diarani Firestore kanthi awan. Muga-muga sampeyan durung bingung. Yen sampeyan isih bingung, aja kuwatir, aku dhewe nulis maneh bagean artikel iki kaping sepuluh.
Amarga sampeyan kudu nuduhake Firebase ing pitakonan Firebase, lan Firestore ing pitakonan babagan Firebase, paling ora kanggo nggawe sampeyan ngerti sawetara taun kepungkur ing Stack Overflow.
Yen ana penghargaan kanggo pengalaman jeneng piranti lunak paling awon, iki mesthi bakal dadi salah sawijining pesaing. Jarak Hamming antarane jeneng iki dadi cilik sing confuses malah engineers experienced sing driji ngetik siji jeneng nalika sirahe mikir bab liyane. Iki minangka rencana kanthi niat sing gagal banget; padha kawujud wangsit sing database bakal ing geni. Lan aku ora guyon babar pisan. Wong sing nggawe skema jeneng iki nyebabake getih, kringet lan luh.
kamenangan Pyrrhic
Siji bakal mikir sing Firestore punika panggantos Firebase, turunane generasi sabanjure, nanging bakal mblusukake. Firestore ora dijamin minangka panggantos cocok kanggo Firebase. Iku katon kaya wong Cut metu kabeh menarik saka iku, lan bingung paling liyane ing macem-macem cara.
Nanging, kanthi cepet ing rong produk kasebut bisa uga mbingungake sampeyan: padha nindakake perkara sing padha, liwat API sing padha lan malah ing sesi database sing padha. Bentenipun subtle lan dicethakakΓ© mung dening studi komparatif sing teliti saka dokumentasi ekstensif. Utawa nalika sampeyan nyoba ngirim kode port sing bisa digunakake ing Firebase supaya bisa digunakake karo Firestore. Malah banjur sampeyan mangerteni yen antarmuka database murup sanalika sampeyan nyoba nyeret lan nyelehake mouse ing wektu nyata. Aku mbaleni, aku ora guyon.
Klien Firebase sopan ing pangertèn sing buffer owahan lan otomatis maneh nganyari sing menehi prioritas kanggo operasi nulis pungkasan. Nanging, Firestore duwe watesan 1 operasi nulis saben dokumen saben pangguna per detik, lan watesan iki dileksanakake dening server. Nalika nggarap, sampeyan kudu nemokake cara kanggo ngubengi lan ngleksanakake pembatasan tingkat nganyari, sanajan sampeyan lagi nyoba mbangun aplikasi sampeyan. Tegese, Firestore minangka basis data wektu nyata tanpa klien wektu nyata, sing masquerades minangka siji nggunakake API.
Ing kene kita wiwit ndeleng pratandha pisanan saka raison d'Γͺtre Firestore. Aku bisa uga salah, nanging aku curiga manawa ana wong sing paling dhuwur ing manajemen Google ndeleng Firebase sawise tuku lan mung kandha, "Ora, ya Allah, ora. Iki ora bisa ditampa. Ora mung ing pimpinanku."
Dheweke metu saka kamar lan ujar:
"Siji dokumen JSON gedhe? Ora. Sampeyan bakal misahake data dadi dokumen sing kapisah, sing saben ukurane ora luwih saka 1 megabyte.
Kayane watesan kasebut ora bakal bisa urip nalika ketemu pisanan karo basis pangguna sing cukup motivasi. Sampeyan ngerti iku. Ing karya, contone, kita duwe luwih saka siji lan setengah ewu presentations, lan iki Rampung Normal.
Kanthi watesan iki, sampeyan bakal kepeksa nampa kasunyatan manawa siji "dokumen" ing basis data ora bakal padha karo obyek sing bisa diarani dokumen.
"Arrays array sing bisa ngemot unsur liyane kanthi rekursif? Ora. Array mung ngemot obyek utawa angka sing dawane tetep, kaya sing dikarepake dening Gusti Allah."
Dadi yen sampeyan ngarep-arep kanggo nyelehake GeoJSON menyang Firestore, sampeyan bakal nemokake manawa iki ora bisa ditindakake. Ora ana sing ora siji-dimensi sing bisa ditampa. Muga-muga sampeyan seneng Base64 lan / utawa JSON ing JSON.
"Impor lan ekspor JSON liwat HTTP, alat baris perintah utawa panel admin? Ora. Sampeyan mung bakal bisa ngekspor lan ngimpor data menyang Google Cloud Storage. Sing diarani saiki, menurutku. Lan nalika aku ngomong "sampeyan," aku mung ngarahake wong sing duwe kredensial Pemilik Proyek. Kabeh wong liya bisa nggawe tiket."
Kaya sing sampeyan ngerteni, model data FireBase gampang diterangake. Isine siji dokumen JSON gedhe sing nggandhengake kunci JSON karo jalur URL. Yen sampeyan nulis karo HTTP PUT Π² / FireBase minangka ing ngisor iki:
{
"hello": "world"
}
Banjur GET /hello bakal bali "world". Sejatine kerjane persis kaya sing dikarepake. Koleksi obyek FireBase /my-collection/:id padha karo kamus JSON {"my-collection": {...}} ing ROOT, isi kang kasedhiya ing /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Iki dianggo nggoleki yen saben insert duwe ID tabrakan-free, kang sistem wis solusi standar kanggo.
Ing tembung liyane, database 100% JSON(*) kompatibel lan bisa dianggo apik karo HTTP, kayata CouchDB. Nanging dhasar sampeyan nggunakake API nyata-wektu sing abstrak websockets, wewenang, lan lengganan. Panel admin nduweni kabisan loro, ngidini panyuntingan wektu nyata lan impor / ekspor JSON. Yen sampeyan nindakake perkara sing padha ing kode sampeyan, sampeyan bakal kaget amarga akeh kode khusus sing bakal dibuwang nalika sampeyan ngerti yen patch lan diff JSON ngrampungake 90% tugas rutin kanggo nangani negara sing terus-terusan.
Model data Firestore padha karo JSON, nanging beda-beda ing sawetara cara kritis. Aku wis kasebut lack of arrays ing arrays. Model kanggo sub-koleksi yaiku konsep kelas pertama, kapisah saka dokumen JSON sing ngemot. Amarga ora ana serialisasi sing wis siap kanggo iki, path kode khusus dibutuhake kanggo njupuk lan nulis data. Kanggo ngolah koleksi sampeyan dhewe, sampeyan kudu nulis skrip lan alat sampeyan dhewe. Panel admin mung ngidini sampeyan nggawe owah-owahan cilik siji lapangan ing wektu, lan ora duwe kemampuan ngimpor / ekspor.
Dheweke njupuk database NoSQL wektu nyata lan ngowahi dadi non-SQL alon kanthi otomatis gabung lan kolom non-JSON sing kapisah. Kaya GraftQL.
Jawa panas
Yen Firestore mesthine luwih dipercaya lan bisa diukur, mula ironi yaiku pangembang rata-rata bakal entuk solusi sing kurang dipercaya tinimbang milih FireBase metu saka kothak. Jenis piranti lunak sing dibutuhake Administrator Database Grumpy mbutuhake tingkat gaweyan lan kaliber bakat sing mung ora realistis kanggo niche produk sing dikira apik. Iki padha karo carane HTML5 Canvas dudu panggantos kanggo Flash yen ora ana alat pangembangan lan pemain. Kajaba iku, Firestore kepencut ing kepinginan kanggo kemurnian data lan validasi steril sing mung ora cocog karo pangguna bisnis rata-rata. seneng nyambut gawe: kanggo wong kabeh iku opsional, amarga nganti pungkasan kabeh iku konsep.
Kerugian utama FireBase yaiku klien digawe sawetara taun sadurunge, sadurunge umume pangembang web ngerti babagan immutability. Amarga iki, FireBase nganggep yen sampeyan bakal ngganti data lan mulane ora njupuk kauntungan saka immutability sing diwenehake pangguna. Kajaba iku, ora nggunakake maneh data ing jepretan sing dikirim menyang pangguna, sing ndadekake bedane luwih angel. Kanggo dokumen gedhe, mekanisme transaksi adhedhasar beda sing bisa diganti mung ora cukup. Guys, kita wis duwe WeakMap ing JavaScript. Wis nyaman.
Yen sampeyan menehi data bentuk sing dikarepake lan ora nggawe wit-witan sing akeh banget, mula masalah iki bisa diatasi. Nanging aku kepengin weruh yen FireBase bakal luwih menarik yen pangembang ngeculake API klien sing apik banget sing nggunakake immutability digabungake karo sawetara saran praktis sing serius babagan desain database. Nanging, dheweke katon nyoba ndandani apa sing ora rusak, lan iki dadi luwih elek.
Aku ora ngerti kabeh logika konco nggawe Firestore. Spekulasi babagan motif sing muncul ing kothak ireng uga minangka bagian saka kesenengan. Iki juxtaposition saka loro banget padha nanging incomparable database cukup langka. Kaya ana sing mikir: "Firebase mung fungsi sing bisa ditiru ing Google Cloud", nanging durung nemokake konsep ngenali syarat-syarat nyata utawa nggawe solusi sing migunani sing nyukupi kabeh syarat kasebut. "Ayo para pangembang mikir babagan iki. Cukup gawe UI sing apik ... Apa sampeyan bisa nambah geni maneh?"
Aku ngerti sawetara bab struktur data. Aku mesthi ndeleng konsep "kabeh ing siji wit JSON gedhe" minangka upaya kanggo abstrak rasa struktur skala gedhe saka database. Ngarep-arep piranti lunak kanggo ngatasi fraktal struktur data sing meragukan iku pancen edan. Aku malah ora kudu mbayangno carane ala iku bisa, Aku wis rampung audit kode ketat lan Aku weruh barang-barang sing ora tau diimpi-impi. Nanging aku uga ngerti kaya apa struktur sing apik, ΠΈ . Aku bisa mbayangno donya ing ngendi Firestore katon logis lan wong-wong sing nggawe bakal mikir yen dheweke nindakake tugas sing apik. Nanging kita ora manggon ing donya iki.
Dhukungan pitakon FireBase ora ana standar apa wae lan meh ora ana. Mesthi mbutuhake perbaikan utawa paling ora revisi. Nanging Firestore ora luwih apik amarga diwatesi karo indeks siji-dimensi sing padha ditemokake ing SQL biasa. Yen sampeyan butuh pitakon sing ditindakake wong ing data kacau, sampeyan butuh telusuran teks lengkap, saringan multi-range, lan pesenan sing ditemtokake pangguna khusus. Sawise dipriksa kanthi tliti, fungsi SQL kosong diwatesi dhewe. Kajaba iku, mung pitakon SQL sing bisa ditindakake wong ing produksi yaiku pitakon cepet. Sampeyan mbutuhake solusi indeksasi khusus kanthi struktur data sing wicaksana. Kanggo kabeh liyane, paling ora ana tambahan peta-ngurangi utawa sing padha.
Yen sampeyan nggoleki Google Docs kanggo informasi babagan iki, muga-muga sampeyan bakal diarahake menyang arah kaya BigTable lan BigQuery. Nanging, kabeh solusi kasebut diiringi jargon dodolan perusahaan sing akeh banget sing bakal cepet bali lan wiwit golek liyane.
Wangsulan: Bab ingkang pungkasan sampeyan pengin karo database nyata-wektu soko digawe dening lan kanggo wong ing timbangan pembayaran Manajemen.
(*) Iki guyon, ora ana sing kaya ngono .
Ing Hak Iklan
Nggolek kanggo proyek debugging, server kanggo pangembangan lan hosting? Sampeyan mesthi klien kita π Rega saben dina kanggo server saka macem-macem konfigurasi, lisensi anti-DDoS lan Windows wis kalebu ing rega.
Source: www.habr.com