Terlalu banyak panggilan REST API pada halaman?

8

Aplikasi web yang dirancang dengan komponen kecil yang sangat modular (dalam hal ini menggunakan arahan AngularJS tetapi bisa dengan mudah menjadi komponen Web, komponen ReactJS, atau teknologi lainnya). Komponen sering kali memiliki panggilan REST API yang tidak sinkron, saat inisialisasi atau saat interaksi pengguna. Desain ini menyebabkan banyak panggilan API per halaman (terkadang 20+). Apakah ada masalah dengan desain ini? Beberapa menyarankan kami memadatkan panggilan API ke layanan sisi klien yang lebih besar yang bertindak sebagai lajang. Jadi 10 panggilan API dapat dikurangi menjadi 1, meskipun satu halaman hanya dapat menggunakan sebagian dari data itu. Apakah ada tanda bahaya, atau ada masalah dengan desain ini? Yang mana yang lebih disukai?

rest api async Ryan Langton
sumber
Saya pikir banyak dari ini tergantung pada latensi yang Anda alami dan dampaknya pada pengguna (apakah mereka memperhatikannya)?
Niall
Ini adalah panggilan tak sinkron dan paling sering terjadi sekaligus (inisialisasi halaman). Jadi pengguna hanya melihat layar dan bar pemuatan yang sedikit abu-abu sampai semua data dimuat. Saya pikir ini adalah pengalaman pengguna yang bagus. Satu-satunya kekhawatiran saya adalah volume panggilan server, apakah itu masalah (batasan API? Dll). Dalam aplikasi tradisional, saya akan melakukan satu panggilan ke server per halaman.
Ryan Langton
1
Saya tidak tahu adanya keterbatasan begitu saja. Itu terdengar seperti trade off; desain vs. pemeliharaan vs latensi vs. dll. Saya lebih suka lebih sedikit, tetapi bahwa semua data masih relevan dengan panggilan (yaitu jika data yang diperlukan tidak relevan dengan panggilan API, maka buatlah panggilan terpisah). Saya akui, saya pikir ini adalah 6 dari satu, setengah lusin lainnya.
Niall
Pertimbangkan untuk meningkatkan server Anda ke HTTP 2.
CodesInChaos

Jawaban:

2

Browser membatasi jumlah total permintaan bersamaan

/programming/561046

Jadi ya, ada masalah dengan desain ini. Namun saya pikir tanggapan yang diterima adalah pindah ke implementasi soket web di mana Anda menggunakan koneksi tunggal, tetapi dengan banyak jenis pesan untuk berkomunikasi dengan server

Ewan
sumber
1
Ini sepertinya bukan masalah karena batas per browser. Jadi, jika ada lebih dari 6 panggilan, yang lain hanya akan mengantri. Setuju bahwa koneksi soket web akan lebih efisien, hanya saja tidak yakin jika perlu.
Ryan Langton
tergantung pada bagaimana Anda menggunakan panggilan itu saya kira. Masalah utama adalah bahwa ketika kode sisi klien semakin rumit Anda mulai mengalami keterbatasan javascript. misalnya. mengkode koneksi pooling socket client dalam bahasa yang dirancang untuk mengubah warna teks pada mouseover
Ewan
"Jadi ya, ada masalah dengan desain ini" - yang sepertinya terlalu berlebihan. Ada banyak cara agar desain ini dapat diimplementasikan dengan sukses.
richard
2

Desain ini menyebabkan banyak panggilan API per halaman (terkadang 20+). Apakah ada masalah dengan desain ini?

Seharusnya tidak ada. Fakta bahwa setiap permintaan kecil dan async berarti Anda dapat sangat mempercepat aplikasi web Anda, daripada harus menunggu satu permintaan besar untuk menyelesaikan yang memblokir semuanya.

Pastikan javascript Anda benar-benar tidak sinkron dan dapat melakukan hal-hal sementara permintaan Anda yang lain menunggu dan Anda akan berakhir dengan aplikasi yang jauh lebih baik daripada jika Anda memiliki satu permintaan besar yang mengambil semuanya.

Setelah semua browser dirancang untuk menangani pemuatan banyak URL secara bersamaan, bahkan halaman web standar yang khas mungkin memiliki puluhan atau bahkan ratusan permintaan untuk gambar, css, javascript, iframe, dll.

Cormac Mulhall
sumber
1

Jangan lupa ukuran setiap permintaan jaringan. Secara umum, jika setiap permintaan hanya mengembalikan seperti 2 KB data, maka permintaan jaringan mahal untuk sejumlah kecil data.

Jika permintaan jaringan mencapai 400KB, maka bagi menjadi dua. Tetapi secara umum, tidak cukup data untuk satu permintaan jaringan lebih sering menjadi masalah.

dman
sumber
0

Beberapa pertimbangan di sini:

Performa

Jika Anda melihat kinerja yang dapat diterima, Anda tidak perlu terlalu khawatir tentang hal itu. Jika Anda dapat mengelola untuk menjalankan HTTP2 Anda akan melihat peningkatan kinerja. [1] .

Rancangan

Seperti halnya desain apa pun, tidak ada aturan cepat tentang apakah Anda harus melakukan banyak permintaan kecil atau beberapa permintaan besar. Beberapa hal yang perlu dipertimbangkan:

  1. Apakah banyak panggilan yang saling tergantung? Jika Anda memiliki hubungan ketergantungan yang kompleks antara panggilan yang berbeda, hal itu dapat membuat pemeliharaan menjadi lebih sulit.

  2. Apakah komponen yang berbeda memiliki banyak data yang sama? Jika demikian, Anda dapat memiliki titik pusat yang melakukan panggilan bersama dan memungkinkan komponen mengakses data bersama.

  3. Mengawasi beban pemeliharaan komponen kecil yang melakukan panggilan terpisah. Anda akan tahu ketika itu menjadi sulit untuk dikelola dan kemudian perubahan mungkin diperlukan. Mengubah desain berdasarkan kebutuhan hipotetis di masa depan dapat menyebabkan kesalahan desain, karena Anda harus secara akurat mengantisipasi masalah apa yang akan Anda miliki di masa depan. Jika itu berfungsi dengan baik sekarang, mengubahnya juga tidak perlu.

1: "HTTP / 2 sepenuhnya multiplexing memungkinkan beberapa file dan permintaan untuk ditransfer pada saat yang sama, yang bertentangan dengan HTTP1.x yang hanya menerima satu permintaan / koneksi tunggal pada suatu waktu. HTTP / 2 menggunakan koneksi yang sama untuk mentransfer berbagai file dan permintaan, menghindari operasi besar membuka koneksi baru untuk setiap file yang perlu ditransfer antara klien dan server. " - https://css-tricks.com/http2-real-world-performance-test-analysis/

Tjaart
sumber