Arsitektur berpusat pada Firebase

Ini adalah pertanyaan arsitektur.

Saat ini saya sedang dalam proses mendesain aplikasi web dan saya sudah terbiasa dengan dasar: frontend, api, database, pengaturan layanan mikro.

Demi menghemat uang dan membuat arsitektur saya sedikit lebih modern daripada biasanya, saya memutuskan untuk beralih ke tanpa server.

Dua bagian utama yang saya minati adalah fungsi Google Cloud dan Firebase. Pemahaman saya adalah bahwa fungsi cloud Google dapat diaktifkan ketika entri database di firebase telah dimanipulasi.

Cara yang saya gunakan untuk berkomunikasi antar layanan adalah melalui antrian pesan seperti RabbitMQ tetapi menurut saya dengan menggunakan fungsi firebase dan cloud Anda dapat membangun komunikasi melalui database tanpa memerlukan antrian pesan. Yang saya maksud dengan komunikasi dalam hal ini adalah bahwa satu layanan dapat bereaksi terhadap eksekusi layanan lain dengan melihat bahwa entri dalam database diubah.

Oleh karena itu, pertanyaan saya adalah, apa keuntungan dan kerugian membiarkan semua komunikasi antar layanan mikro berjalan melalui firebase alih-alih antrian pesan, dan apakah ini arsitektur yang umum digunakan?


google-cloud-firestore architecture serverless
person Alex Haller    schedule 31.12.2020    source sumber

Jawaban (1)


arrow_upward
2
arrow_downward

AFAIK, pemicu fungsi cloud adalah fitur beta di Firebase, dan menurut dokumen, ada beberapa batasan untuk peristiwa pemicu firestore:

  • Diperlukan waktu hingga 10 detik agar suatu fungsi merespons perubahan di Cloud Firestore.
  • Pemesanan tidak dijamin. Perubahan yang cepat dapat memicu pemanggilan fungsi dalam urutan yang tidak terduga.
  • Peristiwa dikirimkan setidaknya satu kali, namun satu peristiwa dapat mengakibatkan pemanggilan beberapa fungsi. Hindari bergantung pada mekanika tepat satu kali, dan tulis fungsi idempoten.
  • Pemicu Cloud Firestore untuk Cloud Functions hanya tersedia untuk Cloud Firestore dalam mode Native. Ini tidak tersedia untuk Cloud Firestore dalam mode Datastore.

Batasan yang paling memprihatinkan di sini adalah yang pertama. 10 detik untuk pembaruan adalah waktu yang lama jika Anda memerlukan pembaruan tersebut agar dapat dilihat oleh pengguna.

Kerugian lain yang saya lihat adalah ia mungkin lepas kendali (dalam hal desain sistem) seiring dengan meningkatnya kompleksitas. Anda mungkin tergoda untuk menambahkan acara untuk semuanya, dan mungkin sulit untuk mempartisinya berdasarkan kategori, misalnya (dalam antrian pesan, Anda dapat menggunakan topik untuk itu).

Selain itu, menurut doc, fungsi cloud dibatasi tarifnya hingga 16 pemanggilan per 100 detik, yang dapat dicapai dengan cepat jika Anda mendapatkan lalu lintas di aplikasi Anda.

Saya akan menggunakan peristiwa pemicu untuk skenario terisolasi dan menggunakan antrian pesan untuk komunikasi tulang punggung antar layanan mikro.

person Cosmin Ioniță    schedule 01.01.2021