With the Beta for Kokotop complete, I want to cover the components and technologies that were used to make this application a reality. In this post, I’ll go over the messaging module and the main technologies I used to successfully build a simple messenger on top of the Web.
Technologies may include:
- A Programming Language, preferably a Web MVC framework such as Node or Rails
- Push Technology such as Websockets, Server Sent Events, or the Pusher API
- A Publish-Subscribe (Pub/Sub) system such as Redis, Pubnub, or Faye
- Encryption such as OTR (not covered in this post)
Note: If you want to hook up Facebook, Google Talk, and various other messaging services to your application, you’ll have to use the XMPP/Jabber protocol. There’s a book on it you can buy or download free. But I won’t cover this topic in this post.
These technologies will act as the backbone to your messaging application. There are some 3rd party API’s that you can utilize which will save you time but it costs money. For example, the lowest tier pricing for Pusher is $20 for 100 people simultaneously connected to your app.
Also, make sure your hosting provider will support these technologies. For example, Heroku did not support Websockets (although it did have a simple API to integrate Pusher with your app) when I was building the messaging module so I had to use Amazon EC2. I’m not sure if that’s the case now.
Once you have an idea of the technologies that you’ll use, you’ll have to determine the features to include with your app. I’ll only talk about the three main components for the sake of brevity:
- Notifications for new messages
- Presence to show who’s online and offline
- The Chatbox
Let’s take a look at this shall we?
Notifications For New Messages:
On the outside, the component works like this: Your friend sends you a message, you get a notification saying your friend has sent you a message.
Internally, the component works like this: Your friend sends you a message, the message is sent to the database and recorded, the message is then pushed back out to you, you get a notification signalling your friend has sent you a message.
One of the main issues with implementing this component is that there is no way to retrieve any new data unless you reload the page. By clicking on ‘refresh’, your browser goes into the database and fetches any new data that has been created. This is otherwise known as the request/respone paradigm. Having the user click refresh obviously will not work in real life so we need to use a push service to handle this.
As an aside, this link gives a good history on push technology.
The advent of HTML5 has introduced some very nice API’s. Websockets is one of them. Websockets is a push technology that essentially opens up a bi-directional connection between the client and the server. It moves away from the request/response paradigm by pushing any changes directly to the client without having the user reload the page. The latency is low (it doesn’t contain stuff like HTTP headers) which makes it super fast and consumes very litle bandwidth.
There’s a problem though. The server needs to know which friend to push the message to. This is where Pub/Sub comes in. Pub/Sub works by creating a channel where both parties subscribe to. Once a message is sent, the Pub/Sub publishes the message to the channel along with the message.
Depending on the purpose of your application, you might want to let your users know if their friends are online or offline (or ‘busy’, ‘away’, …etc). This feature is called Presence. It uses the same technologies as New Message Notification, but instead of returning a message, the computer interprets the message as to whether or not your friend is online or offline and displays it to you. The UI is usually a green dot for online and a grey dot for offline. In Kokotop, I chose to make the entire text green or grey, although this may change in the future when the application gets improved.
The concept of a messaging system is pretty simple when you have the dots connected. Implementing it is a little difficult. But like everything in life, with the right attitude and focus a lot of things are possible. Also, like any system, the complexity can grow. For example, you might want to allow people to create groups. This might mean you’ll have to figure out how to set up the channels properly as well as the Database configuration.
Lastly, I started an IndieGogo Campaign for Kokotop. I’m hoping to get a few early adopters and some cash in the coffers for the Lab. If you’re interested and like what I’m doing, please take a look at the campaign here.