Vivendi
Vivendi

Reputation: 21027

How to design a generic notification system for websites?

I want to design a notofication system in a generic way so that multiple systems can make use of it. And i say generic because right now it needs to send an email. But maybe later on it also needs to send out push notifications, but to a different group of people.

Here is some background to start with.

Currently we have two websites that are responsible for a certain part in a workflow. For example:

So basically the administrative person can only continue to the next step in this workflow when the requested Person responds.

Sometimes the Persons simply forget to respond or forget to complete their document uploads. For this I'd like to create a notification system. When a certain Person haven't completed his profile/documents in 2 days, then our system should send out a reminder email.

We also have a third and a fourth website running which is part of the workflow. To that the same ideas apply. But for example for Website 3 a contactperson of a company is involved.


So, I am really curious how to set up a generic system like this.

Specifically, should each website be responsible for implementing its own notification client? That seems like it'd be really easy for code bases to get out of sync. But at the same time, even if you build a library you still need to handle the HTML templates somehow.

I'm not really sure where and how to start. If this were for a single website it'd be a different story, but implementing it across multiple websites at the same time has me puzzled.

Upvotes: 1

Views: 3237

Answers (4)

pnewhook
pnewhook

Reputation: 4068

What you're describing generally is a Publish/Subscribe model, the reminder is a separate issue that's I'll tackle next. If you had only two websites you might simply send an HTTP request from one web application to another to notify the second system there's work to be done. But if you need multiple web applications to take part, this quickly becomes complex.

Instead I'd use a PubSub system (for example NServiceBus). In this setup you'd have one central server that co-ordinates events and determines the appropriate responses. For example when a new user signs up, a message would be published to the PubSub server. On that server there are a number of subscribers that know how to respond (create new accounts, send emails, notify admins, etc).

At first if you're just notifying admins via email there could be a subscriber that sends emails, but then later you might swap in something like SignalR for real-time push notifications like @coirius suggests.

As for the reminders, I'd store a record of the request in a database, then have a daily job that checks for unfinished requests.

Upvotes: 1

arknotts
arknotts

Reputation: 454

I'd put the notification logic in one of the applications (or even its own project if you envisioning it growing in the future), then expose the functionality to the other application via a RESTful web service (possibly using Web API). This way it shares the same code base (HTML templates) but is still only loosely coupled.

Upvotes: 1

Phil Boyd
Phil Boyd

Reputation: 390

Something that might help - MS provide a sample application for WWF (Windows Workflow Foundation) for HR management that might give you some ideas. Not saying that WF is the solution - but how they modeled the process.

Upvotes: 0

wladyslaw.czyzewski
wladyslaw.czyzewski

Reputation: 770

I recommend to use SignalR. It's very simple libary to build realtime web application, i can easily implement notifications in few lines of code.

Upvotes: -1

Related Questions