Architecting MusicManaged
In this Dev Blog, let’s talk about the architecture of Music Managed and the process of getting there from a fairly simple, vague brief: Make Music Great Again… err… Make a great music player.
As we saw in the last Dev Blog, our initial ideations were about the tools we would be using. Settling on a framework for the back-end and subsequently, the front-end, required asking a few tough questions.
What?
Fairly simple and straightforward. What were the best tools to build Music Managed? How could we ensure we weren’t bringing a sword to a gunfight? If we did, we’d have to be pretty sure our swordsmanship was up to the mark!
In our initial discussions, we went over quite a few options. PHP and Python were swiftly discarded — it would take too much time to learn the required skills to do the job. In the case of Python/Django, we found the overall learning curve a bit too steep given the time constraints we were working with.
That left us looking at Node as a viable tool. Given its great flexibility in terms of development — and given that the language was JavaScript — we felt the learning curve was not as steep and decided to give it a spin.
Why?
We settled on NodeJS quickly for a variety of reasons.
We ain’t got all day.
One of our primary concerns was hitting the ground running — if we made mistakes, we needed to have the ability to patch things quickly and keep things moving. Also, we needed to make the initial decision and stick with it.
Great flexibility.
Another point in favour of Node was NPM — the Node Package Manager. The huge repository of node packages meant that a large number of problems — both potential and actual — could be avoided by using trusted packages that are implemented for specific use cases. Largely, this also meant we wouldn’t have to reinvent the wheel when not necessary.
It also allows us flexibility to do the same thing in many different ways. Front end? There’s React/Angular/Vue/EJS/Mustache, etc. for that.
Essentially, we could rely on the immensely popular MEAN Stack with a few modifications —
Using EJS instead of full-fledged frameworks like React/Angular. While they are great in their own right, the learning curve and the individual weight they added to our project size was immense and our explorations told us EJS was the way to go — simple templating along with the ability to write expressive, flexible JavaScript right into our pages.
Quite the multitasker.
Node’s inherent architecture makes it great for asynchronous, network applications. This meant that we could take full advantage of Callback functions in JavaScript and also have a lot of things going on simultaneously — we imagined that the activities of loading static assets like web-pages, stylesheets, images, songs, etc. would make the application extremely active and Node fit well into the equation.
How?
After much trial and error, we settled on the following architecture.
At the center of our application is the application server, driven by NodeJS.
The server serves incoming requests with static webpages/templates as required and works as an interface between the front end (EJS templates) and the back end (MongoDB database).
We developed a RESTful API to interface with our various services at will and in a uniform manner.
The client is served with templates that are individually powered by their own JavaScript, which we use to make requests to the API, using its responses to populate playlists, play songs and do much more.
That’s a wrap! In the following Dev Blogs, we will take you through some of the things we talked about here in greater detail!
