Ba bài học kiến trúc từ một tuần trên DEV: event timing, xác thực Telegram Mini App và giá trị kinh nghiệm thời AI

Tuần này mình chọn ba bài từ DEV Community để bàn. Chúng nằm ở ba tầng rất khác nhau — một bài về thứ tự mount của UI, một bài về xác thực phiên đăng nhập, một bài về triết lý làm việc với AI — nhưng chúng có một điểm chung: đều nói về những quyết định kiến trúc nhỏ mà nếu chọn sai, hậu quả chỉ hiện ra khi hệ thống đã chạy thật.

1. Widget hỗ trợ mở bằng window event — khi event bắn trước khi component tồn tại

Bài của Daniel Pertu trên CogniPrep mô tả một vấn đề tưởng đơn giản: có một dòng chữ dưới danh sách game, khi nhấn vào thì phải mở panel hỗ trợ, sẵn sàng ở form ticket, với danh mục đã chọn trước là "game không khớp với bài test thật". Câu trả lời React chuẩn textbook là lift state lên một context, provide phía trên cả hai component, rồi consume ở nút bấm. Nhưng team này không làm vậy, và lý do đáng quan tâm hơn cơ chế.

Điểm hay nhất của bài: widget hỗ trợ được mở thông qua một window event, và event đó có thể fire trước khi widget tồn tại. Đây là bài toán kinh điển về thứ tự khởi tạo trong hệ thống phân mảnh — khi publisher và subscriber không nằm cùng một cây render, cùng một chunk code, hoặc cùng một thời điểm mount.

Theo góc nhìn kiến trúc, đây là trade-off giữa coupling tường minh (context, props) và decoupling qua event bus. Event-based giải phóng hai phần khỏi việc biết về nhau — tiện khi widget là script bên thứ ba hoặc lazy-loaded — nhưng đổi lại bạn mất compile-time guarantee và phải tự xử lý mọi race condition ở runtime. Ba cách xử lý phổ biến: queue event cho đến khi listener sẵn sàng (buffering), widget đăng ký listener sớm nhất có thể trong lifecycle, hoặc kiểm tra trạng thái trước khi dispatch.

Giá trị thực tiễn: nếu bạn đang tích hợp widget chat, analytics hay bất kỳ script độc lập nào, hãy tự hỏi ngay: "Điều gì xảy ra nếu user bấm trước khi script tải xong?" Thiết kế một contract rõ ràng — ví dụ event bus với buffer — ngay từ đầu rẻ hơn nhiều so với debug lỗi "bấm nút không có gì xảy ra, nhưng chỉ thỉnh thoảng". Race condition về timing là loại bug khó tái hiện nhất, nên đừng để nó tồn tại bằng mặc định.

2. Đổi Telegram WebApp InitData lấy JWT đã xác thực — và cái bẫy user_id phía client

Bài thứ hai của Serhii đánh thẳng vào một lỗ hổng bảo mật mà mình thấy lặp lại gần như công thức trong các Telegram Mini App: developer đọc window.Telegram.WebApp.initDataUnsafe.user.id phía client rồi truyền thẳng user_id đó trong JSON payload hoặc GET parameter lên backend API.

Vấn đề không phải là Telegram không có cơ chế bảo vệ — nó có. initData (không phải bản Unsafe) chứa chữ ký HMAC mà chỉ bot token của bạn và Telegram mới tạo được. Lỗ hổng nằm ở kiến trúc: khi backend tin một con số do client tự khai báo, thì bất kỳ ai mở Chrome DevTools, xem network request và đổi user_id đều có thể truy cập tài khoản người khác. Với một hệ thống đặt chỗ bên trong, cửa hàng VIP hay desk chăm sóc khách hàng chạy trong Telegram, đây là take-over tài khoản toàn bộ.

Pattern đúng mà bài đề xuất cho stack React + PHP: client gửi nguyên initData có chữ ký lên server; server dùng bot token để xác thực chữ ký HMAC theo thuật toán Telegram quy định; chỉ sau khi验证 pass, server mới cấp một JWT có thời hạn cho các request sau. Nguyên tắc nền tảng là cũ như HTTP itself: client là miền không tin cậy. Mọi định danh, mọi phân quyền phải được server tự suy ra từ bằng chứng đã xác thực, không bao giờ nhận từ payload.

Giá trị thực tiễn: nếu bạn đang có một Mini App trong production, hãy mở network tab ngay và tìm xem có field nào tên user_id hay chat_id được client gửi lên không. Nếu có, đó là backlog ưu tiên cao nhất tuần này. Flow exchange InitData → JWT cũng áp dụng được cho bất kỳ nền tảng embedded nào khác có cơ chế ký tương tự (Zalo Mini App, Slack, v.v.).

3. Saving the soul of AI projects — kinh nghiệm có đang lỗi thời không?

Bài của Oscar Hedeby phản bác một sentiment phổ biến trên Twitter: rằng kiến thức tích lũy từ việc build các dự án quy mô lớn trước thời AI đang trở nên vô dụng. Ông cho rằng điều ngược lại mới đúng. AI giúp ông gánh được khối lượng công việc mà trước đây sẽ buộc phải bỏ dở giữa chừng — nhưng cái giá là nhiều dự án chỉ được finish về mặt hình thức, còn chất lượng bên trong phụ thuộc hoàn toàn vào người ra prompt có đủ nền tảng để đánh giá.

Đây là luận điểm kiến trúc mà mình đồng tình: AI khuếch đại năng lực thực thi, nhưng không tạo ra năng lực đánh giá. Một architect giàu kinh nghiệm dùng AI sẽ phát hiện sớm khi generated code vi phạm ranh giới module, tạo N+1 query, hay lặp state thừa. Người chưa từng ship hệ thống lớn sẽ nhận cùng một output và thấy "chạy được là xong". Khoảng cách đó không phải về tốc độ gõ code — mà về việc biết câu hỏi nào cần đặt và đáp án nào đáng nghi ngờ.

Giá trị thực tiễn: nếu bạn đang tăng tốc bằng AI, hãy giữ lại hai thói quen cũ: review kiến trúc trước khi viết code (vẽ sơ đồ, xác định ranh giới service và data flow), và code review nghiêm túc với output của AI như với một junior developer mới. Đừng để AI xóa nhằng ranh giới giữa "biết cách ra lệnh" và "hiểu hệ thống".

Bสรุป mở

Ba bài, ba tầng, một chủ đề chung: những gì không hiển thị trên UI là nơi hệ thống thật sống. Widget event là về thời gian, InitData là về ranh giới tin cậy, bài AI là về ranh giới năng lực. Nếu bạn muốn thử nghiệm tiếp, mình đề xuất hai hướng: đưa một event bus có buffering vào dự án có script bên thứ ba để loại bỏ race condition về timing, và nếu đang vận hành Mini App, viết một integration test chủ động giả mạo user_id trong payload để chứng minh backend từ chối nó. Rủi ro lớn nhất cần phòng tránh: tin rằng vì thứ gì đó "vẫn chạy" nên kiến trúc đã đúng — cả ba bài trên đều là minh chứng cho điều ngược lại.

Nguồn tham khảo

• Our support widget is opened by a window event, and the event can fire before the widget exists
• Exchange Telegram WebApp InitData for Validated JWTs in React and PHP
• Saving the soul of AI projects