Brief:
The Time Tracker application (or Timer, as we all in Boston Byte call it) is one of the many user interfaces for the internally used Time Tracker System. This application runs on the employee's desktop and supports Windows Operating System (OS), Macintosh OS X, Ubuntu OS and it's other variants. The employee can select any assigned project tasks. He/she can then start or stop the timer for various tasks for which he/she has been working. The time records are updated on the centralized server accordingly. Along with many additional server side modules, the whole system makes it much easier to track the project status in real-time.
Need :
Timer 1.0 had been developed using the .Net Framework since the inception of our organization and has been continuously evolving ever since. During the early years, almost all desktops were running Windows OS and thus the Timer 1.0 was developed for Windows OS only. But gradually over time, our expertise would span various technologies and environments for which our developers would choose the OS which best suited their development needs. Thus making it impossible to run the Timer 1.0 application on these new operating systems.
Timer 1.0 had a major performance drawback due to the fact that to maintain the consistency of the time records, both the client & server had to be in sync continuously. Polling mechanism had been implemented to achieve the same. Well, as it turns out, with the gradual increase in the number of employees the polling mechanism had taken a toll on the server as well as the internal network bandwidth. So we had to find an alternate solution to address the issue.
How It Works:
Timer 2.0 was on the meeting board and we had to address the above mentioned issues along with some other changes. To make it platform independent, we decided to go with JAVA particularly JAVAFX. To address the polling issue, we decided to keep the whole system event driven with the help of MQTT. The Last Will & Testament (LWT) feature of MQTT was the prime reason for us to go with MQTT. If any Timer application crashes or is disconnected from the network then the MQTT broker relays the LWT message to application server and the server updates the time records accordingly. Another reason to go with MQTT is that it has it's own implementation of socket level keep-alive ping so we don't need to worry about polling the server explicitly. The result of this implementation is that Timer 2.0 application consumes 2 bytes per 30 seconds i.e. around 0.07 bytes per second whereas Timer 1.0 used to consume around 40,000 bytes per second. Along with that, the server CPU load has decreased drastically. The Timer application will continue to evolve with technologies which would better suit our future needs.