Firebase kullanılıyorsa iş mantığı nereye yerleştirilir?


10

Çok kullanıcılı bir dokümantasyon sistemi basitleştirilmiş tek bir web uygulaması geliştirmeye başlamak üzereyim. Ön uç muhtemelen Angular2'yi kullanacaktır.

Projenin kısa bir son tarihi var, bu yüzden "kısayolları" arıyordum, yani her şeyi sıfırdan uygulamak yerine çeşitli hazır hizmetler kullanıyorum.

Uygulama verilerini saklamak için bir çeşit arka uca ihtiyacım olacak. Etrafa baktım ve ön uçla iletişim kurmak için ayrı bir arka uç ve API oluşturma çalışmalarından bazılarını götüren Firebase'i buldum.

Ama bu aynı zamanda iş mantığını Angular2 web uygulamasında ön uca koymak zorunda olduğum anlamına geliyor, değil mi?

Gelecekte bir gün bir mobil uygulama ön ucu yapmak istersem, iş mantığı kodunu çoğaltmam gerekir mi?

Alternatif, iş mantığını içeren ve veri depolama için Firebase'i kullanan bir arka uç oluşturmak olurdu, ancak bu biraz garip görünüyor (aynı sonucu elde etmek için sadece bir ORM veya doğrudan arka ucumda bir şey kullanamadım çok daha fazla iş?)

Örneğin Firebase'den yararlanmak isteyenler, genellikle bu tür uygulamaları nasıl yapılandırırlar?


En çok hangi veritabanı / orm, vb. Hakkında bilginiz var? Muhtemelen sizi en hızlı oraya götürecek şey budur.
Robert Harvey

Bu proje için muhtemelen daha önce kullanmadığım bazı teknolojileri kullanıyordum, bu yüzden her iki şekilde de bir şeyler
Magnus W

Sadece veri depolamaya mı ihtiyacınız var yoksa anlık push özelliğini de kullanmaya mı çalışıyorsunuz? Bunu iş mantığı olarak görmüyorsanız, her ön uç teknolojisi bunu doğrudan kendi bağlantı koduyla işleyebilir. Bir ORM'nin bunu yapacağından emin değilim.
JeffO

Yanıtlar:


2

S: Ama bu aynı zamanda, iş mantığını Angular2 web uygulamasında ön uca koymak zorunda olduğum anlamına geliyor, değil mi?

Evet. Bir sunucu tarafından desteklenmiyorsa, işletme bir yere uygulanmalıdır.

Google'ın satın alınmasından sonra Firebase, kendi arka uçlarını dağıtmayı göze alamayan (veya gerekmeyen) mobil uygulama geliştiricileri için bir platform haline geldi. Hizmetlerin çoğu oldukça çapraz olsa da, depolama, giriş, analitik ve mesaj hizmeti, bazı işlere özgü kuralları gerçekleştirmek için kullanılabilen Bulut İşlevleri (bir çeşit lambda) da sağladığı doğrudur . Ancak, kurumsal uygulamalar veya karmaşık bir etki alanı ve iş mantığına sahip büyük uygulamalar için bu tür destekler yetersiz kalır.

Tahmin edebileceğiniz gibi, Firebase bizi, işe özgü operasyonları barındırmaya ve yürütmeye yönelik arka uca sahip olmaktan muaf tutmuyor.

S: Peki gelecekte bir gün bir mobil uygulama ön ucu yapmak istersem, iş mantığı kodunu çoğaltmam gerekir mi?

Şart değil. Web uygulaması Açısal olarak oluşturulmuşsa, NativeScript gibi çapraz platformlar web bileşenlerini, kütüphaneleri, yardımcı programları, modelleri vb. Yeniden kullanmanıza izin verebilir. Konuya girmedim , böylece tam uyumluluğu sağlayamıyorum. Anahtar TypeScript üzerinde yer alır , hem Angular hem de NativeScript TS üzerinde kod yazmamızı gerektirir.

Mesele , Javascript'in dağıtımı ve versiyonlaması için nerede barındırılacağıdır . Bir kelime CDN .

S: Alternatif, iş mantığını içeren ve veri depolaması için Firebase'i kullanan bir arka uç oluşturmak olurdu, ancak bu biraz garip görünüyor (aynısını elde etmek için sadece bir ORM veya doğrudan arka ucumda bir şey kullanamadım daha fazla iş yapmadan sonuç?)

Bazı düşünceler.

