Hội nhập ecosystem qua interface có sẵn

Khi xây một tool hoặc thư viện mới, có hai con đường để được adopt: tự dựng API riêng và thuyết phục người dùng học, hoặc tuân thủ một interface chuẩn đã có để plug-in vào ecosystem trưởng thành. Hướng thứ hai gần như luôn cho lợi ích lớn hơn trong giai đoạn đầu — vì tool mới được hưởng miễn phí toàn bộ tooling, monitoring, documentation, và cộng đồng đã tích luỹ quanh interface đó. Cái phải trả: bị ràng buộc bởi interface, phải maintain compatibility khi spec thay đổi.

Vì sao bám interface có sẵn lợi hơn dựng riêng

Mỗi interface chuẩn trưởng thành kèm sẵn một “infrastructure tax đã trả hộ”:

Tooling: deploy script, process manager, monitoring exporter, debugger adapter đã có cho interface đó
Documentation: người dùng đã biết cách dùng interface, không phải đọc doc mới từ đầu
Bug discovery: edge case của interface đã được người dùng khác phát hiện và fix
Composability: tool của bạn ghép được với mọi tool khác cùng tuân thủ interface

Triết lý này song song với Unix Philosophy (“write programs to work together” qua interface text stream) và quan điểm “Convention over Configuration” của Rails — đều chia sẻ một lõi: standard interface là tài sản chung, người mới nên consume nó thay vì redo.

Dẫn chứng từ uasgi

uasgi (xây 2025-07 tại Zen8labs) là một dẫn chứng cá nhân của triết lý này. Hai interface có sẵn được uasgi bám vào:

ASGI spec — tuân thủ scope/receive/send protocol nên mọi framework ASGI (Starlette, FastAPI, Django ASGI, Quart) chạy được trên uasgi mà không sửa một dòng nào. Nếu uasgi tự định nghĩa API riêng, sẽ phải đợi hoặc tự viết adapter cho từng framework.
Gunicorn worker interface — uasgi cung cấp UASGIWorker class tương thích worker spec của Gunicorn, nên uasgi chạy được bên trong Gunicorn (gunicorn main:app --worker-class uasgi.UASGIWorker.UASGIWorker). Hệ quả: uasgi tự động kế thừa toàn bộ tính năng vận hành của Gunicorn — config file, signal handling, graceful reload, logging integration, prometheus exporter — mà không phải tự viết.

Hai bài học cụ thể từ uasgi:

Interface chuẩn hoá trước (ASGI) và interface trưởng thành nhưng không chuẩn (Gunicorn worker là de facto) đều đáng bám. Bám de facto rủi ro hơn vì có thể đổi, nhưng vẫn lợi hơn dựng riêng.
Bám interface không có nghĩa là không sáng tạo bên trong. uasgi vẫn tự viết arbiter, worker, parser tích hợp httptools, lifespan — cái mới nằm ở implementation; bám interface chỉ là chiến lược go-to-market.

Khi nào không bám interface có sẵn

Triết lý này có giới hạn. Không bám khi:

interface đã lỗi thời rõ rệt và bạn đang pioneer pattern mới (CGI → WSGI → ASGI là chuỗi như vậy)
ecosystem đích không phải mục tiêu — vd library research không cần adopt rộng
chi phí compat layer vượt lợi ích (interface phức tạp hoặc thay đổi liên tục)
interface kéo theo ràng buộc không chấp nhận được (ví dụ blocking I/O cho synchronous spec)

Heuristic: nếu interface có nhiều người dùng và thay đổi chậm, bám; nếu nó là một thiết kế dở mà ecosystem đang chờ thay thế, đó là cơ hội pioneer.

Hội nhập ecosystem qua interface có sẵn

Vì sao bám interface có sẵn lợi hơn dựng riêng

Dẫn chứng từ uasgi

Khi nào không bám interface có sẵn

Nguồn tham khảo

Liên kết tri thức

Tags