caseyjohnsonwv / playlist-pigeon Goto Github PK

The converter Lambda needs the functionality to actually convert songs between Spotify and Apple Music. Incoming requests will contain the below payload - this is not currently being validated by API Gateway (#6).

{
  "source_service" : "spotify",
  "target_service" : "apple",
  "playlist_name" : "my spotify playlist",
  "track_list" : [
    "track-1-uuid",
    "track-2-uuid",
    "track-3-uuid",
  ]
}

Approximately. I'm sure this will need tweaking. Ideally the converter Lambda would work without credentials, only using public search APIs. The whole point of the asynchronous architecture is to stay within API rate limits from Spotify and Apple.

MVP:

1. Look up each track on the source service for its name and artist
2. Look up each track on the target service for its new UUID
3. Create a JSON file mapping UUIDs to UUIDs, source to target (eg, "track-1-uuid-spotify" : "track-1-uuid-apple")
4. Use the already implemented logic to upload the file to S3

Targeting this infrastructure:

Need to stand up a bunch of stuff with Terraform:

• API Gateway
• /v1/convert
• Job Queue
• Frontend Bucket
• Playlist Bucket
• Converter Lambda
• Retrieval Lambda

Even if the code in the Lambdas does nothing etc etc, it would be good to get all these services talking to each other before proceeding with actual application code.

Here is the cost estimate I threw together for this architecture (using some pretty wild numbers just to be safe).

Keep getting an error stating the integration method identifier is not valid. Same issue occurs whether hardcoded or using aws_api_gateway_method.<whatever>.http_method reference. Read a few issues / answers online about possibly needing some depends_on blocks to make it work - may be an issue with the AWS Terraform provider.

Sometimes a song is available on Spotify but not Apple & vice versa. The app should doing something to tell users about this. Currently these songs are simply omitted from the target playlist.

I'm imagining a very simple Vue.js SPA. On desktop, it's two halves - one for converting playlists, one for retrieving. On mobile, they're stacked with convert on top and retrieve below.

The UI needs a few key capabilities:

• Authentication to both Apple Music and Spotify
• Ability to create a playlist in the user's library and add songs to it
• GET & POST request functionality to /v1/convert on API Gateway
• Pop-up with conversion's Job ID for sharing with friends - can this be a shareable link?

This library looks promising for Spotify - not sure what's out there for Apple Music yet.

The API Gateway is not configured to validate incoming requests. Once #5 is implemented, it would be good to add a Model that validates request bodies. There's really no point in doing it sooner because the schema may change.

Modify the build script to allow --frontend and --backend flags (both is the default, but passing only one omits the other). Then add functionality to build the frontend code for deployment. Upload it to S3 with Terraform's aws_s3_object resource. This depends on at least the beginning of #9.

May be related to #2 - seems to be an issue with the API being deployed before all of its methods, responses, etc are created. May need to add explicit depends_on blocks to make everything work in order.

We don't need to keep every playlist ever converted - set a lifecycle policy on the playlist JSON bucket to delete items after some time. A day sounds good to me.

The build script currently downloads linux-x86-64 dependencies to the main source code folders. These dependencies are not deleted, which creates some funky behavior - Windows doesn't like all of the Linux dependencies.

There are also local .env files etc in these directories - it makes sense to refactor build.py. For each directory it builds:

1. Create a temp directory
2. Move every non-gitignore'd file there
3. Install Linux dependencies there
4. Zip the temp folder
5. Delete the temp folder

This is inhibiting #5, though not completely blocking its progress.

Currently setting environment variables on the Lambda functions. This is fine for testing, but before anything is public, all credentials should be moved to human-managed AWS secrets. The Lambda functions should be refactored to reference these if no environment configuration is present.

Due to IAM errors when creating the log group manually, I have allowed Lambda to create its own log groups. These log groups need to have a 1-day retention policy applied to them. They will likely have to be created separately with access granted to Lambda functions.

API Gateway is currently doing no request validation. At minimum, it should:

• Use a shared secret or API key to ensure requests are coming from the frontend.
• Require requests to come from a valid IAM role that is assumed by the frontend S3 bucket.

This should be implemented after #9.