After a long delay I finally mustered up the courage to build the query ranking module. Some scary stuff. Here are the problems I’ve been facing whenever I start building this.

• The ranking requires the table’s Foreign Key structure. Once the query generation is done, the recursive calls along with Javascript’s callbacks is a nightmare.
• Callbacks are being received even after sending the output. Some relations between the tables are discovered even after ranking. This is troubling.
• I tried to deal with promises but combined with the already scary ranking algorithm and multi-module structure this will just take more time than I have.

So I am switching to a new approach of this as suggested by a colleague.

A meteor based web application which allows users to collaborate to modify the queue for a designated player device (playing audio files stored on server using HTML5).

So, I heard somewhere that meteor was a great framework to build full-fledged JS applications with server and client code (I know it’s called full-stack). Unsurprisingly, I wanted to play with it and so, I came up with the idea for a centralized music playing system which can be remotely controlled. Initially I thought this would just be a side project to test out meteor and its capabilities, but the ability of meteor to support fast development of code logic forced me to think of this on a big scale.