Cách thêm thông báo vào ứng dụng: Trong ứng dụng, Email và Push

Để thêm thông báo vào ứng dụng web, hãy bắt đầu với thông báo trong ứng dụng: một bảng thông báo trong cơ sở dữ liệu và biểu tượng chuông hiển thị các mục chưa đọc. Thêm email cho những điều người dùng cần biết khi họ không ở trong app, sử dụng một nhà cung cấp email, và chỉ thêm web push khi các cảnh báo kịp thời thực sự quan trọng, vì nó cần một service worker, sự cho phép của người dùng và, trên iPhone, ứng dụng phải được lưu vào màn hình chính. Dù dùng kênh nào, hãy tạo mọi thông báo ở một nơi duy nhất trên máy chủ và để người dùng chọn những thông báo họ muốn nhận.

Hướng dẫn này so sánh các kênh, trình bày một kiến trúc đơn giản và đưa ra các prompt bạn có thể dùng với một công cụ xây ứng dụng bằng AI.

So sánh các kênh chính

Hầu hết ứng dụng cần trong ứng dụng cộng với email. Push và SMS đáng dùng khi thời điểm thực sự quan trọng, như nhắc lịch đặt chỗ hoặc đơn hàng đã sẵn sàng.

Hệ thống thông báo hoạt động như thế nào

Hãy giữ nó đơn giản và tập trung:

1. Có một sự việc xảy ra. Một bình luận được đăng, một thanh toán thất bại, một lịch hẹn vào ngày mai.
2. Máy chủ của bạn gọi một hàm duy nhất, chẳng hạn notify(user, type, data).
3. Hàm đó kiểm tra tùy chọn của người dùng và ghi một dòng vào bảng notifications (cho chuông).
4. Sau đó gửi sang các kênh khác mà người dùng đã bật cho loại đó: email qua nhà cung cấp, push qua Push API.
5. Frontend hiển thị các thông báo chưa đọc và đánh dấu đã đọc khi được mở.

Chỉ một điểm vào duy nhất nghĩa là bạn có thể thêm kênh, đổi nội dung hoặc tôn trọng tùy chọn mà không phải lần tìm khắp codebase.

Cần lưu gì

Bảng thông báo thường cần: ID người dùng, loại (ví dụ comment_reply), tiêu đề và nội dung ngắn, liên kết đến trang liên quan, thời điểm tạo và thời điểm đọc. Một bảng tùy chọn riêng lưu những kênh mà mỗi người dùng muốn cho từng loại.

Hiển thị thông báo mới

• Tải khi xem trang và kiểm tra định kỳ mỗi 30–60 giây. Đơn giản và đáng tin cậy.
• Cập nhật thời gian thực bằng WebSockets hoặc server-sent events cho cảm giác tức thì nhưng thêm nhiều thành phần chuyển động. Hãy bắt đầu bằng polling trừ khi cập nhật tức thì thật sự quan trọng.

Thông báo qua email

Email cần một nhà cung cấp gửi thư và một tên miền đã được xác minh; chi tiết nằm trong cách gửi email từ ứng dụng. Riêng với thông báo:

• Gửi từ máy chủ, không bao giờ dùng khóa của nhà cung cấp trong trình duyệt.
• Gộp các sự kiện dồn dập. "3 bình luận mới" trong một email tốt hơn ba email.
• Cung cấp bản tóm tắt hằng ngày hoặc hằng tuần cho hoạt động có mức ưu tiên thấp.
• Đưa liên kết hủy đăng ký hoặc quản lý tùy chọn vào email không thiết yếu. Quy định về email tiếp thị khác nhau giữa các quốc gia; hãy kiểm tra điều gì áp dụng cho bạn.

Thông báo web push

Web push cho phép website của bạn gửi cảnh báo xuất hiện giống như thông báo ứng dụng. Theo tài liệu Push API của MDN, nó hoạt động như sau:

1. Website của bạn đăng ký một service worker, một đoạn script mà trình duyệt có thể chạy ở chế độ nền.
2. Sau khi người dùng đồng ý, service worker đăng ký qua PushManager.subscribe(). Trình duyệt trả về một subscription có endpoint và khóa mã hóa.
3. Máy chủ của bạn lưu subscription đó và, khi có sự việc, gửi tin nhắn đến endpoint, thường được ký bằng khóa VAPID (một cặp khóa xác định máy chủ của bạn).
4. Trình duyệt khởi động service worker của bạn, nó hiển thị thông báo, ngay cả khi trang của bạn không mở.

MDN cũng lưu ý rằng endpoint nên được giữ bí mật, vì chỉ cần biết nó là đủ để gửi tin nhắn đến người dùng đó.

iPhone và iPad

WebKit đã bổ sung Web Push cho ứng dụng web trên iOS và iPadOS 16.4, với hai điều kiện từ thông báo của hãng: website phải được thêm vào màn hình chính, và quyền phải được yêu cầu để đáp lại một thao tác của người dùng như chạm vào nút Đăng ký. Vì vậy trên iPhone, push chỉ tới được những người dùng đã cài ứng dụng web của bạn. Xem ứng dụng native và progressive web app để hiểu việc cài đặt ứng dụng web nghĩa là gì.

Xin quyền một cách khéo léo

