Backend untuk pola Frontend

Pola ini menjelaskan bagaimana memisahkan layanan backend dari implementasi frontend untuk menyesuaikan pengalaman bagi antarmuka klien yang berbeda. Pola ini berguna ketika Anda ingin menghindari penyesuaian backend yang melayani beberapa antarmuka. Pola ini didasarkan pada pola Backends for Frontends oleh Sam Newman.

Konteks dan masalah

Pertimbangkan aplikasi yang awalnya dirancang dengan UI web desktop dan layanan backend yang sesuai. Seiring perubahan persyaratan bisnis dari waktu ke waktu, antarmuka seluler ditambahkan. Kedua antarmuka berinteraksi dengan layanan backend yang sama. Tetapi kemampuan perangkat seluler berbeda secara signifikan dari browser desktop dalam hal ukuran layar, performa, dan batasan tampilan.

Diagram memiliki dua bagian: layanan backend dan klien desktop dan klien seluler. Dua panah dua sisi menunjuk dari layanan backend ke klien desktop dan klien seluler.

Layanan backend sering mengalami tuntutan yang bersaing dari beberapa sistem frontend. Tuntutan ini mengakibatkan seringnya pembaruan dan potensi penyempitan pengembangan. Pembaruan yang bertentangan dan kebutuhan untuk mempertahankan kompatibilitas menghasilkan permintaan yang berlebihan pada satu sumber daya yang dapat disebarkan.

Meminta tim terpisah mengelola layanan backend dapat membuat pemutusan sambungan antara tim frontend dan backend. Pemutusan sambungan ini dapat menyebabkan keterlambatan dalam mendapatkan konsensus dan menyeimbangkan persyaratan. Misalnya, perubahan yang diminta oleh satu tim frontend harus divalidasi dengan tim frontend lainnya sebelum integrasi.

Solusi

Perkenalkan lapisan baru yang hanya menangani persyaratan yang khusus untuk antarmuka. Lapisan ini, yang dikenal sebagai layanan backend-for-frontend (BFF), berada di antara klien frontend dan layanan backend. Jika aplikasi mendukung beberapa antarmuka, seperti antarmuka web dan aplikasi seluler, buat layanan BFF untuk setiap antarmuka.

Pola ini menyesuaikan pengalaman klien untuk antarmuka tertentu tanpa memengaruhi antarmuka lain. Ini juga mengoptimalkan performa untuk memenuhi kebutuhan lingkungan frontend. Karena setiap layanan BFF lebih kecil dan kurang kompleks daripada layanan backend bersama, itu dapat membuat aplikasi lebih mudah dikelola.

Tim frontend secara independen mengelola layanan BFF mereka sendiri, yang memberi mereka kontrol atas pemilihan bahasa, irama rilis, prioritas beban kerja, dan integrasi fitur. Otonomi ini memungkinkan mereka beroperasi secara efisien tanpa bergantung pada tim pengembangan backend terpusat.

Banyak layanan BFF secara tradisional bergantung pada REST API, tetapi implementasi GraphQL muncul sebagai alternatif. Dengan GraphQL, mekanisme kueri menghilangkan kebutuhan akan lapisan BFF terpisah karena memungkinkan klien untuk meminta data yang mereka butuhkan tanpa mengandalkan titik akhir yang telah ditentukan sebelumnya.

Diagram menunjukkan tiga bagian. Bagian pertama terdiri dari klien desktop dan klien seluler. Bagian kedua terdiri dari layanan BFF klien desktop dan layanan BFF klien seluler. Klien desktop memiliki panah solid yang menunjuk ke layanan BFF dari klien desktop. Klien seluler memiliki panah solid yang menunjuk ke layanan BFF (Best Friend Forever) klien seluler. Setiap layanan BFF memiliki panah putus-putus yang menunjuk ke bagian layanan backend.

Untuk informasi selengkapnya, lihat pola Backends untuk Frontends oleh Sam Newman.

Masalah dan pertimbangan

• Evaluasi jumlah layanan optimal Anda tergantung pada biaya terkait. Mempertahankan dan menyebarkan lebih banyak layanan berarti peningkatan overhead operasional. Setiap layanan individu memiliki siklus hidup, persyaratan penyebaran dan pemeliharaannya sendiri, serta kebutuhan keamanan.

