Nhiều yêu cầu nhỏ so với vài yêu cầu lớn (Thiết kế API)

Tôi hiện đang làm việc trên một dự án với một tổ chức như sau:

• Máy khách - Nhận dữ liệu từ máy chủ chính qua REST api.
• Máy chủ - Yêu cầu dữ liệu từ nhiều máy chủ khác thông qua API của bên thứ ba
• API của bên thứ ba - Các dịch vụ ngoài tầm kiểm soát của tôi cung cấp dữ liệu cho máy chủ (Reddit, Hackernews, Quora, v.v.)

Để tranh luận, giả sử khách hàng trước tiên cần một danh sách các mục từ mỗi API của bên thứ ba. Từ danh sách này, một mục sẽ được chọn tại điểm mà khách hàng cần để xem toàn bộ nội dung của mục cũng như phản hồi (tức là nhận xét) cho mục đó. Tôi đang cố gắng quyết định giữa ba lựa chọn:

A la Carte

Trong phương pháp này, tôi sẽ có 3 điểm cuối riêng biệt trên máy chủ của mình: một để lấy danh sách các mục, một để lấy nội dung chính cho một mục và một để nhận phản hồi của mục đó.

• Ưu điểm: Tôi không bao giờ thực hiện nhiều yêu cầu hơn tôi cần, các yêu cầu nên nhỏ nên thường chúng sẽ nhanh hơn.
• Nhược điểm: Tôi phải thực hiện rất nhiều yêu cầu. Sau khi chọn một mục từ danh sách, người dùng có thể phải đợi trước khi xem nội dung chính và sau đó đợi lâu hơn để xem phản hồi

Bộ đệm phía máy chủ

Trong yêu cầu này, tôi sẽ thực hiện một cuộc gọi đến máy chủ của mình để "tìm nạp" tất cả dữ liệu cho tất cả các nguồn. Dữ liệu sau đó sẽ được lưu trữ trên máy chủ. Sau đó, máy khách sẽ có các điểm cuối REST giống như trước đây, ngoại trừ sẽ không có nhiều sự chờ đợi giữa các cuộc gọi vì máy chủ của tôi đã có dữ liệu và chỉ phải cung cấp dữ liệu đó cho máy khách.

• Ưu điểm: Vẫn dễ thực hiện ở phía máy khách, nhưng không có vấn đề về độ trễ
• Nhược điểm: Phía máy chủ liên quan nhiều hơn một chút và cuộc gọi đầu tiên có thể thực sự mất nhiều thời gian.

Bộ nhớ cache phía máy khách

Kịch bản này tương tự như kịch bản trước trừ khách hàng chỉ thực hiện một yêu cầu đến máy chủ: cung cấp cho tôi tất cả dữ liệu. Từ đây, trách nhiệm của khách hàng là lưu dữ liệu và sử dụng nó một cách thích hợp.

• Ưu điểm: Triển khai máy chủ dễ dàng, rất nhanh sau cuộc gọi đầu tiên
• Nhược điểm: Cuộc gọi đầu tiên sẽ rất chậm, triển khai phía khách hàng phức tạp hơn

Tôi không chắc đó là cách tiếp cận tốt nhất, hoặc nếu có thể tôi đang thiếu giải pháp rõ ràng. Bất kỳ lời khuyên sẽ được đánh giá rất cao!

Một điều cần lưu ý là độ trễ mạng dự kiến ​​(tức là thời gian ping) giữa máy khách và máy chủ của bạn. Trong tình huống có độ trễ cao với băng thông tốt, nhiều yêu cầu nhỏ sẽ thực hiện kém hơn đáng kể so với yêu cầu lớn.

Gần đây tôi đã hợp tác trong một dự án ứng dụng web dựa trên cơ sở dữ liệu nhiều nhóm trong đó một trong số các đội ở Ấn Độ (phần còn lại ở Hoa Kỳ). Chúng tôi có một phiên bản cơ sở dữ liệu duy nhất được lưu trữ trong văn phòng tại Hoa Kỳ nơi các nhà phát triển kết nối các phiên bản máy chủ web cục bộ của chúng tôi. Bàn của tôi có thể cách năm mươi feet và hai bước LAN từ cơ sở dữ liệu và hiệu suất vẫn ổn.

Khi chúng tôi lần đầu tiên bắt đầu với các nhà phát triển ở Ấn Độ, họ đã trải qua thời gian chờ đợi rất lớn để bắt đầu ứng dụng và điều hướng từ trang này sang trang khác. Chúng tôi đang nói chuyện thời gian chờ đợi mười phút ở đây. Hóa ra điều này là do thời gian ping ~ 200ms từ bàn của họ đến máy chủ cơ sở dữ liệu dev của chúng tôi đã được nhân lên bởi nhiều, rất nhiều truy vấn ngắn đến cơ sở dữ liệu. Ping 0,5ms cục bộ của tôi rất tầm thường đến nỗi độ chói giữa máy chủ web và máy chủ cơ sở dữ liệu không bao giờ quan trọng. Đây là lần đầu tiên chúng tôi có sự tách biệt về địa lý giữa máy chủ web và máy chủ cơ sở dữ liệu.

