Membuat layanan backend terpisah untuk digunakan oleh aplikasi atau antarmuka frontend tertentu. Pola ini berguna jika Anda ingin menghindari penyesuaian satu backend untuk beberapa antarmuka. Pola ini pertama kali dijelaskan oleh Sam Newman.
Konteks dan masalah
Aplikasi mungkin awalnya ditargetkan pada UI web desktop. Biasanya, layanan backend dikembangkan secara paralel yang menyediakan fitur yang diperlukan untuk UI tersebut. Seiring bertambahnya basis pengguna aplikasi, aplikasi seluler dikembangkan yang harus berinteraksi dengan backend yang sama. Layanan backend menjadi backend tujuan umum, yang melayani persyaratan antarmuka desktop dan seluler.
Tetapi kemampuan perangkat seluler berbeda secara signifikan dengan browser desktop, dalam hal ukuran layar, performa, dan batasan tampilan. Akibatnya, persyaratan untuk backend aplikasi seluler berbeda dengan UI web desktop.
Perbedaan ini menghasilkan persyaratan yang bersaing untuk backend. Backend memerlukan perubahan reguler dan signifikan untuk melayani UI web desktop dan aplikasi seluler. Seringkali, tim antarmuka yang terpisah bekerja di setiap frontend, menyebabkan backend menjadi hambatan dalam proses pengembangan. Persyaratan pembaruan yang saling bertentangan, dan kebutuhan untuk menjaga agar layanan tetap berfungsi untuk kedua frontend, dapat mengakibatkan pengeluaran banyak upaya pada satu sumber daya yang dapat disebarkan.
Karena aktivitas pengembangan berfokus pada layanan backend, tim terpisah dapat dibuat untuk mengelola dan memelihara backend. Pada akhirnya, ini mengakibatkan pemutusan antara antarmuka dan tim pengembangan backend, menempatkan beban pada tim backend untuk menyeimbangkan persyaratan yang bersaing dari tim UI yang berbeda. Jika satu tim antarmuka memerlukan perubahan pada backend, perubahan tersebut harus divalidasi dengan tim antarmuka lainnya sebelum dapat diintegrasikan ke dalam backend.
Solusi
Buat satu backend per antarmuka pengguna. Sempurnakan perilaku dan performa setiap backend agar paling sesuai dengan kebutuhan lingkungan frontend, tanpa khawatir akan memengaruhi pengalaman frontend lainnya.
Karena setiap backend khusus untuk satu antarmuka, backend tersebut dapat dioptimalkan untuk antarmuka itu. Akibatnya, backend ini akan lebih kecil, kurang kompleks, dan kemungkinan lebih cepat daripada backend umum yang mencoba memenuhi persyaratan untuk semua antarmuka. Setiap tim antarmuka memiliki otonomi untuk mengontrol backend mereka sendiri dan tidak bergantung pada tim pengembangan backend terpusat. Ini memberikan fleksibilitas pada tim antarmuka dalam pemilihan bahasa, irama rilis, prioritas beban kerja, dan integrasi fitur di backend mereka.
Untuk informasi selengkapnya, lihat Pola: Backends Untuk Frontends.
Masalah dan pertimbangan
- Pertimbangkan berapa banyak backend yang akan disebarkan.
- Jika antarmuka yang berbeda (seperti klien seluler) akan membuat permintaan yang sama, pertimbangkan apakah perlu menerapkan backend untuk setiap antarmuka, atau jika satu backend sudah cukup.
- Duplikasi kode di seluruh layanan sangat mungkin terjadi saat menerapkan pola ini.
- Layanan backend yang berfokus pada frontend hanya boleh berisi logika dan perilaku khusus klien. Logika bisnis umum dan fitur global lainnya harus dikelola di tempat lain dalam aplikasi Anda.
- Pikirkan tentang bagaimana pola ini dapat tercermin dalam tanggung jawab tim pengembangan.
- Pertimbangkan berapa lama waktu yang dibutuhkan untuk menerapkan pola ini. Apakah upaya membuat backend baru akan menimbulkan utang teknis, sementara Anda terus mendukung backend generik yang ada?
Kapan menggunakan pola ini
Gunakan pola ini ketika:
- Layanan backend tujuan bersama atau umum harus dipertahankan dengan overhead pengembangan yang signifikan.
- Anda ingin mengoptimalkan backend untuk persyaratan antarmuka klien tertentu.
- Penyesuaian dilakukan untuk tujuan umum backend guna mengakomodasi beberapa antarmuka.
- Bahasa pemrograman lebih cocok untuk backend antarmuka pengguna tertentu, tetapi tidak semua antarmuka pengguna.
Pola ini mungkin tidak cocok:
- Saat antarmuka membuat permintaan yang sama atau mirip ke backend.
- Saat hanya satu antarmuka yang digunakan untuk berinteraksi dengan backend.
Desain beban kerja
Arsitek harus mengevaluasi bagaimana pola Backends for Frontends dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:
| Pilar | Bagaimana pola ini mendukung tujuan pilar |
|---|---|
| Keputusan desain keandalan membantu beban kerja Anda menjadi tahan terhadap kerusakan dan untuk memastikan bahwa keputusan tersebut pulih ke status berfungsi penuh setelah kegagalan terjadi. | Memiliki layanan terpisah yang eksklusif untuk antarmuka frontend tertentu berisi kerusakan sehingga ketersediaan satu klien mungkin tidak memengaruhi ketersediaan akses klien lain. Selain itu, ketika Anda memperlakukan berbagai klien secara berbeda, Anda dapat memprioritaskan upaya keandalan berdasarkan pola akses klien yang diharapkan. - ALUR KRITIS RE:02 - RE:07 Pelestarian Mandiri |
| Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja Anda. | Karena pemisahan layanan yang diperkenalkan dalam pola ini, keamanan dan otorisasi di lapisan layanan yang mendukung satu klien dapat disesuaikan dengan fungsionalitas yang diperlukan oleh klien tersebut, berpotensi mengurangi area permukaan API dan gerakan lateral di antara backend yang berbeda yang mungkin mengekspos kemampuan yang berbeda. - Segmentasi SE:04 - Sumber daya PENGERASAN SE:08 |
| Efisiensi Performa membantu beban kerja Anda memenuhi tuntutan secara efisien melalui pengoptimalan dalam penskalaan, data, 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 |
Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.