Developing Solutions for Scale
We recently launched a new feature that only one user can access.
A couple of weeks ago we rolled out a new feature for one of our users that allowed them to upload their newly released album to our system and then provide download codes to those who had purchased it. Even though we could have built this for just the one user in a much simpler manner, we took three times as long and built this feature for all our users to have access to … eventually. Why did we do that?
At Stream Monkey, we have an internal policy to only build solutions that are scalable and that add value to the majority of our users. Of course, that makes sense at the core of our product: we’d never want to build video players that were completely custom to every user.
By keeping our player under one core configuration (with lots of variety based on each user’s desires), we can create stability for all viewers tuning in. You’d be surprised how many companies like ours get stuck in the rut of custom solutions — trying to please the people keeping their product alive.
Four things we ask when considering implementing a new feature:
- Does this feature add value to the majority of our users?
- Can this feature be built to scale?
- How does this fit into our future goals?
- Does development time outweigh potential usage time?
Being a smaller development team, we have to choose what goes into our feature releases very carefully. There are times when we want to build and launch a new feature, but we’re unable to answer yes to even two of these questions. It’s never easy to walk away from projects that get you excited, but if they don’t fit into the culture and identity you want to create, then you shouldn’t pursue them.
Sometimes the simplest features take the longest time.
We strive hard to keep things simple. At the core of everything we create and pursue, we ask ourselves how we can continue creating simple to use features while building advanced tools on the backside. We long to be known as “simply advanced.” What a funny thing to want to be known for, right?
A perfect example of our desire to create something “simply advanced” is when we decided to build this code redemption tool for our users. We had a user stop by our office in the City Beautiful and ask us to help them build a system to provide download codes. They needed to mass generate thousands of codes to be printed on cards, which would be handed to someone purchasing an album on site. And then those codes needed to be entered on a site to receive the downloadable package.
Pause.
The following is a technical breakdown of how we implemented this. This post aims to serve a dual purpose: show off what we’ve been working on and explain how we implemented this feature for scale so others can do the same.
Resume.
There are many technical pieces that contribute to why it took us three times as long to produce this new feature. Let’s quickly touch on the four big items that made up this project and how we used them to implement this feature.
First: System to generate codes
We recently dove head first into a new serverless application framework called Serverless. It’s amazing. We’ll share more details on how we’re using this later. For now, you should know this framework is an absolute game changer. It quickly builds server architecture that runs in response to events on AWS Lambda and auto-scales for you. It’s incredible. When I say a game changer, I mean it is truly a game changer.
Inside Serverless, we created an API using Amazon’s API Gateway and Node.js functions that run on Lambda. The API we created could create, delete, and redeem the codes.
To actually generate the codes, we went with node-code-generator, a tool that creates random codes using a pre-defined pattern you specify. It’s really that simple.
Second: Encryption on files
Now that we have codes, we need to deal with our files that the user had uploaded. For this project, we had our user create a compressed folder that was uploaded to their specific bucket in S3. We store all of our user’s assets inside S3, so it was a natural fit for us.
Using the API we built with Serverless, we embraced the power of Cloudfront to sign URLs that then delivered the stored files that were on S3. This signed URL was valid for two minutes before expiring. We chose two minutes because the URL was only signed when a viewer had actually hit download, so their download should have started immediately.
Third: Download method for viewers
We tried a few things here, but we ended up landing with an iFrame embedded input box. Yep. An input box. The viewer types in their download code into the input box and on enter (or clicking submit, which we included for our unsure friends), we do an ajax request to our Serverless endpoint which does a validation. If the code is valid, it replaced the input box with a download button which is linked to the signed URL.
Fourth: Validator
All we did here was a simple query to our database. It first checked to see if the code exists inside the system. If it does, then it goes to see if the download had been requested three times in the past. If it had, then the code was now expired and could no longer be downloaded. If it had not, then it would increment the count in the “requested” field by one and then return the encrypted file link, which was then passed to the front-end page for the viewer to get their download.
That’s a small taste of the tools we used to implement this feature. While it’s possible we’ll never release this feature to our entire user base, it is a feature that we have confidence in since we know that it has been properly built to scale and is ready for the masses. This is what we strive for; excellence in our platform that ends up being a simply advanced solution for everyone.
Stream Monkey is an online video company focused on simplifying the way users share, connect, and engage with their audience.
