IceBase, Firebase'in API'sini koruyor ve backend'i değiştirilebilir bir config değerine dönüştürüyor

Bir geliştirici, Firebase'in API'sini koruyarak backend seçimini bir yapılandırma ayarına dönüştüren, Apache-2.0 lisanslı IceBase adlı kütüphaneyi yayımladı. Panth Patel'in dev.to'daki yazısına göre, bir uygulamadaki her servis gerçek Firebase, SQLite tabanlı bağımsız bir emulator veya Postgres üzerindeki self-hosted bir sunucuyla çalışabiliyor ve aynı uygulama kodu üçünde de işliyor. Proje şu an 0.6.0 sürümünde; JSR üzerinde yayımlanmış durumda ve kaynak kodu GitHub'da.

Aynı çağrılar, tek ek dosya

Patel'i harekete geçeren şey, bir yan projenin artık yan proje olmaktan çıkması anı olmuş. Bir uygulamanın bir şirket için veya büyük ölçekte çalışması gerektiğinde, diye yazıyor, hızlı bir çıkış yolu yoktu: kod Firebase'in SDK'sına göre yazılmıştı ve veri modeli, veritabanında tesadüfen ne varsa içinde örtük biçimde duruyordu.

IceBase, Firebase'in fonksiyon adlarını ve çağrı biçimlerini koruyor; bu yüzden benimsemek çoğunlukla import'ları değiştirmek anlamına geliyor. Geliştiricilerin fark edeceği tek fark key path'ler: iç içe alanlara noktalı string'ler yerine dizilerle erişiliyor, çünkü noktalı bir string tek bir key olarak okunurdu. icebase.config.ts adlı yeni bir dosya, schema, rules, functions ve hosting yapılandırmasını tutuyor ve her servisin ortam başına modunu belirliyor — örneğin lokalde emulator, production'da firebase.

Schema asıl odak

Patel, tanımlı schemayı gerçek özellik olarak tanımlıyor. Firebase her biçimde doküman kabul ediyor; bu da başlangıcı hızlandırıyor ama incelenecek bir şey bırakmıyor. Kodun büyük kısmını artık AI yazdığı için bunun daha çok can sıkıcı hale geldiğini savunuyor; çünkü o çıktıyı denetleyen bir geliştiricinin yine de arayızlara ve incelenecek bir schemaya ihtiyacı var.

IceBase, her collection'ın, Realtime Database path'inin ve storage path'inin tam biçimini, ayrıca bir sorgunun filtrelediği her alanı istiyor. Yazma işlemleri tüm modlarda runtime'da type-check edilip doğrulanıyor; index'i tanımlanmamış bir sorgu compile time'da başarısız oluyor ve runtime'da reddediliyor. Bir CLI kontrolü, bu tür tüm sorguları listeliyor, böylece CI'da yakalanabiliyorlar.

Zaten var olan projeler için bir init komutu, bir doküman örnekleminden bir schema taslağı çıkarıyor; bir de learning mode, tanımlanmamış collection'ları ve eksik index'leri düpedüz reddetmek yerine raporluyor.

Üç backend, servis başına karışık

Firebase driver'ı, gerçek Firebase SDK'larını IceBase'ın type, schema ve index kontrolleriyle birlikte kullanıyor. Emulator modu, Patel'in kendi sunucusunu SQLite üzerinde çalıştırıyor — Firebase'in resmi emulator'ü yavaş geldiği ve production'a benzer testlere uygun bir şey istediği için böyle bir sunucu yazdığını söylüyor — ve Firebase'in kendi sözdizimiyle yazılmış security rule'larını zorunlu kılıyor; böylece aynı rule dosyaları Firebase'e değiştirilmeden deploy edilebiliyor. vm modu ise aynı sunucuyu self-hosted Postgres üzerinde çalıştırıyor.

Modlar servis başına farklılaşabiliyor; yani bir servis taşınırken diğerleri Firebase'te kalabiliyor ve tek bir migrate komutu, veriyi SQLite ve Postgres depoları arasında iki yönde de aktarıyor. IceBase ayrıca her modda çalışan kendi konsolunu da içeriyor. Conformance suite'leri Firebase'in emulator'leri, IceBase sunucusu ve canlı bir Firebase projesine karşı çalıştırılıyor ve her IceBase-sunucu suite'i Postgres'te de geçiyor. Patel'in tasarım aracı Digital Canvas, IceBase'i firebase modunda kullanıyor.

Henüz yapılmamış olanlar

Yazı eksikler konusunda açık sözlü. vm modunda saklanan dosyalar diskte kalıyor, S3 desteği henüz yok ve migrate komutu dosyaları kopyalamıyor. Docker image yok, bir VM için login-and-deploy akışı yok ve backup yok. Import, export ve link — canlı bir Firebase projesinden ayrılmayı tek komutluk bir işe dönüştürecek özellikler — yol haritasında sıradaki adımlar. Patel, hızlı ve acısız bir çıkışın bir iddia değil, hedef olduğunu açıkça belirtiyor.

Neden önemli

Firebase'te lock-in genellikle veri erişim katmanında can yakar: ayrılmak, SDK çağrılarını yeniden yazmak ve canlı dokümanlardan bir veri modeli yeniden kurmak demek. IceBase'ın bahsi şu: geliştiriciler onu daha ilk günden, Firebase hâlâ doğru seçimken benimsiyor ve bir çıkış yolunu servis başına bir ayar olarak elinde tutuyor — aynı API, Apache-2.0 lisansı ve Postgres'in gerekli olduğu gün için baştan beri repoda yaşamış olan bir schema. Migration araçları hâlâ yol haritasındayken, v0.6.0'da tamamlanmış bir kaçış kapısı değil; ama backend taşınabilirliğini yapılandırma olarak modellemek, ayrılma seçeneğini gerçekten gerekmeden önce elinde tutmak isteyen ekipler için pratik bir yaklaşım.