Một hệ thống thông báo cho web app tốt không chỉ là quả chuông trên giao diện. Nó là một chuỗi: có sự kiện xảy ra, thông báo được lưu vào cơ sở dữ liệu, hệ thống xác định đúng người nhận, rồi giao diện hiện số chưa đọc và đưa người dùng tới đúng nội dung. Tôi là Lê Minh Công, và bài này giải thích lại, theo cách dễ hiểu cho chủ doanh nghiệp và nhân viên văn phòng, những gì tôi chia sẻ trong video về chủ đề này.
Nguồn: video Seri Vibe Coding: Cách xây dựng hệ thống thông báo Real-time cho WebApp của kênh Nghiện AppSheet.
Hệ thống thông báo cho web app gồm những phần nào?
Gồm năm phần: nơi lưu thông báo, quy tắc sinh thông báo, quy tắc chọn người nhận, trạng thái đã đọc/chưa đọc, và giao diện hiển thị. Thiếu một phần là hệ thống sẽ "có chuông mà không ai tin".
- Nơi lưu: mỗi thông báo là một dòng trong database, không chỉ là một cái popup hiện rồi mất.
- Quy tắc sinh thông báo: hành động nào của người dùng thì tạo thông báo (thêm, sửa, xoá, đổi trạng thái, duyệt, từ chối).
- Người nhận: ai là người gửi, ai cần biết.
- Trạng thái: đã đọc hay chưa, để đếm số trên biểu tượng chuông.
- Giao diện: chuông, danh sách, và bấm vào là tới đúng phiếu liên quan.
Đây cũng là danh sách nội dung chính của video. Phần dưới tôi đi từng phần, kèm ví dụ cho doanh nghiệp Việt.
Thông báo nên được thiết kế dữ liệu thế nào?
Nên có một bảng riêng cho thông báo, mỗi dòng gắn với một người nhận cụ thể. Cách làm này giúp đếm chưa đọc nhanh và đánh dấu đã đọc cho từng người độc lập. Nếu bạn mới làm quen với việc chia bảng, hãy xem thêm bài thiết kế cơ sở dữ liệu cho người mới.
Dưới đây là một thiết kế minh hoạ do tôi đề xuất để bạn hình dung (không phải cấu trúc bắt buộc, và tên cột bạn có thể đổi):
| Cột | Ý nghĩa | Ví dụ |
|---|---|---|
recipient_id | Người nhận thông báo | Kế toán trưởng |
sender_id | Người gây ra sự kiện | Thủ kho |
type | Loại thông báo | Phiếu bị từ chối |
title, body | Nội dung hiển thị | "Phiếu xuất kho cần duyệt" |
link | Đường dẫn tới nội dung liên quan | Trang chi tiết phiếu |
is_read | Đã đọc chưa | Chưa |
created_at | Thời điểm tạo | Ngày giờ phát sinh |
Làm sao để thông báo được tạo ra và gửi đúng người?
Hãy để phía máy chủ (backend) tạo thông báo ngay khi hành động được lưu thành công, rồi tra quy tắc để biết ai là người nhận. Đừng để giao diện tự quyết định, vì như vậy dễ sót và dễ bị gửi trùng.
Ví dụ minh hoạ: một công ty phân phối nhỏ dùng web app để quản lý kho. Thủ kho tạo phiếu xuất. Hệ thống ghi phiếu, rồi tạo thông báo cho kế toán trưởng (người duyệt). Khi kế toán trưởng từ chối, hệ thống tạo thông báo ngược lại cho thủ kho, kèm lý do. Người gửi và người nhận được xác định theo vai trò trong quy trình duyệt, không phải gửi cho cả công ty.
Trong video tôi nói về một nguồn thông báo rất tiện: nhật ký hoạt động (log). Mỗi module đã có phần log ghi "ai đổi gì, ở đâu, khi nào". Vì vậy, thay vì viết riêng từng thông báo, bạn có thể bảo AI xây dựng để từ log sinh thông báo: ai vừa tạo mới, ai vừa đổi trạng thái từ gì sang gì, và báo cho người cần biết. Các loại tôi đang dùng trong app của mình gồm:
- Thêm, sửa, xoá bản ghi.
- Đổi trạng thái trong quy trình duyệt, phiếu bị từ chối.
- Có người trả lời bình luận của bạn.
- Đăng nhập từ thiết bị mới.
- Thông báo định kỳ, ví dụ mỗi sáng báo có bao nhiêu việc quá hạn cần xử lý.
- Cảnh báo hệ thống, ví dụ lịch đồng bộ với Google Sheet bị dừng.
Có những cách nào để gửi thông báo cho web app?
Có ba nhóm chính: dùng dịch vụ có sẵn (như OneSignal, Firebase Cloud Messaging), gửi qua kênh chat/email (Telegram, Zalo ZNS, email), hoặc tự làm trên VPS của mình. Mỗi cách có ưu nhược điểm riêng, và không có cách nào đúng cho mọi trường hợp.
| Cách | Ưu điểm | Nhược điểm | Hợp khi |
|---|---|---|---|
| OneSignal | Có gói miễn phí để thử, cấu hình sẵn | Gói trả phí tính bằng đô, giới hạn theo gói; phụ thuộc bên thứ ba | Cần thử nhanh, số người dùng ít |
| Firebase Cloud Messaging (Google) | Nằm trong hệ Firebase, có cả database và hosting | Tính phí khi vượt gói miễn phí; không phải cơ sở dữ liệu SQL; tôi thấy tốc độ cải tiến của Google chậm | Đã dùng sẵn hệ Firebase |
| Telegram, email, Zalo ZNS | Telegram miễn phí, dễ gắn vào quy trình tự động | Telegram thường không phải ai cũng mở đọc, gửi riêng từng người; Zalo ZNS và email có thể tốn phí | Báo nhóm nhỏ, báo động khẩn cho quản lý |
| Tự làm trên VPS | Không phụ thuộc gói, chủ động nghiệp vụ (gửi theo thêm/sửa/xoá, hẹn giờ, báo về web và mobile) | Phải tự thuê và vận hành máy chủ | Web app dùng lâu dài, nhiều module |
Về giá và hạn mức miễn phí của OneSignal hay Firebase, trong video tôi chỉ đọc nhanh từ câu trả lời của AI và các con số đó có thể đã đổi. Bạn nên xem trang giá chính thức của từng bên trước khi quyết định, đừng lấy con số trong video làm căn cứ.
Khi nào nên làm thông báo, khi nào nên bỏ qua?
Khi app còn đang chạy thử hoặc mới làm vài module nhỏ (ví dụ chỉ có module kho), hãy tạm bỏ qua thông báo. Đây là lời khuyên thẳng của tôi trong video: lúc đó còn hàng nghìn việc quan trọng hơn như giao diện, bảo mật, quy trình và phương án mở rộng. Cứ nói với người dùng là tính năng này chưa có.
Khi đã đến giai đoạn cần thông báo, tôi khuyên thuê hẳn VPS, chuyển database lên đó và làm thông báo luôn ở đấy. Lý do: các dịch vụ miễn phí có nhiều giới hạn, chi phí tăng khi bắn nhiều, và nếu phải đổi sang sau này thì bạn lại mất công cài đặt lại. Với app rất nhỏ (cỡ 2 GB RAM), trong video tôi ước tính khoảng 1 đến 1,5 triệu đồng một năm. Nếu chạy nhiều hệ thống, thêm N8N hay AI agent, nên cân nhắc 4 GB, 8 GB hoặc hơn. Đây là ước tính theo kinh nghiệm cá nhân; giá thực tế tuỳ nhà cung cấp, bạn hãy xem kinh nghiệm chọn VPS và cách chọn cấu hình VPS cho người mới để so sánh.
Một lưu ý công bằng: nếu app của bạn chạy chủ yếu trên AppSheet, bạn đã có sẵn Automation (Bot) để gửi email hoặc thông báo. Với nhu cầu đơn giản, dùng cái có sẵn là hợp lý hơn việc tự dựng cả hệ thống. Việc tự làm trên VPS chỉ đáng khi bạn cần một trung tâm thông báo trong app như quả chuông, đếm chưa đọc, tuỳ chọn riêng từng người.
Quả chuông, số chưa đọc và real-time hoạt động thế nào?
Số trên quả chuông chỉ là kết quả đếm các dòng thông báo của người đó có is_read là chưa đọc. "Real-time" nghĩa là khi có thông báo mới, giao diện tự cập nhật số đó mà người dùng không phải tải lại trang.
- Sự kiện xảy ra, backend lưu thông báo vào bảng.
- Backend báo cho trình duyệt của đúng người nhận đang mở app.
- Giao diện tăng số trên chuông và đưa thông báo mới lên đầu danh sách.
- Người dùng bấm vào, hệ thống đánh dấu đã đọc và chuyển tới đúng phiếu theo cột
link.
Bước điều hướng hay bị bỏ quên, nhưng với nhân viên văn phòng nó quyết định việc họ dùng hay bỏ thông báo. Thông báo "có phiếu cần duyệt" mà bấm vào chỉ ra trang chủ thì chẳng khác gì tin nhắn nhóm.
Làm sao tránh thông báo trùng và quá nhiều?
Hãy giới hạn ở hai tầng: tầng hệ thống (không tạo trùng, gộp thông báo cùng loại) và tầng người dùng (cho họ tự chọn loại muốn nhận). Thông báo quá nhiều là nguyên nhân chính khiến mọi người tắt hẳn.
Trong app của tôi, người dùng tự chỉnh được các phần sau:
- Bật hoặc tắt thông báo trên từng thiết bị, và xem tài khoản đang đăng nhập trên mấy thiết bị.
- Giờ yên lặng: ví dụ từ 21:00 đến 6:00 sáng không báo, sau giờ đó mới báo bù.
- Bật tắt theo từng module.
- Mức độ: có thông báo nhưng im lặng, báo không rung, hoặc khẩn. Ví dụ đăng nhập từ thiết bị mới tôi để mức khẩn.
- Tắt toàn bộ thông báo đẩy.
Về phía hệ thống, một vài nguyên tắc tôi áp dụng: một hành động chỉ sinh thông báo ở một nơi duy nhất; không báo cho chính người vừa thực hiện hành động; và các việc lặp (như việc quá hạn) nên gom thành một bản tin định kỳ thay vì báo từng việc.
Thiết kế thế nào để hệ thống dễ mở rộng?
Hãy tách "loại thông báo" thành cấu hình, thay vì viết cứng trong code từng module. Khi thêm module mới (ví dụ bán hàng sau kho), bạn chỉ khai thêm loại thông báo và quy tắc người nhận, không phải làm lại cơ chế chuông, đếm và đánh dấu đã đọc.
Điều này cũng khớp với cách làm vibe coding: bạn mô tả rõ quy tắc cho AI (ai nhận, khi nào, mức độ nào), rồi để AI viết phần code. Nếu bạn chưa quen hướng này, đọc vibe coding là gì trước. Phần phân quyền cũng ảnh hưởng trực tiếp tới việc ai được thấy thông báo nào; tôi sẽ có video riêng về chủ đề đó.
Tóm tắt và bước tiếp theo
- Thông báo là một bảng dữ liệu có người nhận, trạng thái đã đọc và đường dẫn, không phải một popup.
- Để backend tạo thông báo và xác định người nhận; log hoạt động là nguồn sinh thông báo rất tiện.
- Ba cách phổ biến: dịch vụ có sẵn, kênh chat/email, hoặc tự làm trên VPS. Hãy cân nhắc chi phí và công vận hành.
- Giai đoạn app còn thử nghiệm: chưa cần thông báo. Khi cần, chuyển lên VPS để chủ động.
- Cho người dùng tự chỉnh: thiết bị, giờ yên lặng, theo module, mức độ khẩn.
Việc bạn làm được ngay hôm nay: liệt kê 5 sự kiện trong quy trình của mình mà người khác bắt buộc phải biết (ví dụ phiếu cần duyệt, phiếu bị từ chối, việc quá hạn), ghi rõ ai là người nhận từng sự kiện. Chỉ cần xong bảng đó, bạn đã có phần khó nhất của đặc tả thông báo.
Nếu cần đội ngũ làm hoặc tư vấn báo giá cho hệ thống thông báo trong web app của bạn, có thể xem trang tư vấn và báo giá làm phần mềm.
Xem thêm
Câu hỏi thường gặp
›Hệ thống thông báo cho web app cần những thành phần nào?
Cần bảng lưu thông báo trong database, quy tắc tạo thông báo khi có sự kiện, quy tắc chọn người nhận, trạng thái đã đọc/chưa đọc và giao diện hiển thị chuông kèm đường dẫn tới nội dung liên quan. Thiếu một phần thì hệ thống khó dùng thật.
›Web app mới làm có cần làm thông báo ngay không?
Thường là chưa cần. Khi app đang chạy thử hoặc mới có vài module nhỏ, nên ưu tiên giao diện, bảo mật, quy trình và khả năng mở rộng. Có thể thông báo người dùng là tính năng này chưa có và làm sau.
›Nên dùng OneSignal, Firebase hay tự làm trên VPS?
OneSignal và Firebase Cloud Messaging phù hợp để thử nhanh hoặc khi đã dùng sẵn hệ đó, nhưng có giới hạn gói và chi phí khi tăng quy mô. Tự làm trên VPS cho bạn chủ động hơn nhưng phải vận hành máy chủ. Hãy kiểm tra giá chính thức trước khi chọn.
›Làm sao để người dùng không bị quá tải thông báo?
Hãy tránh tạo trùng, gộp các việc lặp thành bản tin định kỳ, và cho người dùng tự chọn: bật tắt theo thiết bị, theo module, đặt giờ yên lặng và chọn mức độ khẩn hay im lặng.
Tác giả
Chuyên gia chuyển đổi số · Đại diện 5F Edu
Hơn 8 năm triển khai và tư vấn chuyển đổi số cho doanh nghiệp vừa và nhỏ: chuẩn hoá quy trình, xây phần mềm quản lý bằng AppSheet và web app, tự động hoá bằng N8N. Người làm kênh YouTube Nghiện AppSheet.