Giải pháp trong trường hợp của chúng tôi là sao chép máy chủ cơ sở dữ liệu và sao chép ở Ấn Độ, nhưng vấn đề ở đây là hãy nhớ rằng nếu máy khách và máy chủ của bạn cách xa nhau, độ trễ mạng sẽ được nhân với số lượng truyền thông qua dây điện. Băng thông một khi kết nối được thiết lập thường ít đáng quan tâm hơn.

Ba tùy chọn này không loại trừ lẫn nhau, bạn có thể sử dụng kết hợp cả bộ đệm phía máy khách và bộ đệm phía máy chủ. Tuy nhiên, một số dữ liệu, như nhận xét, có thể trở nên cũ, nếu được giữ trong bộ đệm quá lâu. Xem xét bạn không thể kiểm tra xem đó có phải là trường hợp không, có lẽ bạn không nên lưu trữ nó. Mặt khác, nội dung thường không thay đổi mạnh mẽ, do đó, sẽ không có hại trong việc lưu trữ phía máy chủ và sau đó tìm nạp trước một số nội dung ở phía máy khách để giảm độ trễ.

Chỉ dựa trên thông tin bạn đã cung cấp, tùy chọn 1, bởi vì

• với một yêu cầu khách hàng, bạn sẽ trộn táo và cam và giỏ trái cây có thể rất lớn.

• bộ nhớ đệm là một sự đánh đổi trong đó bạn đạt được hiệu suất nhưng có khả năng mất tính nhất quán (dữ liệu cũ). Nếu bạn không có bất kỳ vấn đề hiệu suất nào được xác định, các sự cố đồng bộ hóa thường không đáng để mạo hiểm.

Tôi luôn tìm thấy một vài yêu cầu lớn để hoạt động tốt hơn và có khả năng mở rộng hơn. Nhưng có sự đánh đổi trong tất cả các phương pháp, vì vậy nó phụ thuộc vào nhu cầu của máy chủ và máy khách. Bạn có thể muốn sử dụng một tùy chọn khác, đó là yêu cầu khách hàng chỉ định toàn bộ phạm vi hoặc bộ dữ liệu cần truy xuất - không nhất thiết là tất cả dữ liệu, nhưng một số phạm vi, được điều chỉnh theo thời gian để phù hợp với băng thông có sẵn.

Tôi sẽ (gần như) tùy chọn giảm giá 3. Lựa chọn giữa 1 và 2 phụ thuộc vào hai điều:

• (A) kết quả của một lần tìm nạp, tổng số là bao nhiêu
• (B) bao nhiêu chi tiết của kết quả mà khách hàng / người dùng thường sẽ sử dụng trong phiên đó.

Thật dễ dàng để đưa ra quyết định nếu A và B là cực trị:

• Nếu A lớn và B nhỏ, chắc chắn chọn tùy chọn 1 (A la Carte).
• Nếu A nhỏ và B lớn, hãy chọn 2 (Bộ đệm phía máy chủ) hoặc thậm chí 3 (Bộ đệm phía máy khách).

Đối với bất kỳ biến thể A / B (lớn / nhỏ) nào khác, bạn sẽ phải áp dụng theo quyết định. Tôi thường cung cấp cả hai điểm cuối thô và tốt để phục vụ cho các trường hợp sử dụng khác nhau từ các khách hàng khác nhau.

Như mọi khi trong lập trình, nó phụ thuộc.

Vì vậy, câu hỏi thực sự là: bạn nên cân nhắc điều gì khi quyết định A / B / C hoặc kết hợp cả ba?

Tôi muốn nói rằng các yếu tố phân biệt đối xử thực sự là chi tiết triển khai của API bên thứ 3 mà bạn đang tiêu thụ. Ví dụ, bạn nên xem xét: Chúng nhanh hay chậm? Dữ liệu thay đổi thường xuyên và bất ngờ? Họ "trò chuyện" hay nghỉ ngơi?

Trong trường hợp dịch vụ gọi nhanh, dễ dàng, với việc thay đổi dữ liệu thường xuyên đến mức bộ nhớ cache phía máy chủ của bạn sẽ tạo ra các vấn đề cũ về bộ đệm, hãy chọn tùy chọn 1: thêm yêu cầu, không cần bộ đệm, chỉ khi cần.

Nếu dữ liệu ngoài của bạn sẽ thay đổi theo cách có thể dự đoán được hoặc bạn bị hạn chế về cách sử dụng hoặc đơn giản là bạn có thể có được trải nghiệm lưu trữ dữ liệu người dùng tốt hơn trên máy chủ của mình, hãy đi với 2. Nhưng hãy nhớ rằng bộ đệm không miễn phí: nó có chi phí về mặt gỡ lỗi và đôi khi người dùng phàn nàn rằng họ không thấy các bản cập nhật.

Tùy chọn 3, tôi sẽ chỉ xem xét nếu dữ liệu không nhiều, nhưng trong trường hợp đó, ngay cả tùy chọn 1 hoặc 2 cũng có thể hoạt động và bạn giữ logic hơn trên máy chủ, vì vậy tôi sẽ giữ nguyên 1 hoặc 2.

Chỉ cần 2c của tôi.