Skip to content

krwenholz/simple-scheduler

Repository files navigation

Getting started

Do you want to run this? You'll need:

  • An AWS account and some permissions for two DynamoDB tables ** One table, "simple-scheduler-users", with a string hash key, username, and a string range key, type ** Another table, "simple-scheduler-events", with a string hash key, username, and a number range key, starttime
  • An IAM user with permissions for the dynamodb tables on your host
  • Add the lambda function in the lambdas folder to an AWS Lambda function reacting to streams off of the simple-scheduler-events table.
  • Clone this repo, run "node install", "bower install", and "pip install" (I highly recommend using a virtual environment for pip)
  • You should now be able to run "python application.py" and navigate to localhost:5000

In a less time pressured world, this would be set up for you with a nice script and run in the Docker file. It's almost there, but AWS configurations and permissions are hard.

Thoughts and musings

Given the time constraints (spare time over less than two weeks), I'm reasonably happy with how this turned out. I've built a solid REST interface on a framework I'm only cursorily familiar with and come up with an architecture I can easily extend:

  • Flask provides the REST APIs sitting on top of two DynamoDB tables: one for users and another for "events"
  • A Lambda function reads the stream of events from DynamoDB and keeps user event lists in sync. This way, a user only has to wait on one write to the events table, enabling a faster and more robust API.
  • The UI is currently a weak Jinja2 (more later) implementation that doesn't really need to know anything about the underlying implementations.

So why is that easily extensible? The REST interface makes it so I can build any UI I want. I went with Jinja2 because it was fast and I was running out of time. (I haven't used Jinja2 before, but I now realize much of my UI experience is baked into Amazon internal tools.) The other major component is the use of Lambda: by feeding off of the event stream from DynamoDB, I can asynchronously add all sorts of functionality including emails, iCal publishing, etc.

The primary areas this falls short are in regards to the UI (already shamefully addressed) and the "production readiness". I should be using some proper Python logging to get messages in the correct places, recording metrics on my DynamoDB dependency and my response times, and recording client side metrics. I also struggled getting Docker (new to me) to bend to my will. I'm reasonably happy with how this is deploying, but it could use some work to be a light operational burden: AWS configuration with something like Terraform, monitors, proper logging, a continuous deployment mechanism (I experimented with CodePipelines, but it wasn't up to the task).

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published