thắc mắc [.NET] Xin ý tưởng và công nghệ cho tính năng Notification này

Hi các thým, em mới được giao task này, kinh nghiệm và kiến thức còn hạn chế quá nên không biết hướng giải quyết như thế nào. Hy vọng các thým cho một vài ý tưởng hay từ khóa để nghiên cứu. Thank các thým!

App có nhiều roles, mỗi role có quyền ở các Areas khác nhau. Sau một thời gian các roles này sẽ bị hết hạn. Trước 2 tuần, các user có role nào chuẩn bị hết hạn sẽ nhận được thông báo về việc sắp hết hạn này.
  • Không cần làm Live Notification.
  • Notification sẽ được query và load mỗi lần trang được load mới. Vì vậy cần một bảng riêng chứa thông tin Notification để query trực tiếp từ đây (tránh mỗi lần load lại phải join, count, query từ nhiều bảng).
Giờ em đang băn khoăn là: để load thông báo từ bảng Notification này thì bảng này đã phải có data từ trước. Nhưng làm thế nào để insert data vào đây tự động mỗi khi cái điều kiện sắp hết hạn role được đáp ứng?
 
Chạy một con worker daily, check expire time của user rồi send notification luôn, không cần thiết phải lưu vào bảng.
Chiều rảnh tôi tư vấn chi tiết cho.
 
Lúc set role chắc có last modified date phải khum? Làm 1 cái cron job = windows service hoặc hangfire để query là đc.
Còn nếu mún quản lý luôn notification thì tạo 1 bảng riêng. Insert vào bảng những thông tin cần thiết (user id, expired date, …) lúc set role cho user. Sau đó vẫn phải làm 1 cái background job

via theNEXTvoz for iPhone
 
Nhờ các thým gợi ý dùng HangFire làm background job nên cuối tuần vừa rồi em có ngồi nghiên cứu và xem áp dụng vào project mình như thế nào. Trong lòng tí tửng hưng phấn vì thấy mọi thứ đều rất ổn và hợp lý rồi :confident:

Thế mà sáng nay lúc họp em đề nghị dùng thư viện này rồi trình bày solution thì bị từ chối phát một các thým ạ. Ổng lead bảo tương lai sẽ có nhiều loại notification khác nữa, có loại chỉ cần refresh cái là hiện ngay, cho nên cronjob 1 ngày/lần, mấy tiếng/lần không phù hợp. Bây giờ ổng yêu cầu em tìm một giải pháp để tương lai scale cho nhiều loại notification khác nữa.

Mới chân ướt chân ráo đi làm mà gặp quả task này toang quá các thým. Thử thách chồng thử thách mỗi ngày thế này tổn thọ quá :cry:

Giờ em đang nghiên cứu Service Bus, không biết có phù hợp không nữa. Hy vọng giãi bày lên đây được các thým gợi ý vài điều quý giá.
 
Nhờ các thým gợi ý dùng HangFire làm background job nên cuối tuần vừa rồi em có ngồi nghiên cứu và xem áp dụng vào project mình như thế nào. Trong lòng tí tửng hưng phấn vì thấy mọi thứ đều rất ổn và hợp lý rồi :confident:

Thế mà sáng nay lúc họp em đề nghị dùng thư viện này rồi trình bày solution thì bị từ chối phát một các thým ạ. Ổng lead bảo tương lai sẽ có nhiều loại notification khác nữa, có loại chỉ cần refresh cái là hiện ngay, cho nên cronjob 1 ngày/lần, mấy tiếng/lần không phù hợp. Bây giờ ổng yêu cầu em tìm một giải pháp để tương lai scale cho nhiều loại notification khác nữa.

Mới chân ướt chân ráo đi làm mà gặp quả task này toang quá các thým. Thử thách chồng thử thách mỗi ngày thế này tổn thọ quá :cry:

Giờ em đang nghiên cứu Service Bus, không biết có phù hợp không nữa. Hy vọng giãi bày lên đây được các thým gợi ý vài điều quý giá.
Cái cron job là để chạy cho khi không có tác động từ phía user về server thôi. Còn vấn đè refresh page là hiện ra cái notification thì cái này có thao tác từ phía user về server rồi, lúc đó muốn hiện thông báo gì mà không được.
Theo cái vấn đề của bác ở #1 thì cái cron là hợp lý, còn đối với các loại notification khác thì có cách xữ lý khác thôi
 
