The Notification Model - Part III

When it comes to mongodb. Things could be store as object. So I don't need to concern about joining tables and worrying the bulkiness of making a super big table which tears down the performance.

Yes, things should be optimized for it's efficiency when you expect the thing you made to expand in future. Before I got my first job, I code to extreme performance. That, from what I've learn from two years of real life working. Is not very practical when co-working and deadline comes to play.

Performance always has its trade offs. Sometimes it would be the readability. Sometimes it would be the time to develop. Sometimes it would be both and those costs money. In terms of usage, say someone need to get to somewhere with a transport vehicle. He ask you make one for him, he didn't say what he want. But normally he would expect me to offer him a bike. If I was before, I would be all over it and than build a jet for him. Or a car with a jet engine inside.

And this is wrong. Of course he might be happy he might get a jet or whatever exceeds his expectations. But building a jet takes times. He could just walk there and I don't even get the wings completed yet. So a bike for him, nothing more.

This is also one of the reason why we start writing nasty codes. Don't have enough time. Whatever, just make it work - it worked! It is done, next!

Anyway, the whole point is getting the minimum costs and maximum output.

Welp, stop chitchatting. Jumping right into today's topic.

Rewriting the model with nodejs

Although it is called rewriting. The fundamental concept of notification remains the same. As long as the notification is defined by which way. There are basically two main functions for notification:
1. subscribe
2. dispatch

So the notification will only dispatch to that user if the user subscribed to that type of notification.

The subscription model should be located in Users:

User = {
  subscriptions : {
     type 1: NotificationA
     type 2: NotificationB
     ...
}

The reason of using indexed array is for faster searching and lesser coding.
For the sake of dispatching notifications, I wouldn't want to store the actual notification data under user because that will makes me search every user to check that.
So I store the actual notification separately.

Notification = {
  type: Number
  target: Schema.Types.ObjectId
  inbox: [ Object ]
}

As before, there's different types of notification. Guest commenting to an article, someone replied to the comment, someone published an article, etc. Thus the type indicates what action is taken for that notification. So the system could know which class it need for processing this item.
Then there's multiple. So the target is needed for that type of notification. Say Jimmy and Tom commented on the same article. I need an ID to identify which one is which. So comes the "target".

For the inbox, it is the data pushed by NotificationType and the value could contain anything depends on what that type needs. Readability could be considered here as it could also be just storing the message and link. The good side of this it could be code-independent. But this doesn't mean code-dependent is a bad thing. It really depends on what do you want to achieve.

So I am going to store link and message here since there isn't really much performance or storage concern. This is a bad idea in terms of storage, there would be so many duplicated phases like "Someonce commented on bloblabla". But for a small computer like mine. I am trading storage for CPU loading. (since substituting message with variables costs loading).

Now I can define how the workflow of how the notification is subscribed, pushed and received.

Class NotificationCenter:

	// getSubscribtions by type
	public Array.<Notification> getSubsByType( int typeId );

	// getSubscribtions by type and target
	public Array.<Notification> getSubsByTarget( typeId, targetId );

	// getSubcribtions by user
	public Array.<Notification> getSubsByUser( userId );

	// Subscribe to a notification
	public void subscribe( userId, typeId, targetId );

Continue to "The Notification Model" Part IV >>

Tag(s): JavaScript node.js rosemary

斟酌鵬兄

Tue Sep 08 2015 12:16:02 GMT+0000 (Coordinated Universal Time)

Last modified: Fri Mar 11 2016 14:31:26 GMT+0000 (Coordinated Universal Time)