So it's been a half year after the last article I talked about the Notification Model in this blog.

I just realized that the life cycle of node.js is just too damn fast. I remembered the first nodejs version I used was something like 0.10.2 or so. And now it's v5.5.0! Even though I could say I like being in the front line of tech, it is still too hard for me to keep up. Because of this I have hard times rewriting some of the framework again and again.

In the 0.10.2 version the code was purely written on ES5. And for a better integration on future I've decided to move on to ES6. But currently the whole Js language is still in the "transition" state and is pretty messy because of those *partial support* thingy. I think I should also rewrite the front-end framework as well.


Now let's jump directly into today's topic, the actual implementation of the Notification Model.

Concept

As I said previously the new model might vary due to the different nature of the database used. This document-oriented thing of mongodb requires you to define a document model. The model is defined in the application. Thus the data stored inside the database does not contain schema nor table relationship, fields are also loosely typed too. ( Actually everything is just a JavaScript Object. )

I haven't figured out what is the advantage of neglecting the relationship of the documents yet. If the model is stored within the application. So the query optimization is often shifted to the application side. Here I use mongoose because I don't have confidence to handle the optimization myself.

Below is the current model of how I think this whole notification thing should work:

If you have read through the previous articles. There is not much left to say.

Another thing worth to mention that this blog is actually multi-user. Unfortunately Aaron does not do blog ( actually he blogged once ). But I have to be prepared that someday he might change his mind and I want to be prepared and make him feels welcome. So I keep the multi-user supporting bit.

And that's why the name "Notification Center". It is a central manager that handles user's subscription and dispatch notifications. There was originally 4 types of notification in cranberry. But now I have kept back the "Article Publish" & "Article Update" since it requires the user to be logged in.

( But they are still useful. I have an idea that we could store the email as verification of a loose account for guests. Since the emails are kept secret. )

On the half way through I realize that a "filter" is needed as I do not want the notification to be shown up by my own action. I don't need to be notify as I am the one who toke such action.

Demo gif

Since I could not demonstrate the final result. I've recorded a gif to give you the impression of how it works. I didn't click the settings bit because if I click anyone of them. I would be unsubscribe from all of it's sub notifications. It is basically switching ON & OFF. I wonder if this is a ambiguous feature as I don't want to turn them off ... whats the point of making it?

Click to view the animation.