This post is the first in a three-part series covering the projects we built and had on display at our first Integration of Things Zone at CONNECT 2015. Missed us there? No worries, not only will you get a sense of the cool IoT projects we built below, you’ll also get a front row seat as to how we built it, and with what technologies. So put on that seat belt, and learn about how the team built Stock Cars, a project that brought big data to life by mashing Anki Drive cars with stock market data from NASDAQ.
Why we built it
Stock Cars was the product of an IoT themed internal hackathon we ran at MuleSoft in April. For the greater part of a weekend, engineers from Buenos Aires to San Francisco teamed up to bring projects we cared about to life. The team consisted of four people: Victor Romero, Alejandro Sequeira, Alejandro Nosenzo and myself.
Our goal was to highlight, with a simple Mule application example, how you can connect different technologies to create new and innovative use cases. We chose Anki Drive Cars, an increasingly popular game that you can buy online or at places like the Apple Store, as our 3rd party device to interact with because we realized, with minimal digging, that you could program your own games using their custom SDK!
Stock Cars is obviously not about the Stock Cars you’re used to seeing on TV. We call our project Stock Cars because we literally made the cars race based on the market performance of different stocks. Wait, what?
It’s pretty neat, actually. We built a Mule application that pulled the stock performance data for three companies–Apple, Google and Cisco– that we then assigned to a specific racing car. The result was that each car would race and change their speed based on the actual performance of that stock on a given day. In other words, the companies that performed better percentage-wise saw their cars go faster than the ones whose numbers weren’t as good, and so on.
In our demo we pulled in 30 days worth of market data so that every 8 seconds or so, the cars took on the characteristics of their stock, which made things exciting and unpredictable, the way some of the best Formula One races would be. When one stock outperformed the others, that car would rapidly take the lead, and if another stock went way down, their car would soon be trailing behind. We also had a good amount of overtaking, which kept things fun. Our attendees loved it!
Architecting it all
In this architecture we are depicting several different applications of Mule:
- Mule on Cloudhub: a Cloudhub worker is running a Mule instance with two Mule applications:
- One application gets the data from the NASDAQ web service for a particular period, and stores it in an intermediate MQ server.
- Another application serves the web dashboard that we use to show the current performance/speed of the cars, by subscribing to the same MQ server (using the STOMP JS framework) and getting the messages.
- Mule on-premises: a local instance of Mule running on a Raspberry Pi that reads messages from the MQ server (using our AMQP connector) and translates them into the bluetooth messages that we are sending to the cars
- RabbitMQ: a cloud MQ server that we hosted on EC2 and that we use as an intermediate storage between our cloud Mule instance and our on-premises Mule instance.
- The web dashboard and control webpage we use to start the race.
- The on-premises application that sends commands to the cars
As you can see, we use a custom script to translate the actual stock values that we read into different speed values for the cars. This is the easiest approach as we only need to handle the set_speed command for this example. When you need to scale and handle several different requests, you would probably have an API interface to define such interaction.