Di mana harus meletakkan logika bisnis jika menggunakan Firebase?


10

Saya akan mulai mengembangkan aplikasi web satu halaman yang sangat disederhanakan sistem dokumentasi multi-pengguna. Ujung depan mungkin akan menggunakan Angular2.

Proyek ini memiliki tenggat waktu yang singkat, jadi saya telah mencari "jalan pintas", yaitu menggunakan berbagai layanan yang sudah jadi alih-alih mengimplementasikan semuanya dari awal.

Saya akan membutuhkan semacam backend untuk menyimpan data aplikasi. Saya telah melihat sekeliling dan menemukan Firebase, yang tampaknya menghilangkan beberapa pekerjaan membuat backend dan API terpisah untuk berkomunikasi dengan ujung depan.

Tapi itu juga berarti saya harus meletakkan logika bisnis di ujung depan, di aplikasi web Angular2, kan?

Jadi, jika suatu hari nanti saya ingin membuat front end aplikasi seluler, saya harus menduplikasi kode logika bisnis?

Saya kira alternatifnya adalah membuat backend yang berisi logika bisnis dan menggunakan Firebase untuk penyimpanan datanya, tapi itu agak aneh (tidak bisakah saya hanya menggunakan ORM atau sesuatu langsung di backend saya untuk mencapai hasil yang sama tanpa lebih banyak pekerjaan?)

Bagaimana orang biasanya menyusun aplikasi semacam ini, jika mereka ingin menggunakan Firebase misalnya?


Basis data / orm, dll. Manakah yang paling Anda kenal? Mungkin itulah yang akan membuat Anda tercepat di sana.
Robert Harvey

Untuk proyek ini saya mungkin akan menggunakan beberapa teknologi yang belum pernah saya gunakan sebelumnya, jadi akan ada beberapa cara belajar ...
Magnus W

Apakah Anda hanya perlu penyimpanan data atau Anda mencoba memanfaatkan kemampuan push instan juga? Jika Anda tidak melihatnya sebagai logika bisnis, setiap teknologi front-end hanya dapat mengatasinya secara langsung dengan kode koneksi itu sendiri. Tidak yakin ORM akan melakukan ini.
JeffO

Jawaban:


2

T: Tapi itu juga berarti saya harus meletakkan logika bisnis di front-end, di aplikasi web Angular2, kan ?

Iya. Jika tidak didukung oleh server, bisnis harus diimplementasikan di suatu tempat.

Setelah akuisisi Google, Firebase berevolusi menjadi platform untuk pengembang aplikasi seluler yang tidak mampu (atau tidak perlu) untuk menyebarkan backend mereka sendiri. Meskipun sebagian besar layanannya cukup transversal: penyimpanan, masuk, analitik, dan layanan pesan, memang benar bahwa ia juga menyediakan Fungsi Cloud (semacam lambdas) yang dapat digunakan untuk melakukan beberapa aturan khusus bisnis. Namun, untuk aplikasi perusahaan atau aplikasi besar dengan domain yang kompleks dan logika bisnis, dukungan semacam ini tidak memadai.

Jadi, seperti yang Anda duga, Firebase tidak membebaskan kami dari backend yang didedikasikan untuk menjadi tuan rumah dan menjalankan operasi khusus bisnis.

T: Jadi jika suatu hari nanti saya ingin membuat aplikasi mobile front-end, saya harus menduplikasi kode logika bisnis?

Belum tentu. Jika aplikasi web dibangun di atas Angular, lintas platform seperti NativeScript dapat memungkinkan Anda untuk menggunakan kembali komponen web, libs, utilitas, model, dll. Saya belum menyelidiki subjek sehingga saya tidak dapat memastikan kompatibilitas penuh Anda. Kuncinya terletak pada TypeScript , baik Angular dan NativeScript mengharuskan kita untuk kode pada TS.

Masalahnya adalah di mana harus meng-host Javascript untuk distribusi dan versinya . CDN kata .

T: Saya kira alternatifnya adalah membuat backend yang berisi logika bisnis dan menggunakan Firebase untuk penyimpanan datanya, tetapi tampaknya agak aneh (tidak bisakah saya hanya menggunakan ORM atau sesuatu langsung di backend saya untuk mencapai hal yang sama hasil tanpa lebih banyak pekerjaan?)

Beberapa pertimbangan.

