Tasks
- Research MQTT
- Pivot to AWS
- AWS IOT Core
- AWS Lambda
- AWS S3
- Post state information to feed
- Convert then host image from source
- Convert GIFs into a manageable format
- Apply for Spotify verification
Requirements
- Inexpensive
- Responsive
- 24/7 availability
- Authorization control
- Format images for display
- Serve JPGs
- Serve GIFs
Intro
A backend is a pivotal component of this project as I find that devices that can only update over a bluetooth connection with a phone tend to be a hassle. This backend’s intended purpose is to provide an endpoint where the device can either download an image, be referred to the url of an image hosted online, or send state commands such as “Spotify”, “Weather”, “Robot” for functionalities that the device can perform locally. This backend will also perform access control for user accounts, as well as the authorization control flow for the Spotify API. Depending on my findings while doing research for the Firmware, the backend may also need to do some image processing, such as reducing colours, resolution, or breaking a GIF into individual JPEG frames.
Previous prototypes of this project have all used Google’s Firebase as a backend as it uses node.js which I am quite familiar with, and has enough usage within its free tier to support a couple initial devices. The old backend has 5 functions:
- auth
- Beginning Spotify’s authorization control flow, redirects you to their logon page
- getToken
- Required for the initial authorization as it returns the refresh token
- refreshToken
- Provided the refresh token it will return the access token for the Spotify API
- This is called every hour as the token expires
- currentlyPlaying
- Provided the access token it will return the url for the image of the currently playing song’s album cover.
- image
- this function downloads an image from a provided url and converts it to an indexed bitmap with 15 colours and returns the image as a buffer to be downloaded by the device.
In an attempt to reduce traffic to the server, functions such as currentlyPlaying can be ran locally on the device, however in the end for the device to appear responsive it will need to update about every 5 seconds. If the devices sole functionality is displaying album covers, then this solution would work as my server would only need to be hit for authorization and for the image processing. Unfortunately as the new model has intended uses such as showing gifs, user uploaded photos, and widgets such as weather and hockey scores, the device will need to constantly ask what state the user has set.
Firebase has 2 million requests for free per month - $0.40 per million after. A device checking for update every 5 seconds will make 17,280 a day and 518,400 requests a month and cost me ~$0.20 a month in usage fees after exhausting the free tier in firebase, making this not the most scaleable solution.
Progress
Research MQTT
MQTT is far more suited for this purpose. Its a lightweight communication protocol in which clients can “subscribe” to “feeds” that other clients “publish” to. In this case there will be a state feed that the device is subscribed to where when a user changes the input to the device, such as a new gif or widget, the app will publish the state change to that feed. MQTT will allow for the fastest updating to the device as it has 100% on time without the device polling a server.
To use this protocol, an MQTT broker is required. I have some limited experience using Adafruit’s MQTT service: adafruit.io, however I think it will be better experience using an industry grade broker such as EMQX. Rather than charging per request, MQTT brokers seem to charge per “session minute”, EMQX provides 1 million free session minutes each month, enough to keep 23 devices online 24x7 for 30 days. This is likely more devices than I will ever produce, however if the free tier is exhausted it will only cost me ~$0.09 per month to support addition devices.
EMQX also allows for 1GB of free transfers and $0.15 per GB after. I am not sure if MQTT is suited for this purpose but I could potentially send images using this service as well, however I have not researched the serverless vs. server implementations yet. Using firebase for image manipulation in conjunction with this may be more practical.
Pivot to AWS
The cloud functionality of this project requires three distinct components.
- An image conversion endpoints that can receive a user uploaded image, performs manipulations such as resizing, jpeg compression, and frame splitting for gifs.
- A storage service that receives those processed images and makes them available for device to download
- A MQTT service