Một bản hack Frontend mới đang thay đổi hiệu suất API theo hướng tốt hơn

Trước đây, tôi thường nhận thấy một cách tiếp cận chung là các nhà phát triển (bao gồm cả tôi) sử dụng cùng một API cho cả đọc và ghi trong mọi trường hợp. Thậm chí còn hơn thế nữa, chúng tôi thường dựa vào cùng một nguồn dữ liệu, chẳng hạn như MySQL/PostgreSQL, để xử lý cả hai hoạt động.

Điều này có nghĩa là ghi vào cùng một cột và đọc từ các cột đó, thường dẫn đến khó khăn trong việc tối ưu hóa chỉ mục trên các trường có nhiều truy vấn.

Ví dụ, chúng ta sẽ thấy mình thường xuyên phải điều chỉnh các chỉ mục để phù hợp với các bộ lọc mới hoặc cải thiện hiệu suất truy vấn và các trường được sử dụng với các toán tử như LIKE đặt ra những thách thức cụ thể do tác động của chúng đến hiệu suất.

Những thay đổi này thường dẫn đến những điều chỉnh sâu hơn ở phần phụ trợ, bao gồm sửa đổi API để đưa ra chức năng được cập nhật, đo thời gian do có thêm JOIN, v.v.

Để giải quyết thách thức về việc thêm bộ lọc và nội dung mới vào API, đã có những nỗ lực nhằm tối ưu hóa quy trình bằng các công cụ và tiêu chuẩn như Apicalypse và tất nhiên là GraphQL .

Các giải pháp này nhằm mục đích hợp lý hóa việc tạo truy vấn API và giảm công sức thủ công cần thiết để triển khai các bộ lọc và chức năng mới, cung cấp phương pháp tiếp cận năng động hơn để xử lý quyền truy cập dữ liệu, nhưng chúng có đường cong học tập cao.

Với sự ra đời của CQRS (Command Query Responsibility Segregation), một cách tiếp cận mới bắt đầu xuất hiện. Tư duy này khuyến khích sử dụng các nguồn riêng biệt cho các lệnh ghi và đọc. Các lệnh ghi có thể phát ra các sự kiện và các lệnh đọc có thể xây dựng các chế độ xem từ các sự kiện đó ở những nơi chuyên dụng. Ngay cả khi các lệnh đọc và ghi được quản lý trong cùng một cơ sở dữ liệu (nhưng các bảng khác nhau), sự tách biệt này mang lại những lợi ích đáng kể và tất nhiên là có thể loại bỏ được thách thức thứ hai - JOIN và truy vấn tìm kiếm trên các mô hình miền, vì các mô hình đọc thường ở dạng JSON không chuẩn hóa.

Tuy nhiên, điều này lại nảy sinh một vấn đề khác. Với các lần đọc, chúng ta phải mở rộng quy mô ghi, nghĩa là lý do duy nhất khiến chúng ta phải mở rộng quy mô các phiên bản ứng dụng của mình từ X lên Y là do các lần đọc. Vấn đề này có thể được giảm nhẹ một phần bằng bộ nhớ đệm và trong thế giới của các dịch vụ siêu nhỏ, chúng ta có thể có các dịch vụ siêu nhỏ chuyên dụng cho các lần đọc.

Nhưng...

Tuy nhiên, đây không phải là giải pháp lý tưởng cho các phong cách kiến trúc khác như monolith mô-đun, nơi mà sự tách biệt như vậy có thể không phù hợp với triết lý thiết kế của hệ thống. Một điều nữa là khi API ngừng hoạt động, toàn bộ sản phẩm cũng ngừng hoạt động, và hãy nhớ rằng hầu hết các sản phẩm đều dựa vào nhiều lần đọc hơn là ghi, điều này có thể tác động không cần thiết đến hoạt động kinh doanh (Aparat từ API ngừng hoạt động tất nhiên ;) )

