Nhiều cuộc gọi không đồng bộ so với cuộc gọi đơn tới API

Chúng tôi đang phát triển API REST mà trong số các API khác sẽ được sử dụng bởi một giao diện HTML5 thông qua javascript. Ứng dụng này được sử dụng trong tổ chức và thường có khoảng 300 người dùng, nhưng chúng tôi muốn mở rộng quy mô lên tới 1000 người dùng.

Thông thường các kết nối với API sẽ được thực hiện trong mạng LAN nên chất lượng và độ trễ của kết nối sẽ tốt, mặc dù không loại trừ việc sử dụng thường xuyên qua Internet khi kết nối có thể chậm hơn và có độ trễ hơn qua 3G / 4G.

Hai tùy chọn mà chúng tôi nghĩ là:

1. Giao diện sẽ thực hiện một số cuộc gọi không đồng bộ đồng thời tới API để tải các thành phần khác nhau của giao diện.

   • Ưu điểm: Đơn giản.
   • Nhược điểm: Nhiều kết nối đến máy chủ.

2. Bộ điều khiển của frontend sẽ thực hiện một cuộc gọi đến API chuyển qua dưới dạng tham số mà các đối tượng cần được tìm nạp.

   • Ưu điểm: Chỉ có một kết nối đến máy chủ, mặc dù máy chủ sẽ tạo một số kết nối tới cơ sở dữ liệu.
   • Nhược điểm: Yêu cầu cơ chế trong cả frontend và API. Nó làm phức tạp thiết kế.

Giải thích thêm: Sẽ có các tài nguyên khác nhau ... / Sản phẩm ... / Vị trí, v.v. Những tài nguyên này có thể được tìm nạp một mình, nhưng sẽ có một tài nguyên trừu tượng khác ... / màn hình? Sản phẩm & Vị trí sẽ tìm nạp cả hai trong một cuộc gọi.

Tùy chọn 1 (nhiều cuộc gọi không đồng bộ) là lựa chọn tốt nhất vì:

1. mỗi cuộc gọi riêng lẻ là thực thể riêng của nó , vì vậy bạn có thể thử lại nếu có lỗi xảy ra. Trong kiến ​​trúc 'một cuộc gọi' nguyên khối, nếu một điều không thành công, bạn phải thực hiện lại toàn bộ cuộc gọi
2. mã phía máy chủ sẽ đơn giản hơn: một lần nữa, tính mô đun , nghĩa là các nhà phát triển khác nhau có thể làm việc trên các tài nguyên API khác nhau
3. Trong một mẫu MVC điển hình , không có nghĩa là có một lệnh gọi API tải nhiều tài nguyên riêng biệt ; ví dụ: nếu bạn yêu cầu /productslấy danh sách các sản phẩm để hiển thị trên một trang và bạn cũng muốn hiển thị danh sách các địa điểm bán sản phẩm phổ biến, bạn có hai tài nguyên riêng biệt: Productvà Location. Mặc dù chúng được hiển thị trên cùng một trang, nhưng bạn không thể thực hiện cuộc gọi một cách hợp lý/products và nó cũng trả lại vị trí
4. báo cáo đăng nhập / sử dụng của bạn sẽ đơn giản hơn trong phương pháp mô-đun. Nếu bạn yêu cầu /productsvà bạn cũng đang tải vị trí, các tệp nhật ký của bạn sẽ thực sự khó hiểu
5. nếu bạn gặp rắc rối với một nguồn lực đặc biệt, cách tiếp cận một cuộc gọi sẽ làm cho toàn bộ trang để phá vỡ và nó sẽ không được rõ ràng cho người dùng của bạn những gì đã phá vỡ - và các phương tiện này nó sẽ mất nhiều thời gian cho nhóm của bạn để khắc phục vấn đề; tuy nhiên, trong phương pháp mô-đun nếu một thứ bị hỏng, sẽ rất rõ ràng những gì đã phá vỡ và bạn có thể sửa nó nhanh hơn. Nó cũng sẽ không làm hỏng phần còn lại của trang (trừ khi mọi thứ được kết hợp quá chặt chẽ ...)
6. Nói chung sẽ dễ dàng hơn để thay đổi nếu mọi thứ được tách ra; nếu bạn có 5 tài nguyên được tải bởi một lệnh gọi API, sẽ khó hơn để tìm ra cách không phá vỡ mọi thứ khi bạn muốn thay đổi thứ gì đó

Toàn bộ vấn đề là các tài nguyên là riêng biệt và trong API REST trả về nhiều tài nguyên riêng biệt từ một đường dẫn API duy nhất không có ý nghĩa, ngay cả khi bạn đang "lưu kết nối với máy chủ". Nhân tiện, sử dụng tham số để tải tài nguyên (khác nhau) có điều kiện không phải là RESTful.

Tất cả những gì đã nói, tùy chọn hợp lý duy nhất là thực hiện nhiều yêu cầu không đồng bộ để phân tách tài nguyên: thực hiện phương pháp mô đun !

Tái bút - Không tối ưu hóa sớm "kết nối với máy chủ", đặc biệt khi các kết nối HTTP có chi phí cực thấp và bạn đang sử dụng mạng LAN. Kiểu suy nghĩ đó thay vì chọn thiết kế đơn giản hơn ngay lập tức sẽ khiến bạn gặp rắc rối sau này.