Giải pháp của sếp khi 3rd party API giới hạn lượng requests

08 - 04 - 2023

Gần đây khi làm dự án cho khách, tôi gặp phải vấn đề sau:

Vấn đề

Web app của khách xây dựng dựa trên một bên thứ 3 (3rd party) API, nhưng API đó giới hạn số lượng request trong một giây.
Performance của web app cũng không được tốt.
Khách hàng là start-up không có nhiều tiền.
Hệ thống vẫn cần scale lên cho số lượng người dùng nhiều hơn 3rd party API cho phép.


Kết nối trực tiếp với web app và gặp phải vấn đề giới hạn request

Giải pháp đề xuất

Sau khi bàn bạc với đồng nghiệp, chúng tôi đề xuất giải pháp sau với sếp:

Tạo một server riêng để làm proxy giữa web app và 3rd party API.
Server proxy sẽ download dữ liệu từ 3rd party API và lưu lại trong database do chúng tôi quản lý.
Web app sẽ gọi đến server proxy để lấy dữ liệu.
Cron job sẽ định kỳ update dữ liệu từ 3rd party API vào database.

Pros

Giải quyết được rate limit của 3rd party API.
Không cần phải sửa đổi code của web app.
Có thể scale server và database theo nhu cầu.

Cons

Giải pháp tương đối phức tạp vì phải kiến trúc database
Cron job có thể timeout gây mất dữ liệu
Chí phí khi scale database
Độ phức tạp của kiến trúc khiến nhu cầu sử dụng Developer cao hơn đồng nghĩa với chi phí cho Developer cũng cao.


Web app kết nối trung gian qua server dùng MongoDB để lưu dữ liệu và CronJob để đồng bộ

Giải pháp từ sếp

Sau đó chúng tôi họp với sếp và nhận được giải pháp sau:

Để giải quyết việc đồng bộ dữ liệu từ 3rd party API, sếp đề xuất sử dụng webhook từ phía server của chúng tôi và yêu cầu admin của khách hàng trigger webhook khi thay đổi dữ liệu. Trong trường hợp nhiều record thay đổi, admin có thể nhờ dev chúng tôi cập nhật.
Lưu trữ dữ liệu không cần thiết mà chúng tôi sẽ sử dụng SSG để gọi dữ liệu lúc build và nhờ Vercel để cache và deploy các trang web tĩnh này.
Webhook sau khi được admin cập nhật sẽ thực hiện build lại trang web tĩnh dần dần ISR (Incremental Static Regeneration) để tránh tình trạng dữ liệu bị hết hạn.

Pros

Giải quyết được rate limit của 3rd party API.
Performance tốt!
Bớt đi chi phí database và chi phí dev.
Không quá phức tạp đòi hỏi sửa code nhiều.
Đưa admin vào như là một phần của giải pháp.

Cons

Phụ thuộc vào NextJS và Vercel để scale lên. Tiềm tàng chi phí cao
Các trang web tĩnh hoàn toàn có thể bị quá đát hoặc không cập nhật kịp theo tương tác của người dùng. Nếu người dùng viết nhiều dữ liệu thì việc đồng bộ giữa database của chúng tôi (MongoDB) và 3rd party API vẫn sẽ khó khăn và phức tạp.
Thời gian build lại trang web lâu và sẽ càng tăng khi lượng content trên hệ thống tăng.


Web app sử dụng NextJS Vercel SSG (Static Site Generator) and ISR (Incremental Static Regeneration)

Kết luận

Cuối cùng tôi lựa chọn phương áp của sếp nhờ chi phí thấp và đơn giản, rất phù hợp với startup. Tuy nhiên cần chú ý rằng phương pháp này ẩn chứa những vấn đề được nêu ra ở trên. Một điều đáng chú ý là với phương án ban đầu, sau khi bàn bạc tôi không thể thoát ra được cách nghĩ đó và không thể tìm ra một giải pháp khác. Thật thú vị là sếp tôi đã có thể tìm ra một giải pháp phù hợp hơn mà tôi không thể tìm ra ngay cả khi biết về SSG và ISR. (Blog này được viết theo SSG và host trên Vercel).