Firebase Realtime Database Development İçin En İyi Uygulamalar
News Rush, 4 aydır Firebase'i kullanıyor ve daha iyi görmek istediğimiz şeyler olsa da (“mükemmel bir ürün adı verebilir misiniz?”), Mobil veri senkronizasyonu gereksinimlerimiz için desteğimize değerli bir katkı oldu.
Yol boyunca, platformun ihtiyaçlarımızı karşılamak için en iyi nasıl kullanılacağı hakkında bazı dersler aldık. Firebase, belge odaklı / NoSQL veritabanıdır ve bu nedenle bu platformların özelliklerinin çoğunu paylaşır, ancak öğrenmesi gereken kendine özgü bazı özellikleri vardır. İşte yol boyunca keşfettiğimiz şeylerin hızlıca bir beyin dökümü.
KKO!
SDK belgeleri genellikle korkunç, bu yüzden çoğumuz yüksek puanlar için eksik ve daha sonra (ya da asla) geri dönmek eğilimindedir.
Burada tam tersi geçerlidir. Kılavuzlar ve Örnekler takip etmek kolaydır ve Referans dokümanlar hem ayrıntılı hem de aldatıcı bir şekilde kısadır. Neredeyse ekibimizin bir sorusu veya sorunu olduğunda, çözümü dokümanlarda kaçırdığımız bir şey bulduk. Sonunda oturduk ve her kelimeyi doğrudan okuduk ve 3 saat harcadık.
Gerçek dünyadaki sorunlara çözüm bulmak için hazine olan bir blog da var. News Rush’ta en kritik bulduğumuz yayınlardan birkaçı:
- Firebase Veritabanında Grup Güvenliği
- Sorgular, Bölüm 1: Firebase İçin Dönüştürülen Genel SQL Sorguları
- En İyi Uygulamalar: Firebase'deki Diziler
Sonuç: “Şema-az”, beyin-az anlamına gelmez!
Belge yönelimli veritabanlarının verilerin nasıl daha az önemli şekilde yapılandırılacağı konusunda önceden plan yapması yaygın bir yanılgıdır. Bu bir efsanedir. Herhangi bir şey olursa, bunun tersini bulduk: daha fazlasına ihtiyaçları var.
İyi bir planlamanın herhangi bir yazılım bileşeninden en yüksek performansı elde etmesine yardımcı olabileceğini söylemek olağandışı bir şey değildir. Ancak SQL veritabanlarında, planlama hatalarını yalnızca daha fazla tabloya katılarak, alt sorgular yaparak veya toplu veri güncellemeleri yaparak düzeltmek genellikle kolaydır. Firebase bu kavramlara sahip olmadığından, oturmak için zaman ayırın ve verilerinizi ve erişim kalıplarınızı vaktinden önce modelleyin. Yaptığına sevineceksin.
Ve RTFM!
Destek kafa karıştırıcı
Çok sayıda destek seçeneği var, ancak belirli bir durumda yanlış olanı kullanmaya çalışmak sinir bozucu olabilir. Deneyimlerimiz olmuştur:
- Slack: Topluma yönelik kendi kendine yardım ve beyin fırtınası diğer yerler için uygun değil. “Bir şeyler düştü” için uygun değildir.
- Destek Formu: “Resmi” destek yeri. Burada “bir şey düştüğünü” bildiriniz. Bir konserve alabilecek özellik talepleri “dikkate alacağız, ancak söz vermeyeceğiz” yanıtı verdi.
- Google Grupları: Çekirdek ekibin, grup odaklı posta sistemlerinde geri dönüş süresi hakkında olağan uyarılarla aktif katılımı. Uygulama içi ve “garip” konular hakkında oldukça teknik tartışmalar için en iyi yer.
- StackOverflow: Yavaş / öngörülemeyen tepki süreleri ancak yedek referans malzemesi için en iyi yer. StackOverflow'ta bir soru ve cevap okuduysanız, oraya da göndermenin en iyi yoludur.
Referanslar ve basit alımlar “ucuz”
Firebase'de bir “ref” verilere bir işaretçi gibidir. Onları önbelleğe almak veya başka şekilde yönetmek istemek içgüdüseldir, ancak mevcut Firebase istemci kütüphanelerinde bunu asla yapmamalısınız. Gerçekten de, yalnızca URL nesnelerine veri nesnelerine yapılan referansları sarıyorlar ve erişim sağladıkları geri aramalar bir seferde yalnızca bir dinleyiciye sahip olabilir. Bir nesneye iki farklı yerden başvuru yapmanız gerekirse, iki referansa bakın. Bunu yapmak daha pahalıya mal olmaz.
Veri alımları için de benzer bir kural geçerlidir. SQL veritabanlarından gelenler, gidiş geliş süresini ortadan kaldırmak ve ek yükü sorgulamak için mümkün olan en az sayıda sorguda daha büyük nesneleri almaya çalışmaktadırlar. Veri yapılarını düzleştirirken, tek bir erişimin gereken her şeyi almasını sağlamak için “özet” verilerini birden fazla konuma kopyalamak caziptir.
Firebase'de bu neredeyse tamamen yanlış bir karardır. Birincisi, basit anahtar / ref tabanlı alımlar yoğun şekilde optimize edilmiştir ve Firebase, onlar için büyük yatay ölçekler sunmaktadır. News Rush'taki performans testimizde, Firebase'in daha küçük nesnelerle daha iyisini yaptığını gördük. Gereksiz birkaç alanı kaldırmak bile ölçülebilir bir performans artışı sağlayabilir.
Redis'in karma ve set gibi yapılar için optimize edilmiş modellerinde olduğu gibi, Firebase’in devasa yatay ölçeklenebilirliği de temel özelliklerinden biridir. Sadece olması güzel bir şey olmamalı. Uygulama tasarımlarınızda bir araç olarak kendisini güçlendirmek gerekir.
Dizileri önlemek
Firebase belgeleri zaten bu konuyu kapsamaktadır. Hepsi doğru. Onlardan kaçının.
Tarih yok
Firebase tarih nesne türüne sahip değildir ve azalan türlere izin vermez. Yerel nesneleri Date alanları ile alan ve bunları bir milisaniye-başından beri milisaniye değerlerine dönüştüren ve ayrıca bu değerlerin karşılık gelen negatif sayı türevlerini ekleyen bir yardımcı “güncelleme” işlevi yazdık. Negatif sayıdaki bir zaman değerine göre artan sıralama, istenen inme sırasını sağlar.
Tek beden herkese olmaz
Firebase’in güçlü yanlarından yararlanın. Sahip olduğun her işi yapmayı denemeyin. İşte Firebase değil bazı şeyler:
- Bir arama motoru. Önek eşleme gibi birkaç temel işlemi var, ancak bu kadar. Tam güçlü bir aramaya ihtiyaç duyarsanız ELK, Algolia vb. Kullanın.
- Bir API yığını. Firebase için Bulut İşlevleri çok umut verici görünüyor, ancak hala Beta'da. Uygulamanız yapılacaklar listesinden başka bir şeyse, sunucu tarafında / güvenilir kod yürütülmesini nasıl yapacağınızı planlayın.
- Bir raporlama motoru. Verilerinizi kesmeniz / kesmeniz gerektiğinde ilişkisel bir veri tabanından yararlanmak isteyebilirsiniz.
- Kendi kendine barındırılan veya tamamen kullanılabilir çevrimdışı. Çevrimdışı işlevler senkronizasyon / kalıcılık ile sağlanır, ancak Firebase bulutunun ilk başta dahil olması gerekir.
Güncelle ile ayarla
SET ve UPDATE işlemleri arasında büyük bir fark var. Bir anahtar henüz mevcut değilse, özellikle karmaşık nesnelerin içindeki anahtarlar olduğunda ne olacağını etkiler. Dikkat et!
FirebaseUI harika!
Oh, bahsetmeliyim ki, birçok platform için FirebaseUI eşlik eden projeler var. Onları kullan. Firebase koleksiyonundaki nesnelerin listesini görüntülemek için bir tablo oluşturma gibi şeyler için inanılmaz derecede yardımcı oluyorlar.
Bu kitaplık, mobil bir platformda yalnızca birkaç satır kod başlatan FUICollectionViewDataSource ve FUITableViewDataSource sınıflarını (ve Android'deki eşdeğerlerini) sağlar. Bu başlangıç, Firebase'i ilk değerlendirirken çok güzeldi. Tablodaki diğer seçeneklere kıyasla çok az öğrenmenin yer aldığı birkaç saat içinde bir kavram kanıtı hazırladık.
Daha fazla gelişmişlik ve kontrol için hazır olduğunuzda, FirebaseUI hala kullanışlıdır, çünkü aynı zamanda sekme başlıkları ve diğer tuhaf ekranlar gibi şeyleri sürmenizi sağlayan alt seviye veri toplama sınıfları FUIArray ve FUIIndexArray sağlar.
Bir şey mi kaçırdım? Kendinizinkini paylaşın!