Đừng hỏi ngay ở lần truy cập đầu tiên. Hãy giải thích lợi ích trước ("Nhận nhắc nhở một giờ trước lớp học của bạn"), rồi mới hiển thị hộp thoại của trình duyệt khi người dùng chạm vào một nút. Nếu ai đó từ chối, trình duyệt có thể không cho bạn hỏi lại, nên một lời nhắc quá sớm có thể làm bạn mất họ vĩnh viễn.

Thông báo theo lịch cần một trigger

"Nhắc trước 24 giờ" hoặc "tóm tắt hằng tuần vào mỗi thứ Hai" cần một thứ gì đó chạy theo lịch. Đó là bài toán background job, được trình bày trong cách chạy background job. Một mẫu phổ biến: một bộ lập lịch bên ngoài gọi một endpoint được bảo vệ vài phút một lần, và endpoint đó gửi mọi thứ đến hạn.

Prompt để đưa cho công cụ xây dựng bằng AI

Hãy bắt đầu với trong ứng dụng:

Thêm thông báo trong ứng dụng. Tạo một bảng notifications (user, type, title, body, link, created_at, read_at). Thêm một hàm phía server notify(userId, type, data) mà mọi tính năng đều gọi. Hiển thị biểu tượng chuông trên header với số lượng chưa đọc, một danh sách thả xuống gồm 20 thông báo mới nhất, và nút "đánh dấu tất cả là đã đọc". Kiểm tra thông báo mới mỗi 60 giây.

Sau đó là tùy chọn và email:

Thêm cài đặt thông báo: với mỗi loại (trả lời bình luận, lượt nhắc tên, thanh toán), để người dùng chọn trong app, email, cả hai hoặc không gì cả. notify() phải tôn trọng các lựa chọn này. Gửi email qua [PROVIDER] bằng secret [ENV_NAME] chỉ trên máy chủ. Gộp email bình luận để một người dùng nhận tối đa một email mỗi 15 phút.

Sau đó là push, nếu bạn cần:

Thêm web push tùy chọn. Đăng ký một service worker, tạo khóa VAPID và lưu khóa riêng làm secret. Thêm nút "Bật thông báo" trong cài đặt, chỉ xin quyền khi được nhấn. Lưu từng subscription theo người dùng và thiết bị, gửi push từ notify() khi người dùng đã chọn nhận, và xóa các subscription mà dịch vụ push báo là đã hết hạn.

Những lỗi thường gặp

• Thông báo rải rác khắp code. Mỗi tính năng tự gửi email theo cách riêng, và tùy chọn bị bỏ qua. Hãy dùng một hàm notify() duy nhất.
• Xin quyền push ngay khi tải trang. Hầu hết mọi người sẽ từ chối, và bạn có thể không có cơ hội thứ hai.
• Không có tùy chọn. Người dùng không thể tắt các cảnh báo gây phiền sẽ tắt tất cả, hoặc rời đi.
• Gửi từ trình duyệt. Khóa email và push phải nằm trên máy chủ.
• Không dọn dẹp các subscription push đã chết. Subscription hết hạn tích tụ và làm lãng phí số lần gửi.
• Chi tiết nhạy cảm trong nội dung thông báo. Màn hình khóa sẽ hiển thị nó. "Bạn có tin nhắn mới" an toàn hơn chính nội dung tin nhắn.
• Không có bản ghi về những gì đã gửi. Khi người dùng nói "tôi không nhận được email", nhật ký có mã tin nhắn của nhà cung cấp sẽ giúp bạn tìm ra nguyên nhân.

Danh sách kiểm tra

• Một hàm notify() phía server được dùng ở mọi nơi
• Bảng thông báo có trạng thái đã đọc, và chuông có số lượng chưa đọc
• Tùy chọn kênh theo từng loại, được notify() tôn trọng
• Email gửi từ máy chủ với tên miền đã xác minh; gộp hoặc tóm tắt cho sự kiện dồn dập
• Chỉ xin quyền push sau một thao tác của người dùng, kèm giải thích
• Đã kiểm tra push trên máy tính và trên iPhone với ứng dụng đã thêm vào màn hình chính
• Đã xóa các subscription push hết hạn
• Không có nội dung nhạy cảm trong xem trước push hoặc email
• Nhắc lịch theo thời gian có một trigger đáng tin cậy

Thông báo trên Mythex

Mythex không bao gồm dịch vụ email hay push tích hợp sẵn cho các ứng dụng bạn xây dựng, nên bạn tự mang nhà cung cấp email của mình và tự tạo khóa push, được lưu làm secret của dự án. Phần trong ứng dụng chỉ cần cơ sở dữ liệu của dự án, mà Mythex thêm vào khi bạn yêu cầu. Hãy xây dựng bằng các prompt như trên, kiểm tra chuông và email trong Preview, và kiểm tra push trên URL đã publish, vì service worker và push cần một địa chỉ HTTPS thật. Công thức trong tài liệu Gửi email từ ứng dụng của bạn có một prompt khởi đầu. Mythex chưa có tài liệu về các job theo lịch, nên hãy lên kế hoạch cho nhắc nhở theo thời gian bằng một trigger bên ngoài như mô tả trong cách chạy background job.

Câu hỏi thường gặp