• Tinjau tujuan tingkat layanan saat Anda menambahkan layanan baru. Peningkatan latensi mungkin terjadi karena klien tidak menghubungi layanan Anda secara langsung, dan layanan baru memperkenalkan hop jaringan tambahan.

• Ketika antarmuka yang berbeda membuat permintaan yang sama, evaluasi apakah permintaan dapat dikonsolidasikan ke dalam satu layanan BFF. Berbagi satu layanan BFF antara beberapa antarmuka dapat mengakibatkan persyaratan yang berbeda untuk setiap klien, yang dapat mempersulit pertumbuhan dan dukungan layanan BFF.

  Duplikasi kode adalah kemungkinan hasil dari pola ini. Evaluasi kompromi antara duplikasi kode dan pengalaman yang lebih terarah untuk setiap klien.

• Layanan BFF hanya boleh menangani logika khusus klien yang terkait dengan pengalaman pengguna tertentu. Fitur lintas sektoral, seperti pemantauan dan otorisasi, harus dilakukan abstraksi untuk menjaga efisiensi. Fitur umum yang mungkin muncul dalam layanan BFF ditangani secara terpisah dengan pola Gatekeeping, Pembatasan Laju, dan Perutean .

• Pertimbangkan bagaimana pembelajaran dan penerapan pola ini memengaruhi tim pengembangan. Mengembangkan sistem backend baru membutuhkan waktu dan upaya, yang dapat mengakibatkan utang teknis. Mempertahankan layanan backend yang ada menambah tantangan ini.

• Evaluasi apakah Anda memerlukan pola ini. Misalnya, jika organisasi Anda menggunakan GraphQL dengan pemecah masalah khusus frontend, layanan BFF mungkin tidak menambahkan nilai ke aplikasi Anda.

  Skenario lain adalah aplikasi yang menggabungkan gateway API dengan layanan mikro. Pendekatan ini mungkin cukup untuk beberapa skenario di mana layanan BFF biasanya direkomendasikan.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Layanan backend bersama atau tujuan umum memerlukan overhead pengembangan yang substansial untuk dipertahankan.

• Anda ingin mengoptimalkan backend untuk persyaratan antarmuka klien tertentu.

• Anda membuat penyesuaian ke backend tujuan umum untuk mengakomodasi beberapa antarmuka.

• Bahasa pemrograman lebih cocok untuk backend antarmuka pengguna tertentu, tetapi tidak semua antarmuka pengguna.

Pola ini mungkin tidak cocok ketika:

• Antarmuka membuat permintaan yang sama atau serupa dengan backend.

• Hanya satu antarmuka yang berinteraksi dengan backend.

Desain beban kerja

Evaluasi cara menggunakan pola Backends for Frontends dalam desain beban kerja untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Pilar	Bagaimana pola ini mendukung tujuan pilar
Keputusan desain Keandalan membantu beban kerja Anda menjadi tangguh tidak berfungsi dan memastikan bahwa memulihkan ke keadaan yang berfungsi penuh setelah kegagalan terjadi.	Saat Anda mengisolasi layanan ke antarmuka frontend tertentu, Anda mengendalikan kerusakan. Ketersediaan satu klien tidak memengaruhi ketersediaan akses klien lain. Ketika Anda memperlakukan berbagai klien secara berbeda, Anda dapat memprioritaskan upaya keandalan berdasarkan pola akses klien yang diharapkan. - ALUR KRITIS RE:02 - RE:07 Perlindungan Diri
Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja Anda.	Pemisahan layanan yang diperkenalkan dalam pola ini memungkinkan keamanan dan otorisasi di lapisan layanan disesuaikan untuk kebutuhan spesifik setiap klien. Pendekatan ini dapat mengurangi area permukaan API dan membatasi pergerakan lateral antara backend yang mungkin mengekspos kemampuan yang berbeda. - Segmentasi SE:04 - Sumber daya PENGERASAN SE:08
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode.	Pemisahan backend memungkinkan Anda untuk mengoptimalkan dengan cara yang mungkin tidak dimungkinkan dengan lapisan layanan bersama. Saat Menangani klien individual secara berbeda, Anda dapat mengoptimalkan performa untuk batasan dan fungsionalitas klien tertentu. - Perencanaan kapasitas PE:02 - ALUR KRITIS PE:09

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Contoh

