Hi! Why?

This blog is a cool guy’s way of documenting what’s behind the scene of Radio Auto-asaad. So if you don’t know what it is (or not interested about it) you have two choices:

  1. To get yourself familiar with Radio Auto-asaad, by visiting its website and reading this rest of this post.
  2. To leave this blog. I won’t blame you if you do so!

Before I get into technical details, here is some background. I started this pet-project to fill up my extra time, when I am off duty as a PhD student (which is a rare thing to happen BTW). My first idea was very simple: I wanted to schedule playback of some mp3 tracks I had on my laptop. So I started off writing few lines of code to do the job and KaBoom! I am here, writing my diary about all the sweat and blood (aka coffee) it took me in order to build an automatic internet radio-station. Obviously, I am not adding any clarity to the question of WHAT is Radio Auto-asaad, and I am aware of it. I will dedicate another post to elaborate about the domain. But like many other startup projects, it’s more likely about HOW and WHY I did what I did rather that what is the final product is. So let’s jump to that part of the story when I decided to go online and make RAA (= Radio Auto-asaad) publicly available. My half-carrier as a PhD student pretty much sets the limit on the project budget: Zero! Therefore, I chose a straightforward strategy. Use free stuff unless you really cannot find a decent option free of charge. So let’s see what kind of external services/infrastructure we might need.

Ingredients for building an internet radio

From the top of my head, I have listed some resources that come to mind easily:

  • Servers, storage and enough bandwidth to deliver
  • A nice and shiny domain name for the radio
  • Software development tools and subscriptions (e.g. Apple developer program, Google Play, etc.) Let’s put aside the latter two items. We will come back to them later. But for now, I guess we all agree that without a proper hosting of our code, there is no RAA.

RAA server hosting

It should be a solved mystery by now, after all said above, that RAA is hosted on Amazon AWS and is tightly squeezed to use only the free tier of AWS. For those who might not know, AWS free tier gives you one year of free access to:

  • 1 VM with 1 processing core and 1 GB of RAM
  • 30 Gb of SSD disk
  • 5 Gb of S3 storage
  • ~800 Hrs of processing time on Lambda (estimate for 128 MB of Memory)
  • And a few others

OK. Now that we know our environment, let’s build our architecture. This is quite similar to any other enterprise application, right? Services, communicating with each other and serving user requests (see Figure 1 below). So let’s fire up IntelliJ, find a cool new web framework and start development. But wait a minute! Not so fast…

Figure 1. A sloppy sketch of an enterprise application architecture. What I am trying to show is that components are well defined and encapsulated!
Figure 1. A sloppy sketch of an enterprise application architecture. What I am trying to show is that components are well defined and encapsulated!

It doesn’t ask for a genius to find out that 1GB of RAM is not even enough for JVM to say good morning. Let alone bringing up a web framework, perform several deployment, most of the times hot ones, a day (which in my experience generates huge amounts of garbage), and so on. And we still didn’t discuss the DBMS we are about to use. So enough of storytelling! I need an architecture like what I sketched in Figure 2.

Figure 2. RAA architecture from high above. Numerous script files and a ton of data files.
Figure 2. RAA architecture from high above. Numerous script files and a ton of data files.

That’s it. I made my most important architectural decision. That is:

  1. Generate static files unless you really need to be dynamic.
  2. Instead of a designing mothership application, write several applets that communicate to each other through files.

We are almost there! Just to add to the fun, I obliged myself to use technologies, languages and frameworks I wasn’t comfortable and/or experienced with. As a backend developer, I was always hesitant to learn Javascript and any other front-end technology. Thanks to NodeJS, I am finally out of excuses and must use Javascript this time to code my back-end. (I will show you later that this decision was not made completely out of stubbornness, but let’s believe so for now). My next post, will show you what is RAA in essence and some domain terminology I will use later on.

- Back -