Bir yandan, bir veritabanını barındırma, dağıtma, yönetme ve bakımını yapma küçük bir şey değildir. Güvenlik, ölçeklenebilirlik, kullanılabilirlik vb. İşlemlerden bahsetmiyorum. Bu günlerde veritabanımızın bulutta bir yere sahip olması çılgınca bir fikir değil. Tabii ki, bir banka için ara katman yazılımı ve arka uçlar uygulasaydık bunu önermem. Ancak müşterinin oturumu, kullanıcı profilleri, tercihleri ​​ve genellikle müşteri tarafında yaşayan bu tür veriler veya umursamadığımız veriler için anlamlı olabilir.

Öte yandan, arka ucumuza sahip olmak basit bir nedenden dolayı yararlıdır, ayırma .

Müşterilerimizi, yönetmediğimiz ve kontrol etmediğimiz her türlü hizmetle eşleştirmek yerine, bunlara baktığımız sunucu tarafı bir uygulama dağıtırız, böylece müşterilerimiz hizmetlerin kapanması veya kırılması gibi konular hakkında endişelenmek zorunda kalmazlar değiştirir. Ek olarak, basitlik kazanıyoruz çünkü arka ucumuz bir cephe gibi davranıyor.

S: Örneğin Firebase'den yararlanmak isteyen insanlar genellikle bu tür uygulamaları nasıl yapılandırırlar?

Projeden projeye büyük farklılıklar gösterir. Örneğin, Firebase + arka ucu kullanıyoruz.

  • Firebase DB arasındaki payı verilerine cihazlar hesaplar-oturumları . Ayrıca bir değişiklik günlüğü olarak, arka ucumuz geçici olarak kullanılamadığında istemciler yazma işlemlerini günlüğe gönderir ve bu işlem daha sonra senkronize edilir.

  • Firebase Cloud Mesajları bize yukarı / aşağı push bildirimleri ve konuları sağlar. Hizmeti pub / sub message exchange için kullanıyoruz.

  • Firebase analizi Çoğunlukla metrikler için.

  • Kesinlikle iş ile ilgili her şey için arka uç


1

Kısa cevap: İş mantığını kullanma.

Uzun cevap: Ayrı bir iş mantığına sahip olmayacak kadar küçük görünen bir uygulamayı tanımlarsınız; ilk etapta gerçekten böyle bir iş mantığınız olup olmadığını değerlendirin; çok sayıda iş mantığı veri tasarımı ve biraz da sunum katmanı ile azaltılabilir. Birçok küçük sistem çoğunlukla CRUD'dur ve gerçek bir iş mantığı yoktur; Çoğu zaman, asla gelmeyecek bir gelecek için alan bırakan, sadece düz geçişli nesneler olan iki veya üç kat sınıf gördüm.

Firebase'den hemen bir API ile başlayabilir ve daha sonra, sözleşmenizi hizmet için istikrarlı bir imza tutmaya yetecek kadar iyi tasarladığınız sürece, gerçek bir ihtiyaç olduğunu bulduğunuzda iş mantığı için ek bir katman sunabilirsiniz. arkasındaki uygulama değişebilir.


Bunu kabul ettiğim gibi söyleyemem. Bu sektörde 20 yıldır çalışıyorum ve küçük CRUD uygulamalarındaki payım üzerinde çalıştım, ancak neredeyse her zaman bir iş mantığı var. Sadece özel doğrulama veya vergi hesaplamaları olsa bile, her zaman bir şey vardır.
Jules

Yorumuna katılıyorum. Sıfır iş mantığı olduğunu söylemiyorum; Söylediğim, ayrı bir katmanı hak edecek kadar büyük olmaması. Bu doğrulamaların veya hesaplamaların veri veya sunum katmanına değil, özellikle bir iş katmanına ait olup olmadığını (özellikle özel doğrulamaların veri mantığı tanımımla eşleşme eğiliminde olduğunu) iddia ediyorum, ancak nokta, sınıflandırılması gereken yerde saf olmak değil, nereye kodlanacağı konusunda pragmatik.
Bruno Guardia

0

bkz. /programming/54994228/how-to-minimise-firebase-function-latency

Cloud Firestore, ön uç ve arka uç arasındaki birincil ve tek bağlantıdır. Tabii ki bazı mantık ön uçta olabilir, ancak güvenlik için genellikle kullanıcının çevrimdışı faydası olabilir. Cloud Firestore koleksiyonlarına, rollere veya ihtiyacınız olan her şeye güvenerek güvenliği uygulamalısınız.

Ardından, bir Cloud Firestore tetikleyicisinden çağrılan Cloud İşlevlerini kullanın.

Bir ön uç uygulamasından asla Bulut İşlevi çağırmamalısınız.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.