Có vài cách:
1. Làm API global, page nào cũng gọi, refresh là thấy notification :shame:
2. Websocket chơi notifcation real time :sexy_girl:
3. Cron job dưới BE gửi notification theo giờ :feel_good:
4. Notification cho n loại event nhất định -> update code cho từng API cho nhanh

Còn vụ check hết hạn thì cron job mỗi ngày query xem có user nào hết hạn vào hôm nay ko, nếu có thì insert :look_down:
 
Nhờ các thým gợi ý dùng HangFire làm background job nên cuối tuần vừa rồi em có ngồi nghiên cứu và xem áp dụng vào project mình như thế nào. Trong lòng tí tửng hưng phấn vì thấy mọi thứ đều rất ổn và hợp lý rồi :confident:

Thế mà sáng nay lúc họp em đề nghị dùng thư viện này rồi trình bày solution thì bị từ chối phát một các thým ạ. Ổng lead bảo tương lai sẽ có nhiều loại notification khác nữa, có loại chỉ cần refresh cái là hiện ngay, cho nên cronjob 1 ngày/lần, mấy tiếng/lần không phù hợp. Bây giờ ổng yêu cầu em tìm một giải pháp để tương lai scale cho nhiều loại notification khác nữa.

Mới chân ướt chân ráo đi làm mà gặp quả task này toang quá các thým. Thử thách chồng thử thách mỗi ngày thế này tổn thọ quá :cry:

Giờ em đang nghiên cứu Service Bus, không biết có phù hợp không nữa. Hy vọng giãi bày lên đây được các thým gợi ý vài điều quý giá.
Cái job để remove cái quyền đó đi thôi.
Thêm cái cột expire time, trên code thì có cái api /current check info với kiểm tra expeire time - current < xxday thì trả về notify thôi.
Còn thằng A remove role thăng B, mà phải notify realtime thằng B thì làm thêm con notifystem nữa, dùng socket hoặc SSE :v
 
Bên e đang xài dạng push message vào queue, ngay khi vừa push vào queue xong nó tự trigger background job chạy push notification về device. Gửi xong xoá message từ queue đi, gửi failed setup sau bn phút gửi lại :v app nhỏ traffic thấp thấy đang chạy vẫn ổn
 
Có vẻ ông lead bạn không hiểu vấn đề, vấn đề là cronjob chỉ làm cái phần revoke mấy cái role rồi send notification. Còn Notification nên dùng công nghệ gì thì là vấn đề khác.
Nếu không muốn xài 3rd party thì .NET core có SignalR (kết hợp redis pub-sub cho multi-cluster). Còn không thì có thể xài Firebase.
 
Nhờ các thým gợi ý dùng HangFire làm background job nên cuối tuần vừa rồi em có ngồi nghiên cứu và xem áp dụng vào project mình như thế nào. Trong lòng tí tửng hưng phấn vì thấy mọi thứ đều rất ổn và hợp lý rồi :confident:

Thế mà sáng nay lúc họp em đề nghị dùng thư viện này rồi trình bày solution thì bị từ chối phát một các thým ạ. Ổng lead bảo tương lai sẽ có nhiều loại notification khác nữa, có loại chỉ cần refresh cái là hiện ngay, cho nên cronjob 1 ngày/lần, mấy tiếng/lần không phù hợp. Bây giờ ổng yêu cầu em tìm một giải pháp để tương lai scale cho nhiều loại notification khác nữa.

Mới chân ướt chân ráo đi làm mà gặp quả task này toang quá các thým. Thử thách chồng thử thách mỗi ngày thế này tổn thọ quá :cry:

Giờ em đang nghiên cứu Service Bus, không biết có phù hợp không nữa. Hy vọng giãi bày lên đây được các thým gợi ý vài điều quý giá.

Refresh phải có ngay là cùng 1 request phải xử lý data, vừa check business logic để tạo noti. Ko biết lead bạn giỏi cỡ nào mà lại làm như vậy.

Viết cron job check từng phút, check business logic tạo noti, xong push vào SignalR đẩy lên frontend.
 
Từ hôm qua nghiên cứu đến giờ thì em thấy giải pháp này khá hợp lý (giống thým crazymankkkk ở #12)
  1. Viết 1 service sender, listener dùng Azure Service Bus Queue
  2. Api, service nào cần hiện thông báo thì inject service trên , send nội dung vào Queue
  3. Dùng HangFire làm Background job lắng nghe Queue, nếu có giữ liệu mới thì lưu vào bảng Notification
  4. Người dùng vào trang, refresh trang thì query từ bảng Notification lấy thông báo
 
Back
Top