Di satu sisi, hosting, menggelar, mengelola dan memelihara database bukanlah hal yang kecil. Belum lagi menangani keamanan, skalabilitas, ketersediaan, dll. Jadi, memiliki penyedia DB menjaga hal-hal ini menarik. Bukan ide gila akhir-akhir ini memiliki basis data kami di suatu tempat di cloud. Tentu saja, saya tidak akan menyarankan ini jika kami menerapkan middleware dan back-end untuk bank. Tetapi masuk akal untuk sesi klien, profil pengguna, preferensi, dan data seperti ini yang biasanya hidup di sisi klien atau data yang tidak kami pedulikan.

Di sisi lain, memiliki back-end kami berguna karena alasan sederhana, decoupling .

Alih-alih menyambungkan klien kami ke semua jenis layanan yang tidak kami kelola dan kontrol, kami menggunakan aplikasi sisi-server dari tempat kami menangani hal-hal ini sehingga klien kami tidak perlu khawatir tentang masalah seperti penutupan atau pemecahan layanan perubahan. Selain itu, kami memperoleh kesederhanaan karena back-end kami bertindak seperti fasad.

T: Bagaimana orang biasanya menyusun aplikasi semacam ini, jika mereka ingin menggunakan Firebase misalnya?

Sangat bervariasi dari proyek ke proyek. Misalnya, kami menggunakan Firebase + back-end.

  • Firebase DB untuk berbagi data antara perangkat-akun-sesi . Juga sebagai changelog, ketika backend kami sementara tidak tersedia, klien mengirim operasi tulis ke log, yang kemudian disinkronkan.

  • Firebase Cloud Messages memberi kami pemberitahuan dan topik push upstream / downstream. Kami menggunakan layanan untuk pertukaran pesan pub / sub.

  • Analitik Firebase Sebagian besar untuk metrik.

  • Back-end untuk segala sesuatu yang terkait erat dengan bisnis


1

Jawaban singkat: Jangan gunakan logika bisnis.

Jawaban panjang: Anda menggambarkan aplikasi yang tampaknya cukup kecil untuk tidak memiliki logika bisnis yang terpisah; mengevaluasi jika Anda benar-benar memiliki logika bisnis seperti itu di tempat pertama; banyak logika bisnis dapat dikurangi dengan desain data, dan sedikit oleh lapisan presentasi. Banyak sistem kecil kebanyakan CRUD dan tidak memiliki logika bisnis nyata; sering kali saya melihat dua atau tiga lapisan kelas yang hanya melewati objek meninggalkan ruang untuk masa depan yang tidak akan pernah tiba.

Anda dapat mulai dengan API langsung dari Firebase, dan kemudian memperkenalkan lapisan tambahan untuk logika bisnis ketika Anda menemukan ada kebutuhan nyata untuk itu, selama Anda mendesain kontrak Anda dengan cukup baik agar layanan dapat mempertahankan tanda tangan yang stabil sementara implementasi di belakang dapat berubah.


Tidak bisa mengatakannya karena saya setuju dengan ini. Saya telah bekerja di industri ini selama 20 tahun, dan telah mengerjakan bagian dari aplikasi CRUD kecil saya, tetapi hampir selalu ada beberapa logika bisnis. Bahkan jika itu hanya validasi khusus atau perhitungan pajak, selalu ada sesuatu.
Jules

Saya setuju dengan komentar Anda. Saya tidak mengatakan tidak ada logika bisnis; apa yang saya katakan adalah tidak cukup besar untuk mendapatkan lapisan terpisah. Saya akan berpendapat jika validasi atau perhitungan tersebut benar-benar milik lapisan bisnis dan bukan data atau lapisan presentasi (terutama validasi khusus cenderung cocok dengan definisi saya tentang logika data), tetapi intinya bukan untuk menjelaskan di mana seharusnya diklasifikasikan, tetapi pragmatis di mana kode itu.
Bruno Guardia

0

lihat /programming/54994228/how-to-minimise-firebase-function-latency

Cloud Firestore adalah koneksi utama dan satu-satunya antara front-end dan backend. Tentu saja beberapa logika dapat berada di front-end, tetapi untuk keamanan yang biasanya hanya untuk keuntungan pengguna secara offline. Anda harus menerapkan keamanan pada koleksi Cloud Firestore sendiri, mengamankan peran atau apa pun yang Anda butuhkan.

Kemudian, gunakan Fungsi Cloud yang dipanggil dari pemicu Cloud Firestore.

Anda HARUS tidak pernah memanggil Fungsi Cloud dari aplikasi front-end.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.