Top Charts Spotify

By: Douglas Read

Purpose of the App

The purpose of creating this Spotify App is to make a personal chart that mimics the Billboard Hot 100. This would offer a fun and engaging way for a user to track their music habits over time. Like the Hot 100, the "tracking week" will stop at 12 PM EST on Fridays and charts will drop on Tuesdays. In the future, this app will expand to allow for creating "Groups" which will enable a friends to have a shared chart.

Backend Architecture

Notes of the Spotify API

Per the Spotify documentation, this app should use the Authorization code method of authenticating as it will access user resources on the server-side.

Additionally, it is important to note that Spotify limits the number of requests a user can make to their API. Though the rate varies, it typically limits an application to around 180 requests per minute. Our use case is going to require several API hits per user to accurately construct a chart over the past week. To not run into issues with rate-limiting, we will schedule data collection and distribute collection over the Friday-Monday timeframe.

Architectural Diagram

Why this Architecture Was Chosen

Given that this is currently a side project and I would like it to cost little to no money... I figured the most rationale design would leverage a serverless architecture and heavily utilize lambdas which do not need to always be running. Additionally, the small scoping and isolation of individual components helps ensure the design will be fault-tolerant and maintainable.

Notes on the Diagram

At a high level, a user authenticates with AWS Cognito and queries AWS AppSync for information that populates user fields, charts, and other things in the application. AWS Cognito will fire a trigger during account creation to get the user's approval for the application to collect their Spotify data. When sign up is completed, Cognito will trigger a different lambda to asynchronously start to collect data for a user's past week.

At a high level the SQS queues and SNS topics are used to schedule and distribute the number of requests made to the Spotify API. After 12 PM EST on Fridays, there will be an event bridge rule which triggers a lambda. The purpose of this lambda will be to query active users and enqueue "data refresh requests" to an SQS queue. At a to be determined frequency (but one that keeps us under the rate-limit), another lambda will read from this SQS queue and publish to an SNS topic. Finally, another lambda will be triggered by this message to do the data collection and normalize/persist it.