Izinkan saya menceritakan kisah teknisnya.
Bertahun-tahun yang lalu saya mengembangkan aplikasi dengan fitur kolaborasi yang dibangun di dalamnya. Itu adalah tumpukan eksperimental praktis yang memanfaatkan potensi penuh dari React dan CouchDB awal. Ini menyinkronkan data melalui JSON OT secara real time . Itu digunakan secara internal di perusahaan, tetapi penerapannya yang luas dan potensinya di bidang lain terlihat jelas.
Saat mencoba menjual teknologi ini kepada calon pelanggan, kami menemui kendala yang tidak terduga. Dalam video demo, teknologi kami terlihat dan berfungsi dengan baik, tidak masalah. Video tersebut menunjukkan dengan tepat cara kerjanya, dan tidak ada yang ditiru di dalamnya. Kami datang dengan dan membuat kode skenario realistis untuk menggunakan program tersebut.
Nyatanya, inilah yang menjadi masalahnya. Demo kami bekerja persis seperti orang lain menyimulasikan cara kerja aplikasi mereka. Lebih khusus lagi, informasi langsung ditransfer dari A ke B, meskipun itu adalah file media yang besar. Setelah masuk, setiap pengguna melihat entri baru. Dengan menggunakan aplikasi ini, pengguna yang berbeda dapat berkolaborasi pada proyek yang persis sama, meskipun koneksi Internet terputus di suatu tempat di desa. Ini secara implisit tersirat dalam video produk potongan apa pun di After Effects.
Meskipun semua orang tahu untuk apa tombol Segarkan, tidak ada yang mengerti bahwa aplikasi web yang mereka minta untuk kami buat biasanya tunduk pada batasan mereka sendiri. Dan jika mereka tidak lagi dibutuhkan, maka pengalaman pengguna akan sangat berbeda. Pada dasarnya, mereka memperhatikan bahwa Anda dapat "mengobrol" dengan meninggalkan catatan kepada lawan bicara, jadi mereka bertanya-tanya apa bedanya, misalnya, dari Slack. Uf-f-f-f!
Desain sinkronisasi sehari-hari
Jika Anda sudah memiliki pengalaman dalam pengembangan perangkat lunak, Anda akan merasa gugup untuk mengingat bahwa kebanyakan orang tidak bisa hanya melihat gambar antarmuka dan mencari tahu apa yang akan dilakukannya saat berinteraksi dengannya. Belum lagi apa yang terjadi di dalam program itu sendiri. Mengetahui apa yang bisa terjadi sebagian besar merupakan hasil dari mengetahui apa yang tidak bisa terjadi dan apa yang tidak boleh terjadi. Ini membutuhkan model mental tidak hanya tentang apa yang dilakukan perangkat lunak, tetapi juga tentang bagaimana masing-masing bagiannya dikoordinasikan dan berkomunikasi satu sama lain.
Contoh klasiknya adalah pengguna yang melihat spinner.gif selama dua puluh menitbertanya-tanya kapan pekerjaan itu akhirnya akan berakhir. Pengembang akan memahami bahwa prosesnya mungkin terhenti, dan gif tidak akan pernah hilang dari layar. Animasi ini mensimulasikan pelaksanaan pekerjaan, tetapi tidak terkait dengan statusnya. Dalam kasus seperti ini, beberapa teknisi suka memutar mata, mengagumi tingkat kebingungan pengguna. Namun, perhatikan yang mana di antara mereka yang menunjuk ke jam yang berputar dan mengatakan bahwa mereka sebenarnya tidak bergerak?
Ini adalah inti dari nilai waktu nyata. Basis data waktu nyata masih sangat sedikit digunakan saat ini, dan banyak yang mencurigainya. Sebagian besar database ini secara aktif condong ke gaya NoSQL, itulah sebabnya mereka biasanya menggunakan solusi berbasis Mongo yang lebih baik. Namun, bagi saya itu berarti kenyamanan bekerja dengan CouchDB, serta studi mendesain struktur yang tidak hanya dapat diisi oleh beberapa birokrat dengan data. Saya pikir saya menghabiskan waktu saya dengan lebih baik.
Tapi topik sebenarnya dari posting ini adalah apa yang saya gunakan hari ini. Bukan karena pilihan, tetapi karena kebijakan perusahaan yang diterapkan secara acuh tak acuh dan membabi buta. Oleh karena itu, saya akan menyajikan perbandingan yang sangat jujur dan tidak memihak dari dua produk basis data waktu nyata Google yang terkait erat.
Keduanya memiliki kata Api di nama mereka. Satu hal yang saya ingat dengan kesukaan. Yang kedua bagi saya adalah jenis api yang berbeda. Saya tidak terburu-buru menyebutkan nama mereka, karena begitu saya melakukannya, kita dihadapkan pada masalah besar pertama - nama.
Yang pertama disebut Firebase Real-Time Database dan yang kedua adalah Firebase Cloud Firestore . Keduanya adalah produk dari rangkaian Firebase Google . API mereka masing-masing diberi nama,
firebase.database(…)dan firebase.firestore(…).
Ini karena Real-Time Database hanyalah Firebase asli sebelum Google membelinya pada tahun 2014. Kemudian Google memutuskan untuk membuat salinanFirebase didasarkan pada data besar perusahaan, dan menamakannya Firestore dengan awan. Saya harap Anda belum bingung. Jika Anda bingung, jangan khawatir, saya sendiri sudah sepuluh kali menulis ulang bagian artikel ini.
Karena Firebase perlu dikutip dalam pertanyaan Firebase , dan Firestore dalam pertanyaan Firebase, setidaknya harus dipahami beberapa tahun yang lalu di Stack Overflow.
Jika ada penghargaan untuk penamaan produk software terburuk, maka kasus ini pasti akan menjadi salah satu pesaing. Jarak Hamming antara nama-nama ini begitu kecil sehingga membingungkan bahkan para insinyur berpengalaman, yang jari-jarinya mengetik satu nama, meskipun kepala memikirkan yang lain. Ini adalah rencana yang gagal total, dibuat dengan niat terbaik; mereka memenuhi ramalan bahwa database akan terbakar. Dan saya tidak bercanda. Pria yang datang dengan skema penamaan ini menyebabkan darah, keringat dan air mata.
Kemenangan yang mengerikan
Orang akan berpikir bahwa Firestore adalah pengganti Firebase, keturunan generasi berikutnya, tetapi itu akan menjadi kesalahpahaman. Firestore dijamin tidak akan menjadi pengganti Firebase. Sepertinya seseorang memotong semua yang menarik darinya, dan membingungkan sebagian besar sisanya dengan cara yang berbeda.
Namun, melihat sekilas kedua produk tersebut dapat membingungkan: keduanya tampaknya melakukan hal yang sama, sebagian besar melalui API yang sama, dan bahkan dalam sesi database yang sama. Perbedaannya halus dan hanya terungkap dengan studi komparatif menyeluruh dari dokumentasi yang ekstensif. Atau saat mencoba mem-port kode yang berfungsi sempurna ke Firebase untuk bekerja dengan Firestore. Meski begitu, Anda mengetahui bahwa antarmuka database menyala segera setelah Anda mencoba melakukan seret dan lepas waktu nyata. Sekali lagi, saya tidak bercanda.
Klien Firebase sopan dalam arti bahwa ia mendukung perubahan dan secara otomatis mencoba ulang pembaruan, dengan memprioritaskan penulisan terakhir. Namun, Firestore memiliki batas 1 operasi tulis per dokumen per pengguna per detik, dan batas ini diberlakukan oleh server. Saat mengerjakannya, Anda sendiri harus menemukan cara untuk mengatasinya dan menerapkan pembatas kecepatan refresh, bahkan saat Anda hanya mencoba membangun aplikasi. Artinya, Firestore adalah database waktu nyata tanpa klien waktu nyata, yang menyamar menggunakan API.
Dengan ini kita mulai melihat tanda-tanda pertama dari makna keberadaan Firestore. Saya mungkin salah, tetapi saya curiga bahwa seseorang yang berada di puncak kepemimpinan Google memperhatikan pembelian di Firebase dan hanya berkata, "Tidak, Tuhan, tidak. Ini tidak bisa diterima. Hanya tidak di bawah kepemimpinan saya. "
Dia keluar dari kamarnya dan menyatakan,
“Satu dokumen JSON yang besar? Tidak. Anda akan membagi data menjadi beberapa dokumen terpisah, yang masing-masing berukuran tidak lebih dari 1 megabyte. "
Sepertinya batasan seperti itu tidak akan bertahan pada pertemuan pertama dengan basis pengguna yang cukup termotivasi. Anda tahu itu. Di tempat kerja, misalnya, kami memiliki lebih dari seribu lima ratus presentasi, dan ini Normal Sempurna.
Dengan batasan ini, Anda harus memahami fakta bahwa satu "dokumen" dalam database tidak akan seperti objek apa pun yang oleh pengguna disebut sebagai dokumen.
“Array array yang secara rekursif dapat mengandung elemen lain? Tidak. Array hanya akan berisi objek atau angka dengan panjang tetap seperti yang diinginkan Tuhan. "
Jadi jika Anda berharap untuk meletakkan GeoJSON di Firestore Anda, Anda akan menemukan bahwa ini tidak mungkin. Tidak ada yang tidak seragam yang diperbolehkan. Saya harap Anda menyukai Base64 dan / atau JSON di dalam JSON.
Impor dan ekspor JSON melalui HTTP, alat baris perintah, atau panel admin? Tidak. Anda hanya akan dapat mengekspor dan mengimpor data ke Google Cloud Storage. Jadi sepertinya disebut sekarang. Dan ketika saya mengatakan "Anda", yang saya maksud hanyalah mereka yang memiliki kekuasaan 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 menghubungkan kunci JSON ke jalur URL. Jika Anda menulis yang berikut ini
HTTP PUTdi /FireBase:
{
"hello": "world"
}Ini
GET /helloakan kembali "world". Ini pada dasarnya bekerja persis seperti yang Anda harapkan. Kumpulan objek FireBase /my-collection/:idsetara 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 non-tabrakan, yang merupakan solusi standar untuk ini dalam sistem.
Dengan kata lain, database tersebut 100% JSON (*) dan berfungsi baik dengan HTTP seperti CouchDB. Namun kebanyakan Anda menggunakannya melalui API waktu nyata yang mengabstraksi websockets, otorisasi, dan langganan. Panel admin memiliki kedua kemampuan tersebut, memungkinkan pengeditan waktu nyata dan impor / ekspor JSON. Jika Anda tetap menggunakan yang sama dalam kode Anda, Anda akan terkejut betapa banyak kode kustom yang terbuang ketika Anda menyadari bahwa patch dan diff JSON menyelesaikan 90% dari tugas status persisten rutin.
Model data Firestore mirip dengan JSON, tetapi berbeda darinya dalam beberapa hal penting. Saya sudah menyebutkan kurangnya array di dalam array. Model sub-koleksi menjadi konsep kelas pertama yang terpisah dari dokumen JSON yang memuatnya. Karena tidak ada serialisasi out-of-the-box untuk ini, jalur kode khusus diperlukan untuk mendapatkan dan menulis data. Untuk memproses koleksi Anda sendiri, Anda perlu menulis skrip dan alat Anda sendiri. Panel admin hanya memungkinkan Anda membuat perubahan kecil satu bidang dalam satu waktu, dan tidak memiliki kemampuan impor / ekspor.
Mereka mengambil database NoSQL waktu-nyata dan mengubahnya menjadi non-SQL yang lambat dengan gabungan otomatis dan kolom non-JSON yang terpisah. Sesuatu dalam semangat GraftQL .
Java panas
Jika Firestore ingin menjadi lebih andal dan skalabel, ironi adalah bahwa rata-rata pengembang akan mendapatkan solusi yang kurang andal daripada memilih FireBase di luar kotak. Perangkat lunak yang dibutuhkan oleh Administrator Database pemarah membutuhkan tingkat upaya dan kaliber spesialis sedemikian rupa sehingga tidak realistis untuk ceruk di mana produk seharusnya bagus. Ini mirip dengan bagaimana HTML5 Canvas sama sekali bukan pengganti Flash jika tidak ada alat pengembangan dan pemutar. Selain itu, Firestore adalah macet dalam pencarian untuk kebersihan data dan validasi steril, yang hanya tidak sejalan dengan cara pengguna bisnis rata-rata suka bekerja : baginya segala sesuatu adalah opsional, karena semuanya draft sampai akhir.
Kerugian utama FireBase adalah bahwa klien dibuat beberapa tahun sebelumnya, bahkan sebelum sebagian besar pengembang web mengetahui tentang kekekalan. Karena itu, FireBase berasumsi bahwa Anda akan memodifikasi data, dan karenanya tidak memanfaatkan kekekalan yang disediakan pengguna. Selain itu, ini tidak menggunakan kembali data dalam snapshot yang dikirim ke pengguna, yang membuat diff jauh lebih sulit. Untuk dokumen besar, mekanisme transaksi berbasis diff yang dapat berubah-ubah tidak memadai. Teman-teman, kami sudah memiliki
WeakMapJavaScript. Nyaman.
Dengan membentuk data sesuai kebutuhan dan tidak membuat pepohonan terlalu besar, masalah ini dapat dielakkan. Tapi saya ingin tahu apakah FireBase akan jauh lebih menarik jika pengembang merilis API klien yang sangat bagus yang memanfaatkan kekekalan yang dikombinasikan dengan beberapa saran praktis yang solid tentang desain database. Sebaliknya, mereka tampaknya telah mencoba memperbaiki apa yang tidak rusak, dan itu memperburuk keadaan.
Saya tidak tahu semua logika di balik pembuatan Firestore. Penalaran tentang motif yang muncul di dalam kotak hitam juga merupakan bagian yang menyenangkan. Penjajaran dari dua database yang sangat mirip tetapi tidak ada bandingannya ini sangat jarang. Seolah-olah ada yang berpikir, "Firebase hanyalah fungsi yang dapat kami tiru di Google Cloud".tetapi belum menemukan konsep mendefinisikan persyaratan dunia nyata atau menciptakan solusi berguna yang memenuhi semua persyaratan ini. “Biar para pengembang memikirkannya. Buat saja UI-nya cantik ... Bisakah Anda menambahkan lebih banyak api? "
Saya memahami beberapa hal tentang struktur data. Saya dapat melihat dengan jelas bahwa konsep "segala sesuatu dalam satu pohon JSON besar" adalah upaya untuk mengabstraksi dari database pengertian apa pun dari struktur skala besar. Mengharapkan perangkat lunak untuk hanya menangani fraktal struktur data yang dipertanyakan adalah gila. Saya bahkan tidak perlu membayangkan betapa buruknya segalanya, saya melakukan audit kode yang ketat dan melihat hal-hal yang tidak pernah Anda impikan sebagai manusia . Tapi saya juga tahu seperti apa struktur yang bagus, bagaimana cara menggunakannya danmengapa itu harus dilakukan . Saya dapat membayangkan sebuah dunia di mana Firestore tampak cukup logis dan orang-orang yang membuatnya berpikir bahwa mereka melakukan pekerjaan dengan baik. Tapi kita tidak hidup di dunia ini.
Dukungan untuk membangun kueri di FireBase buruk menurut standar apa pun, secara praktis tidak ada. Ini pasti perlu perbaikan atau setidaknya revisi. Tetapi Firestore tidak jauh lebih baik, karena terbatas pada indeks satu dimensi yang sama yang ditemukan di SQL biasa. Jika Anda menginginkan kueri yang dilakukan orang-orang pada data yang kacau, Anda memerlukan penelusuran teks lengkap, filter pada beberapa rentang, dan urutan yang ditentukan pengguna secara sewenang-wenang. Pada pemeriksaan lebih dekat, fungsi SQL biasa terlalu dibatasi dengan sendirinya. Selain itu, satu-satunya kueri SQL yang dapat dijalankan manusia dalam produksi adalah kueri cepat. Anda akan memerlukan solusi pengindeksan khusus dengan struktur data yang canggih. Untuk yang lainnya, setidaknya harus ada pengurangan peta tambahan atau yang serupa.
Jika Anda melihat di dokumen Google tentang hal ini, semoga Anda akan diarahkan ke sesuatu seperti BigTable dan BigQuery. Namun, semua keputusan ini disertai dengan volume jargon penjualan perusahaan yang begitu tebal sehingga Anda akan segera kembali dan mulai mencari sesuatu yang lain.
Hal terakhir yang Anda butuhkan dalam kasus database real-time adalah sesuatu yang dibuat oleh manusia dan orang yang bekerja dengan skala gaji untuk kepemimpinan.
(*) Ini lelucon, tidak ada yang namanya kompatibilitas 100% JSON .
Periklanan
Apakah Anda mencari VDS untuk proyek debugging, server untuk pengembangan dan penyebaran? Anda pasti klien kami :) Penagihan harian server dengan berbagai konfigurasi, lisensi anti-DDoS dan Windows sudah termasuk dalam harga.
