Uniqush after Go 1

Today, March 28th 2012, is a big day for every gopher: Go team released Go version 1. This means Go -- both the language itself and its standard library -- is stable now. Because of this, I think it's time to move uniqush onto next stage. I would like to share the blueprint of uniqush in this article.

Instead of simply providing push service, uniqush will try to provide communication facilities for mobile developers, including both server-side developers and mobile-side developers. This change will make the current work of uniqush, which only has one single program -- uniqushd, become a (relatively small) part of the whole uniqush project.

In the future, the uniqush project will mainly consists of four parts: uniqush-push, uniqush-conn, uniqush-front and uniqush-mobile-libs. I would explain each of them in the following sections.

uniqushd becomes uniqush-push (done)

Currently, uniqushd is the only program we provide in uniqush project. The function of this program is to behave as a proxy between third party server and push service cloud (C2DM, APNs, etc.) so that the third party server can push messages to many platforms (Android, iOS) in a consistent syntax without knowing protocols on different clouds.

In the future, uniqushd will be renamed to uniqush-push because it actually only deals with push service. It will support more platforms (Windows Phone, Black Berry, etc.), but there is no more functions added to this program. It only focuses on one single task: push a message through different clouds.

uniqush-conn handles connections between server and apps

When I say server, I mean an entity that may consists of more than one node. This means it may be a cloud, a cluster, more precisely, or even a datacenter. (OK. it may be, if they want, several datacenters.)

Imagine you have an app, let's say an online chat app, needs to connect your server directly once it is active. You may define the word active under your context. In most cases, it is when the app is in front, i.e. user is using the app on his phone now. If the server sends a message to the app now, the server may want to use this direct connection instead of push service cloud to send this message.

In an example of online chat app, user A sends a message to user B. User A first start his app on the phone. The app then connects to the server saying "I'm A and am online now". From now on, the app on user A's phone is active and a connection between the app and the server is established. User A wants to chat with B. He types in some message, click send button and the message is sent to the server through the newly established connection. The server unpacks the message seeing it is a message for B. It checks whether B is online/active now. If B is online, then there's a connection between the server and B, the server can send the message through this connection. If B is not, then the server will send some message, saying "Hey, B, you got a message from A, check it!" through push service clouds (C2DM, APNs, etc.).

If the server in the previous example is using facilities from uniqush, then it may use uniqush-push to send message through push service clouds, and use uniqush-conn to deal with active connections between the server and apps.

In fact, the server does not even need to know if a certain user is online or not. uniqush-conn can deal with it and decide whether send message through a direct connection, or through uniqush-push.

Now we can see the benefit. As a server-side developer, you only need to send a message to uniqush-conn, and say "Send this message to user B". Then you are done. What if the user B was offline? Well, uniqush-conn could then automatically tell uniqush-push to push a notification to user B. If the message if too big to be fit into a notification, uniqush-conn will send a notification to user B, saying ``You got a message'', keep a temporary copy of that message and send the message to user B once it's online. The server even does not know the existence of uniqush-push.

uniqush-front handles scale-out growth

As I mentioned, server side may consists of more than one node. With the increasing of number of connections, growing in a scale-out way should be a concern for server developers. We introduce uniqush-front to handle connections distributed among several instances of uniqush-conn in more than one nodes (or cloud instances). The server-side program will finally only communicate with uniqush-front without knowing which instance of uniqush-conn handles which connection. The protocol between server and uniqush-front will be exactly the same as the protocol between server and uniqush-conn. So that changing from uniqush-conn to uniqush-front will not lead to change of code.

Suppose the server side has 10 nodes. Each node runs an instance of uniqush-conn. A certain user may connect one of the instance on some node. The server side program only need to tell uniqush-front what message needs to be sent to which user. Then uniqush-front will figure out which instance of uniqush-conn should be use. Adding more node will not be a pain because the server side program won't be changed.

uniqush-mobile-libs helps app developers

uniqush-conn keeps connections between apps and the server. It also sends messages, commands to apps. The app developers do not need to know details about how to communicate with uniqush-conn. uniqush-mobile-libs will contain libraries for popular mobile platforms so that app developers can use it to communicate with uniqush-conn, hence with the server side program.

When?

uniqush-push is already there. I only need to change its name from uniqushd to uniqush-push. I will start developing uniqush-conn in this week and (hopefully) uniqush-conn and uniqush-mobile-libs will be released before Sep. 2012.

I wish I can make it faster. But sorry for disappointing you, it seems impossible for me: there is only one developer in this project, and yes, I am the developer. If you are interested in this project and want to make your own contribution, please feel free to contact me.

Update

As I mentioned, uniqush-push is online now. It is more than a renaming work. All related documents are changed respectively. If you find any inconsistence between the document and the code, please let me know. Thank you very much.