Izinkan saya menceritakan kisah teknisnya.
Bertahun-tahun yang lalu, saya sedang mengembangkan aplikasi dengan fitur kolaborasi di dalamnya. Itu adalah tumpukan eksperimental yang ramah pengguna yang memanfaatkan potensi penuh dari React dan CouchDB awal. Ini menyinkronkan data secara real time melalui JSON . Metode ini digunakan secara internal di dalam perusahaan, namun penerapannya secara luas dan potensinya di bidang lain sudah jelas.
Saat mencoba menjual teknologi ini kepada calon klien, kami menemui kendala yang tidak terduga. Dalam video demo, teknologi kami terlihat dan bekerja dengan baik, tidak ada masalah. Video tersebut menunjukkan dengan tepat cara kerjanya dan tidak meniru apa pun. Kami membuat dan membuat kode skenario realistis untuk menggunakan program ini.
Faktanya, hal ini menjadi masalah. Demo kami bekerja persis seperti orang lain menyimulasikan aplikasi mereka. Secara khusus, informasi ditransfer secara instan dari A ke B, meskipun itu adalah file media berukuran besar. Setelah masuk, setiap pengguna melihat entri baru. Dengan menggunakan aplikasi ini, pengguna yang berbeda dapat bekerja sama dengan jelas pada proyek yang sama, bahkan jika koneksi Internet terputus di suatu tempat di desa. Hal ini secara implisit tersirat dalam setiap potongan video produk di After Effects.
Meskipun semua orang tahu apa fungsi tombol Refresh, tidak ada yang benar-benar memahami bahwa aplikasi web yang mereka minta untuk kami buat biasanya memiliki keterbatasannya sendiri. Dan jika tidak diperlukan lagi, pengalaman pengguna akan sangat berbeda. Mereka sebagian besar menyadari bahwa mereka dapat “mengobrol” dengan meninggalkan catatan untuk orang yang mereka ajak bicara, jadi mereka bertanya-tanya apa bedanya dengan, misalnya, Slack. Fiuh!
Desain sinkronisasi sehari-hari
Jika Anda mempunyai pengalaman dalam pengembangan perangkat lunak, pasti menegangkan mengingat bahwa kebanyakan orang tidak bisa hanya melihat gambar antarmuka dan memahami apa yang akan dilakukannya ketika berinteraksi dengannya. Belum lagi apa yang terjadi di dalam program itu sendiri. Pengetahuan itu bisa terjadi sebagian besar merupakan hasil dari mengetahui apa yang tidak bisa terjadi dan apa yang tidak boleh terjadi. Ini membutuhkan tidak hanya apa yang dilakukan perangkat lunak, tetapi juga bagaimana bagian-bagiannya dikoordinasikan dan berkomunikasi satu sama lain.
Contoh klasiknya adalah pengguna menatap a pemintal.gif, bertanya-tanya kapan pekerjaan itu akhirnya akan selesai. Pengembang akan menyadari bahwa prosesnya mungkin terhenti dan gif tidak akan pernah hilang dari layar. Animasi ini menyimulasikan eksekusi suatu tugas, namun tidak terkait dengan statusnya. Dalam kasus seperti ini, beberapa teknisi suka memutar mata karena takjub melihat betapa besarnya kebingungan pengguna. Namun, perhatikan berapa banyak dari mereka yang menunjuk ke jam yang berputar dan mengatakan bahwa jam itu sebenarnya tidak bergerak?
Inilah inti dari nilai real-time. Saat ini, database real-time masih sangat sedikit digunakan dan banyak orang memandangnya dengan curiga. Sebagian besar database ini sangat condong ke gaya NoSQL, itulah sebabnya mereka biasanya menggunakan solusi berbasis Mongo, yang sebaiknya dilupakan. Namun, bagi saya ini berarti merasa nyaman bekerja dengan CouchDB, serta belajar merancang struktur yang tidak hanya dapat diisi oleh beberapa birokrat dengan data. Saya pikir saya menggunakan waktu saya dengan lebih baik.
Tapi topik sebenarnya dari postingan ini adalah apa yang saya gunakan hari ini. Bukan karena pilihan, tapi karena kebijakan perusahaan yang diterapkan secara acuh tak acuh dan membabi buta. Jadi saya akan memberikan perbandingan yang Sepenuhnya Adil dan Tidak Memihak dari dua produk database real-time Google yang terkait erat.
Keduanya memiliki kata Api di namanya. Satu hal yang sangat saya ingat. Hal kedua bagi saya adalah jenis api yang berbeda. Saya tidak terburu-buru menyebutkan nama mereka, karena begitu saya menyebutkannya, kita akan menemui masalah besar pertama: nama.
Yang pertama disebut Basis Data Waktu Nyata Firebase, dan kedua - Firebase Cloud Firestore. Keduanya merupakan produk dari Paket Firebase Google. API mereka dipanggil masing-masing firebase.database(…) и firebase.firestore(…).
Hal ini terjadi karena Basis Data Waktu Nyata - itu hanya yang asli Firebase sebelum dibeli oleh Google pada tahun 2014. Kemudian Google memutuskan untuk menciptakannya sebagai produk paralel sebuah salinan Firebase berdasarkan pada perusahaan data besar, dan menyebutnya Firestore dengan cloud. Saya harap Anda belum bingung. Jika Anda masih bingung, jangan khawatir, saya sendiri yang menulis ulang bagian artikel ini sebanyak sepuluh kali.
Karena Anda perlu menunjukkan Firebase dalam pertanyaan Firebase, dan toko api dalam pertanyaan tentang Firebase, setidaknya untuk membuat Anda memahami beberapa tahun yang lalu tentang Stack Overflow.
Jika ada penghargaan untuk pengalaman penamaan perangkat lunak terburuk, ini pasti akan menjadi salah satu pesaingnya. Jarak Hamming antara nama-nama ini sangat kecil sehingga membingungkan bahkan para insinyur berpengalaman yang jari-jarinya mengetik satu nama sementara kepala mereka memikirkan nama lain. Ini adalah rencana yang bermaksud baik namun gagal total; mereka memenuhi ramalan bahwa database akan terbakar. Dan aku tidak bercanda sama sekali. Orang yang membuat skema penamaan ini menimbulkan darah, keringat, dan air mata.
Kemenangan pahit
Orang akan berpikir bahwa Firestore adalah penggantian Firebase, turunan generasi berikutnya, tapi itu menyesatkan. Firestore tidak dijamin menjadi pengganti Firebase yang cocok. Sepertinya seseorang menghilangkan segala sesuatu yang menarik darinya, dan mengacaukan sebagian besar sisanya dengan berbagai cara.
Namun, melihat sekilas kedua produk tersebut mungkin membingungkan Anda: keduanya tampaknya melakukan hal yang sama, pada dasarnya melalui API yang sama, dan bahkan dalam sesi database yang sama. Perbedaannya tidak kentara dan hanya terungkap melalui studi perbandingan yang cermat terhadap dokumentasi yang ekstensif. Atau saat Anda mencoba mem-porting kode yang berfungsi sempurna di Firebase agar berfungsi dengan Firestore. Bahkan kemudian Anda mengetahui bahwa antarmuka basis data menyala segera setelah Anda mencoba menarik dan melepas dengan mouse secara real time. Saya ulangi, saya tidak bercanda.
Klien Firebase bersifat sopan dalam arti bahwa klien ini melakukan buffer terhadap perubahan dan secara otomatis mencoba ulang pembaruan yang memberikan prioritas pada operasi penulisan terakhir. Namun, Firestore memiliki batas 1 operasi tulis per dokumen per pengguna per detik, dan batas ini diberlakukan oleh server. Saat bekerja dengannya, terserah Anda untuk menemukan cara mengatasinya dan menerapkan pembatas kecepatan pembaruan, bahkan ketika Anda hanya mencoba membangun aplikasi Anda. Artinya, Firestore adalah database real-time tanpa klien real-time, yang menyamar sebagai klien yang menggunakan API.
Di sini kita mulai melihat tanda-tanda pertama alasan utama Firestore. Saya mungkin salah, namun saya menduga seseorang yang berkedudukan tinggi di manajemen Google melihat ke Firebase setelah pembelian dan hanya berkata, “Tidak, ya Tuhan, tidak. Ini tidak bisa diterima. Hanya saja tidak di bawah kepemimpinan saya."
Dia muncul dari kamarnya dan menyatakan:
“Satu dokumen JSON yang besar? TIDAK. Anda akan membagi data menjadi dokumen terpisah, yang masing-masing berukuran tidak lebih dari 1 megabyte.”
Tampaknya batasan seperti itu tidak akan bertahan saat pertama kali bertemu dengan basis pengguna yang cukup termotivasi. Anda tahu itu benar. Di tempat kerja, misalnya, kami mempunyai lebih dari satu setengah ribu presentasi, dan ini adalah hal yang Sepenuhnya Normal.
Dengan batasan ini, Anda akan dipaksa untuk menerima kenyataan bahwa satu "dokumen" dalam database tidak akan menyerupai objek apa pun yang mungkin disebut pengguna sebagai dokumen.
"Array dari array yang dapat memuat elemen lain secara rekursif? TIDAK. Array hanya akan berisi objek atau angka dengan panjang tetap, seperti yang Tuhan kehendaki."
Jadi jika Anda berharap untuk memasukkan GeoJSON ke dalam Firestore Anda, Anda akan menyadari bahwa hal ini tidak mungkin. Tidak ada sesuatu pun yang bersifat non-satu dimensi dapat diterima. Saya harap Anda menyukai Base64 dan/atau JSON dalam JSON.
“Impor dan ekspor JSON melalui HTTP, alat baris perintah, atau panel admin? TIDAK. Anda hanya dapat mengekspor dan mengimpor data ke Google Cloud Storage. Itulah sebutannya sekarang, menurutku. Dan ketika saya mengatakan “Anda,” saya hanya berbicara kepada mereka yang memiliki kredensial Pemilik Proyek. Semua orang bisa pergi dan membuat tiket."
Seperti yang Anda lihat, model data FireBase mudah untuk dijelaskan. Ini berisi satu dokumen JSON besar yang mengaitkan kunci JSON dengan jalur URL. Jika Anda menulis dengan HTTP PUT в / FireBase adalah sebagai berikut:
{
"hello": "world"
}
itu GET /hello akan kembali "world". Pada dasarnya ini berfungsi persis seperti yang Anda harapkan. Koleksi objek FireBase /my-collection/:id setara dengan kamus JSON {"my-collection": {...}} di root, yang isinya tersedia di /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Ini berfungsi dengan baik jika setiap sisipan memiliki ID bebas tabrakan, yang solusi standarnya dimiliki oleh sistem.
Dengan kata lain, database 100% kompatibel dengan JSON(*) dan berfungsi baik dengan HTTP, seperti CouchDB. Namun pada dasarnya Anda menggunakannya melalui API real-time yang mengabstraksi soket web, otorisasi, dan langganan. Panel admin memiliki kedua kemampuan tersebut, memungkinkan pengeditan real-time dan impor/ekspor JSON. Jika Anda melakukan hal yang sama pada kode Anda, Anda akan terkejut melihat betapa banyak kode khusus yang akan terbuang ketika Anda menyadari bahwa patch dan diff JSON menyelesaikan 90% tugas rutin penanganan status persisten.
Model data Firestore mirip dengan JSON, tetapi berbeda dalam beberapa hal penting. Saya telah menyebutkan kurangnya array di dalam array. Model untuk subkoleksi adalah konsep kelas satu, terpisah dari dokumen JSON yang memuatnya. Karena tidak ada serialisasi siap pakai untuk ini, jalur kode khusus diperlukan untuk mengambil dan menulis data. Untuk memproses koleksi Anda sendiri, Anda perlu menulis skrip dan alat Anda sendiri. Panel admin hanya memungkinkan Anda membuat perubahan kecil pada satu bidang dalam satu waktu, dan tidak memiliki kemampuan impor/ekspor.
Mereka mengambil database NoSQL real-time dan mengubahnya menjadi non-SQL yang lambat dengan penggabungan otomatis dan kolom non-JSON terpisah. Sesuatu seperti GraftQL.
Jawa panas
Jika Firestore seharusnya lebih andal dan terukur, ironisnya adalah rata-rata pengembang akan mendapatkan solusi yang kurang andal dibandingkan memilih FireBase. Jenis perangkat lunak yang dibutuhkan oleh Grumpy Database Administrator memerlukan tingkat upaya dan kualitas bakat yang tidak realistis untuk ceruk pasar yang seharusnya dikuasai oleh produk tersebut. Hal ini mirip dengan HTML5 Canvas yang bukan pengganti Flash sama sekali jika tidak ada alat pengembangan dan pemutar. Selain itu, Firestore terperosok dalam keinginan akan kemurnian data dan validasi steril yang tidak sejalan dengan cara rata-rata pengguna bisnis suka bekerja: baginya semuanya opsional, karena sampai akhir semuanya hanya draft.
Kerugian utama FireBase adalah klien dibuat beberapa tahun lebih awal, sebelum sebagian besar pengembang web mengetahui tentang kekekalan. Oleh karena itu, FireBase berasumsi bahwa Anda akan mengubah data dan oleh karena itu tidak memanfaatkan kekekalan yang disediakan pengguna. Selain itu, ia tidak menggunakan kembali data dalam snapshot yang diteruskan ke pengguna, sehingga membuat diff menjadi jauh lebih sulit. Untuk dokumen berukuran besar, mekanisme transaksi berbasis diff yang dapat diubah tidak memadai. Teman-teman, kita sudah punya WeakMap dalam JavaScript. Itu nyaman.
Jika Anda memberikan data bentuk yang diinginkan dan tidak membuat pohon terlalu banyak, maka masalah ini dapat diatasi. Namun saya penasaran apakah FireBase akan jauh lebih menarik jika pengembangnya merilis API klien yang sangat bagus yang menggunakan kekekalan dikombinasikan dengan beberapa saran praktis yang serius tentang desain basis data. Sebaliknya, mereka sepertinya mencoba memperbaiki apa yang tidak rusak, dan hal itu malah memperburuk keadaan.
Saya tidak tahu semua logika di balik pembuatan Firestore. Berspekulasi tentang motif yang muncul di dalam kotak hitam juga menjadi bagian yang menyenangkan. Penjajaran dua database yang sangat mirip namun tak dapat dibandingkan ini cukup jarang terjadi. Ini seperti seseorang berpikir: "Firebase hanyalah sebuah fungsi yang dapat kami tiru di Google Cloud", namun belum menemukan konsep untuk mengidentifikasi persyaratan dunia nyata atau menciptakan solusi berguna yang memenuhi semua persyaratan tersebut. “Biarkan pengembang memikirkannya. Percantik saja UI-nya... Bisakah Anda menambahkan lebih banyak api?”
Saya memahami beberapa hal tentang struktur data. Saya jelas melihat konsep "semuanya dalam satu pohon JSON besar" sebagai upaya untuk mengabstraksi segala struktur skala besar dari database. Mengharapkan perangkat lunak untuk mengatasi fraktal struktur data yang meragukan adalah hal yang gila. Saya bahkan tidak perlu membayangkan betapa buruknya hal ini, saya telah melakukan audit kode yang ketat dan Saya melihat hal-hal yang tidak pernah Anda impikan. Tapi saya juga tahu struktur yang bagus seperti apa, и . Saya dapat membayangkan sebuah dunia di mana Firestore tampak logis dan orang-orang yang menciptakannya akan berpikir bahwa mereka telah melakukan pekerjaannya dengan baik. Tapi kita tidak hidup di dunia ini.
Dukungan kueri FireBase buruk menurut standar apa pun dan praktis tidak ada. Pastinya perlu perbaikan atau setidaknya revisi. Namun Firestore tidak jauh lebih baik karena terbatas pada indeks satu dimensi yang sama dengan yang ditemukan di SQL biasa. Jika Anda memerlukan kueri yang dijalankan orang-orang pada data yang kacau, Anda memerlukan penelusuran teks lengkap, filter multi-rentang, dan pengurutan khusus yang ditentukan pengguna. Setelah diperiksa lebih dekat, fungsi SQL biasa terlalu terbatas. Selain itu, satu-satunya kueri SQL yang dapat dijalankan orang dalam produksi adalah kueri cepat. Anda memerlukan solusi pengindeksan khusus dengan struktur data cerdas. Untuk hal lainnya, setidaknya harus ada pengurangan peta bertahap atau yang serupa.
Jika Anda menelusuri Google Dokumen untuk mendapatkan informasi tentang hal ini, semoga Anda diarahkan ke sesuatu seperti BigTable dan BigQuery. Namun, semua solusi ini disertai dengan begitu banyak jargon penjualan korporat yang padat sehingga Anda akan segera kembali dan mulai mencari solusi lain.
Hal terakhir yang Anda inginkan dengan database real-time adalah sesuatu yang dibuat oleh dan untuk orang-orang dalam skala gaji manajemen.
(*) Ini bercanda, tidak ada yang namanya .
Tentang Hak Periklanan
Mencari untuk proyek debugging, server untuk pengembangan dan hosting? Anda pasti klien kami 🙂 Harga harian untuk server dengan berbagai konfigurasi, anti-DDoS, dan lisensi Windows sudah termasuk dalam harga.
Sumber: www.habr.com