Vậy thì, nếu chúng ta có thể yêu cầu những "lượt xem" đó, còn được gọi là mô hình đọc, trực tiếp mà không cần API và xử lý tải thì sao? Đây là lúc các giải pháp như Meilisearch , AppSearch và các giải pháp khác phát huy tác dụng, tận dụng một mẫu được gọi là "Khóa Valet". Bằng cách sử dụng mẫu này, giao diện người dùng có thể truy cập trực tiếp vào các mô hình được tối ưu hóa để đọc, giảm sự phụ thuộc vào API phụ trợ. Tất nhiên, giao diện người dùng vẫn phải "hỏi" API về "Khóa Valet", nhưng giao diện người dùng có thể lưu trữ khóa đệm, do đó ngay cả khi API ngừng hoạt động, giao diện người dùng vẫn có thể giao tiếp và hiển thị nội dung.

Với cách tiếp cận này, chúng ta có thể tập trung vào cơ sở dữ liệu đọc và không phải lo lắng về việc xử lý lưu lượng truy cập cho các lần đọc trong API của chúng ta. "Khóa Valet" được cung cấp cho giao diện người dùng thông qua API của chúng ta được bảo mật theo cách mà giao diện người dùng không thể thay đổi được. Nó bao gồm các bộ lọc và chỉ mục được xác định trước.

Nếu frontend yêu cầu các khả năng bổ sung, nó có thể yêu cầu chúng thông qua API, tại đó API có thể xác thực xem có cho phép chúng hay không. Vẫn ít cuộc gọi hơn.

Một số ưu điểm tôi có thể thấy là:

• Giảm tải API : Giảm tải lưu lượng đọc khỏi API, cho phép API tập trung vào các hoạt động cốt lõi.
• Khả năng mở rộng : Cơ sở dữ liệu đọc hoặc dịch vụ tìm kiếm được tối ưu hóa tốt hơn để xử lý lưu lượng truy cập cao, giảm nhu cầu mở rộng ứng dụng.
• Tính linh hoạt : Các tùy chọn SaaS hoặc tự lưu trữ cho phép các nhóm lựa chọn giải pháp phù hợp nhất với cơ sở hạ tầng của họ.
• Bảo mật : Các bộ lọc và chỉ mục được xác định trước đảm bảo giao diện người dùng chỉ có thể truy cập dữ liệu được phép, giảm thiểu rủi ro. Khóa có thể bị vô hiệu hóa bởi API.
• Hiệu quả của nhà phát triển : Giảm nhu cầu cập nhật API liên tục cho các bộ lọc hoặc khả năng tìm kiếm mới.
• Hiệu suất được cải thiện : Truy cập trực tiếp vào các mô hình được tối ưu hóa để đọc giúp người dùng phản hồi truy vấn nhanh hơn.

Nhưng luôn có nhược điểm:

• Tính nhất quán cuối cùng : Dữ liệu có thể xuất hiện sau một thời gian do bản chất của tính nhất quán cuối cùng trong các mô hình đọc.
• Bảo trì bổ sung: Giới thiệu một thành phần bổ sung cần được giám sát và quản lý.
• Độ phức tạp của lược đồ : Các lược đồ phải được lưu trữ trong mã hoặc một nơi chung, vì các nhóm khác nhau từ các bối cảnh khác nhau có thể cần điền vào cùng một tài liệu (ví dụ: nhân viên có email, nhưng cũng có tín dụng và phiếu giảm giá khả dụng). Mặc dù không liên quan trực tiếp đến mẫu này, nhưng nó làm tăng thêm độ phức tạp.
• Chi phí cho phiên bản SaaS hoặc bảo trì tự lưu trữ

Vì vậy, cách tiếp cận này không phải là giải pháp hoàn hảo và cũng có những thách thức riêng, nhưng nếu bạn chấp nhận được nhược điểm thì một thay đổi nhỏ ở giao diện người dùng có thể không cần sự tham gia của nhóm phụ trợ, giúp hợp lý hóa quy trình phát triển và cải thiện tính linh hoạt tổng thể, và tất nhiên khả năng mở rộng cũng sẽ dễ dàng hơn.