Quá nhiều lệnh gọi API REST trên một trang?

Một ứng dụng web được thiết kế với các thành phần nhỏ, có tính mô-đun cao (trong trường hợp này sử dụng các chỉ thị AngularJS nhưng có thể dễ dàng là các thành phần WebComponents, ReactJS hoặc bất kỳ công nghệ nào khác). Các thành phần thường có các lệnh gọi API REST không đồng bộ, khi khởi tạo hoặc khi có sự tương tác của người dùng. Thiết kế này đang gây ra nhiều cuộc gọi API trên mỗi trang (đôi khi 20+). Có bất kỳ vấn đề với thiết kế này? Một số người đề nghị chúng tôi ngưng tụ các lệnh gọi API vào các dịch vụ phía máy khách lớn hơn hoạt động như các singletons. Vì vậy, 10 lệnh gọi API có thể giảm xuống còn 1, mặc dù một trang chỉ có thể sử dụng một phần dữ liệu đó. Có bất kỳ cờ đỏ, hoặc vấn đề với thiết kế này? Nên ưu tiên cái nào?

Trình duyệt giới hạn tổng số yêu cầu đồng thời

/programming/561046

Vì vậy, có, có một vấn đề với thiết kế này. Tuy nhiên, tôi nghĩ rằng phản hồi được chấp nhận là chuyển sang triển khai ổ cắm web nơi bạn sử dụng một kết nối duy nhất, nhưng có nhiều loại thông báo để liên lạc với máy chủ

Thiết kế này đang gây ra nhiều cuộc gọi API trên mỗi trang (đôi khi 20+). Có bất kỳ vấn đề với thiết kế này?

Không nên có. Thực tế là mỗi yêu cầu đều nhỏ và không đồng bộ có nghĩa là bạn có thể tăng tốc đáng kể cho ứng dụng web của mình, thay vì phải chờ một yêu cầu lớn duy nhất để hoàn thành việc chặn mọi thứ.

Chỉ cần đảm bảo javascript của bạn không chính xác và có thể thực hiện mọi việc trong khi các yêu cầu khác của bạn đang chờ và bạn sẽ kết thúc với một ứng dụng tốt hơn nhiều so với việc bạn có một yêu cầu lớn đã tìm nạp mọi thứ.

Sau khi tất cả các trình duyệt được thiết kế để xử lý tải nhiều URL cùng lúc, ngay cả một trang web tiêu chuẩn thông thường cũng có thể có hàng chục yêu cầu đối với hình ảnh, css, javascript, iframe, v.v.

Đừng quên kích thước của mỗi yêu cầu mạng. Nói chung, nếu mỗi yêu cầu chỉ trả về như 2 KB dữ liệu, thì yêu cầu mạng sẽ tốn kém cho lượng dữ liệu nhỏ đó.

Nếu yêu cầu mạng lên tới 400KB, sau đó chia thành hai. Nhưng nhìn chung, không đủ dữ liệu cho một yêu cầu mạng thường là vấn đề.

Một số cân nhắc ở đây:

Hiệu suất

Nếu bạn đang thấy hiệu suất chấp nhận được, bạn không nên lo lắng quá nhiều về nó. Nếu bạn có thể quản lý để chạy HTTP2, bạn sẽ thấy hiệu suất tăng. ^[1] .

Thiết kế

Như với bất kỳ thiết kế nào, không có quy tắc cứng nhanh nào về việc bạn nên thực hiện nhiều yêu cầu nhỏ hay vài yêu cầu lớn. Một số điều cần xem xét:

1. Có nhiều cuộc gọi phụ thuộc lẫn nhau? Nếu bạn có mối quan hệ phụ thuộc phức tạp giữa các cuộc gọi khác nhau, điều đó có thể khiến việc bảo trì khó khăn hơn. Nếu đây là trường hợp dữ liệu phản hồi liên quan đến lô sẽ có ý nghĩa.

2. Các thành phần khác nhau có chia sẻ nhiều dữ liệu giống nhau không? Nếu đây là trường hợp bạn có thể có một điểm trung tâm thực hiện các cuộc gọi được chia sẻ và cho phép các thành phần truy cập vào dữ liệu được chia sẻ.

3. Theo dõi gánh nặng bảo trì của các bộ phận nhỏ thực hiện các cuộc gọi riêng biệt. Bạn sẽ biết khi nào nó trở nên khó quản lý và sau đó một sự thay đổi có thể là cần thiết. Thay đổi một thiết kế dựa trên nhu cầu tương lai giả định có thể gây ra lỗi thiết kế, bởi vì bạn phải dự đoán chính xác những vấn đề bạn sẽ gặp phải trong tương lai. Nếu bây giờ nó hoạt động tốt, việc thay đổi nó cũng sẽ không cần thiết.

1: "HTTP / 2 được ghép hoàn toàn cho phép nhiều tệp và yêu cầu được truyền cùng một lúc, trái ngược với HTTP1.x chỉ chấp nhận một yêu cầu / kết nối duy nhất tại một thời điểm. HTTP / 2 sử dụng cùng một kết nối để chuyển khác nhau các tệp và yêu cầu, tránh hoạt động nặng nề khi mở kết nối mới cho mọi tệp cần được chuyển giữa máy khách và máy chủ. " - https://css-tricks.com/http2-real-world-performance-test-analysis/