Contoh ini menunjukkan kasus penggunaan untuk pola di mana dua aplikasi klien yang berbeda, aplikasi seluler dan aplikasi desktop, berinteraksi dengan Azure API Management (gateway bidang data). Gateway ini berfungsi sebagai lapisan abstraksi dan mengelola masalah lintas fungsi umum seperti:

• Otorisasi. Memastikan bahwa hanya identitas terverifikasi dengan token akses yang tepat yang dapat memanggil sumber daya yang dilindungi dengan menggunakan API Management dengan ID Microsoft Entra.

• Pemantauan. Menangkap dan mengirim detail permintaan dan respons ke Azure Monitor untuk tujuan pengamatan.

• Meminta penembolokan. Mengoptimalkan permintaan berulang dengan melayani respons dari cache dengan fitur bawaan API Management.

• Perutean dan agregasi. Mengarahkan permintaan masuk ke layanan BFF yang sesuai.

Setiap klien memiliki layanan BFF khusus yang berjalan sebagai fungsi Azure yang berfungsi sebagai perantara antara gateway dan layanan mikro yang mendasarinya. Layanan BFF khusus klien ini memastikan pengalaman yang disesuaikan untuk penomoran halaman dan fungsionalitas lainnya. Aplikasi seluler memprioritaskan efisiensi bandwidth dan memanfaatkan cache untuk meningkatkan performa. Sebaliknya, aplikasi desktop mengambil beberapa halaman dalam satu permintaan, yang menciptakan pengalaman pengguna yang lebih imersif.

Diagram disusun menjadi empat bagian yang menggambarkan alur permintaan, autentikasi, pemantauan, dan pemrosesan khusus klien. Dua perangkat klien memulai permintaan: aplikasi seluler yang dioptimalkan untuk pengalaman pengguna yang efisien bandwidth dan browser web yang menyediakan antarmuka yang berfungsi penuh. Panah memanjang dari kedua perangkat ke arah titik masuk, yang merupakan gateway API Management, untuk menunjukkan bahwa semua permintaan harus melalui lapisan ini. Pada bagian kedua, dikelilingi oleh persegi panjang dengan garis putus-putus, arsitektur dibagi menjadi dua kelompok horizontal. Grup kiri mewakili API Management yang menangani permintaan masuk dan menentukan cara memprosesnya. Dua panah memanjang ke arah luar dari gerbang bidang data ini. Satu panah menunjuk ke atas ke ID Microsoft Entra, yang mengelola otorisasi. Panah lain menunjuk ke bawah ke Azure Monitor, yang bertanggung jawab untuk pencatatan log dan pengamatan. Panah berputar kembali dari gateway ke klien seluler, yang mewakili respons cache ketika permintaan identik diulang, mengurangi pemrosesan yang tidak perlu. Grup yang tepat dalam persegi panjang putus-putus berfokus pada menyesuaikan respons backend berdasarkan jenis klien yang membuat permintaan. Ini fitur dua klien backend-for-frontend terpisah, keduanya dihosting dengan menggunakan Azure Functions untuk komputasi tanpa server. Satu didedikasikan untuk klien seluler dan yang lain untuk klien desktop. Dua panah memanjang dari gateway ke klien backend-for-frontend ini, yang menggambarkan bahwa setiap permintaan masuk diteruskan ke layanan yang sesuai, tergantung pada jenis klien. Di luar lapisan ini, panah putus-putus memperluas dan menghubungkan klien backend-for-frontend ke berbagai layanan mikro, yang menangani logika bisnis yang sebenarnya. Gambar menunjukkan alur kiri-ke-kanan tempat permintaan klien berpindah dari klien seluler dan web ke gateway. Gateway ini memproses setiap permintaan saat mendelegasikan autentikasi ke atas ke penyedia identitas dan masuk ke bawah ke layanan pemantauan. Dari sana, ia merutekan permintaan ke klien backend-for-frontend yang sesuai berdasarkan apakah permintaan berasal dari klien seluler atau desktop. Akhirnya, setiap klien backend-for-frontend meneruskan permintaan ke layanan mikro khusus, yang melakukan logika bisnis yang diperlukan dan mengembalikan respons yang diperlukan. Jika respons cache tersedia, gateway mencegat permintaan dan mengirim respons tersimpan langsung ke klien seluler, yang mencegah pemrosesan redundan.

