Banyak panggilan tidak sinkron vs. panggilan tunggal ke API

Kami sedang mengembangkan API REST yang antara lain akan dikonsumsi oleh HTML5 frontend melalui javascript. Aplikasi ini untuk digunakan dalam organisasi dan biasanya memiliki sekitar 300 pengguna, tetapi kami ingin skala hingga 1000 pengguna atau lebih.

Biasanya koneksi ke API akan dilakukan dalam LAN sehingga kualitas dan latensi koneksi akan baik, meskipun tidak dikecualikan penggunaan sesekali melalui Internet di mana koneksi bisa lebih lambat dan dengan lebih banyak lag melalui 3G / 4G.

Dua opsi yang kami pikir adalah:

1. Frontend akan membuat beberapa panggilan asinkron secara simultan ke API untuk memuat berbagai komponen antarmuka.

   • Pro: Kesederhanaan.
   • Cons: Lebih banyak koneksi ke server.

2. Pengontrol frontend akan membuat satu panggilan ke API yang lewat sebagai parameter yang objek harus diambil.

   • Pro: Hanya satu koneksi ke server, meskipun server akan membuat beberapa koneksi ke database.
   • Cons: Memerlukan mekanisme di frontend dan API. Ini menyulitkan desain.

Penjelasan lebih lanjut: Akan ada sumber daya yang berbeda ... / Produk ... / Lokasi dll. Sumber daya ini dapat diambil sendiri, tetapi akan ada sumber daya abstrak lain ... / layar? Produk & Lokasi yang akan mengambil keduanya dalam satu panggilan.

Opsi 1 (beberapa panggilan async) adalah pilihan terbaik karena:

1. setiap panggilan individu adalah entitasnya sendiri , sehingga Anda dapat mencoba lagi secara individual jika terjadi sesuatu yang gagal. Dalam arsitektur monolitik 'satu panggilan', jika satu hal gagal, Anda harus melakukan seluruh panggilan lagi
2. kode sisi server akan lebih sederhana: lagi, modularitas , artinya pengembang yang berbeda dapat bekerja pada sumber daya API yang berbeda
3. Dalam pola MVC yang khas , tidak masuk akal untuk memiliki satu panggilan API memuat banyak sumber daya terpisah ; misalnya, jika Anda membuat permintaan untuk /productsmendapatkan daftar produk untuk ditampilkan pada halaman, dan Anda juga ingin menampilkan daftar lokasi tempat produk populer dijual, Anda memiliki dua sumber daya terpisah: Productdan Location. Meskipun mereka ditampilkan pada halaman yang sama, Anda tidak dapat secara logis melakukan panggilan ke /productsdan memilikinya juga mengembalikan lokasi
4. laporan logging / utilisasi Anda akan lebih sederhana dalam pendekatan modular. Jika Anda membuat permintaan ke /productsdan Anda juga memuat lokasi, file log Anda akan sangat membingungkan
5. jika Anda memiliki masalah dengan sumber daya tertentu, pendekatan satu panggilan akan menyebabkan seluruh halaman rusak dan tidak jelas bagi pengguna Anda apa yang rusak - dan ini berarti akan lebih lama bagi tim Anda untuk memperbaiki masalah; Namun, dalam pendekatan modular jika satu hal rusak, akan sangat jelas apa yang rusak dan Anda dapat memperbaikinya lebih cepat. Itu juga tidak akan merusak sisa halaman (kecuali semuanya terlalu dekat ...)
6. akan lebih mudah untuk membuat perubahan secara umum jika semuanya terpisah; jika Anda memiliki 5 sumber daya yang dimuat oleh satu panggilan API, akan lebih sulit untuk mengetahui cara tidak merusak sesuatu ketika Anda ingin mengubah sesuatu

Intinya adalah bahwa sumber daya terpisah, dan dalam REST API mengembalikan banyak sumber daya terpisah dari satu jalur API tidak masuk akal, bahkan jika Anda "menyimpan koneksi ke server". Omong-omong, menggunakan parameter untuk memuat sumber (berbeda) secara kondisional tidak TENANG.

Semua yang dikatakan, satu-satunya pilihan logis adalah membuat beberapa permintaan async untuk memisahkan sumber daya: ambil pendekatan modular !

PS - Jangan terlalu cepat mengoptimalkan "koneksi ke server", terutama ketika koneksi HTTP sangat rendah dan Anda menggunakan LAN. Pemikiran seperti itu alih-alih memilih desain yang lebih sederhana segera akan membuat Anda kesulitan nanti.