Network Management

For managing network, I had to handle any kind of network condition that may arise. It took 80% time planning out the design of the code and the rest for implementing.
First we (Ruphy and I) thought of having a queue for caching the messages which are not sent to the server (due to any reason) [Link to the code]. But this design had problems with it. It was not generalised; it handled only text messages sent to the server.
Then we decided to have a separate class altogether to handle the unsent messages. Talking in technical terms, Ruqola uses Meteor APIs to send messages over the network and DDPClient class implements Meteor’s DDP. DDPClient is a generalised class and we tried to keep it that way. Now DDPClient class contains an abstract internal queue which handles all requests. It delegates the work of processing this queue to a separate class, the MessageQueue class. MessageQueue class tries to re-send these messages,until it succeeds, as soon as the network is restored.

During this, Ruphy always taught me to write elegant code and that it will be worth it (and I’ve begin to realise that it is).

I also learned some golden rules-

“Never expose your internal data storage until you are really out of other options.”

“Double arrows in a workflow create mess.” (Yes, this means I did mess up a lot :p )

Finally network management was handled as can be seen  here.

Next up, I have to add support for federated login (OAuth).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s