Alur A untuk permintaan halaman pertama dari klien seluler

1. Klien seluler mengirimkan GET permintaan untuk halaman 1, termasuk token OAuth 2.0 di header otorisasi.

2. Permintaan ini mencapai gateway API Management, yang mencegatnya dan:

   1. Memeriksa status otorisasi. API Management menerapkan pertahanan secara mendalam, sehingga memeriksa validitas token akses.

   2. Mengalirkan aktivitas permintaan sebagai log ke Azure Monitor. Detail permintaan dicatat untuk audit dan pemantauan.

3. Kebijakan diterapkan, kemudian API Management merutekan permintaan ke layanan Azure function mobile BFF.

4. Layanan fungsi Azure BFF seluler kemudian berinteraksi dengan layanan mikro yang diperlukan untuk mengambil satu halaman dan memproses data yang diminta demi memberikan pengalaman yang lebih lancar.

5. Respons dikembalikan ke klien.

Alur B untuk permintaan cache halaman pertama dari klien seluler

1. Klien bergerak mengirim permintaan yang sama GET untuk halaman 1 lagi, termasuk token OAuth 2.0 di header otorisasi.

2. Gateway API Management mengenali bahwa permintaan ini dibuat sebelumnya dan:

   1. Kebijakan diberlakukan. Kemudian gateway mengidentifikasi respons cache yang cocok dengan parameter permintaan.

   2. Mengembalikan respons yang di-cache segera. Respons cepat ini menghilangkan kebutuhan untuk meneruskan permintaan ke layanan BFF fungsi Azure untuk seluler.

Alur C untuk permintaan pertama dari klien desktop

1. Aplikasi klien desktop mengirimkan permintaan GET untuk pertama kalinya, dengan menyertakan token OAuth 2.0 di dalam header otorisasi.

2. Permintaan mencapai gerbang API Management, di mana kepentingan lintas aspek ditangani.

   1. Otorisasi: Validasi token selalu diperlukan.

   2. Streaming aktivitas permintaan: Detail permintaan dicatat untuk pengamatan.

3. Setelah semua kebijakan berlaku, API Management merutekan permintaan ke layanan Azure Functions untuk desktop BFF, yang menangani pemrosesan aplikasi yang berfokus pada data. Layanan desktop BFF merangkum beberapa permintaan dengan menggunakan panggilan layanan mikro yang mendasar sebelum memberikan respons kepada klien yang terdiri dari beberapa halaman.

Desain

• ID Microsoft Entra berfungsi sebagai IdP berbasis cloud. Ini menyediakan klaim audiens yang disesuaikan untuk klien seluler dan desktop. Klaim ini kemudian digunakan untuk otorisasi.

• API Management berfungsi sebagai proksi antara klien dan layanan BFF mereka, yang menetapkan perimeter. API Management dikonfigurasi dengan kebijakan untuk memvalidasi JSON Web Tokens dan menolak permintaan yang tidak memiliki token atau berisi klaim yang tidak valid untuk layanan BFF yang ditargetkan. Ini juga mengalirkan semua log aktivitas ke Azure Monitor.

• Azure Monitor berfungsi sebagai solusi pemantauan terpusat. Ini mengumpulkan semua log aktivitas untuk memastikan pemantauan yang komprehensif dan holistik.

• Azure Functions adalah solusi tanpa server yang secara efisien mengekspos logika layanan BFF di beberapa titik akhir, yang menyederhanakan pengembangan. Azure Functions juga meminimalkan overhead infrastruktur dan membantu menurunkan biaya operasional.

Langkah selanjutnya

• Backends for Frontends pattern oleh Sam Newman
• Autentikasi dan otorisasi ke API di API Management
• Cara mengintegrasikan API Management dengan Application Insights

Sumber daya terkait

• Gateway
• Pola Gateway Offloading
• Pola Gateway Routing