Developing with Flask and AWS Lambda: Intro

Posted on Fri 15 September 2017 in technical

This is the first in a series of blog posts intended to examine some challenges I encountered while writing a RESTful key-value store application for the coding exercise portion of a job interview. Each post in the series will focus on a specific challenge I encountered by describing:

  • the problem
  • my approach to solving the problem, including alternative solutions considered
  • specifics of and rationale behind the solution i chose
  • additional problems, if any, that arose from the chosen solution

But first, I should begin with some background. A couple weeks ago I began interviewing with a development team that was looking for a Python developer; they wanted experience with or the capability of learning how to write, test, and deploy AWS Lambda based applications written in Python. During the initial phone screen with the team lead, I did my best to make the following clear:

  • I have relatively little experience with AWS in general
  • I had no experience whatsover with AWS API Gateway or AWS Lambda
  • My background largely consisted of "DevOps"/SRE/automation work, although I have made solid efforts over the past few years to transition into more of a software development role.

Despite such admonitions regarding my lack of experience, after chatting with the team lead, I was sent a coding challenge intended to gauge both my preexisting Python development experience as well as my ability to wrap my head around AWS API Gateway and AWS Lambda.

As a side note, I'm really not personally too keen on giving in to the growing marketshare of computational power by giants like Google, Microsoft, AWS, etc. However, I understand that the fast-paced, competitive nature of the business world doesn't hold space for consideration of the kind of personal ideals that lead to concerns like mine; and realistically, the job market will shift one way or another with or without my personal approval. I'll make a note to address this in a maybe more meandering quasi-philosophical rant blag post another day.

That said, I did see this as an opportunity to practice my software design and programming skills; I love coding challenges as part of interview processes precisely for this reason. (I suspect my attitude would be different if I were working full time while interviewing for jobs; but this summer I have been full-time job searching and this is the third coding challenge to which I have committed serious concerted effort)

Anyway, the requirements for this app were as follows:

Implement the requirements below to create a basic key/value service:
  * uses Python
  * create a RESTful API, we suggest using AWS Lambda or Flask but use
    whatever you are comfortable with.
    * the route should be something like /key but should be versionable
    * show some example uses of the service; use cases:
      * user should be able to get all keys/values
      * user should be able to get a specific key/value
      * user should be able to add a key/value
      * user should be able to update a key/value
      * user should be able to delete a key/value
      * enable the use of 2 different backing stores of your choice. they can
        use real data stores or be mocked out to represent. which one is used
        should be determined via configuration
  * demonstrate asynchronous handling
    * simultaneous (make 2 or more calls that are processed asynchronously and
      when all calls complete results are compiled to a single result object
      which is returned)
    * chained (make a call the result of which informs a subsequent call)
  * The code should be runnable and have some form of demonstration. For
    example, a user would add a key of 'sports', its value the list of
    'baseball', 'hockey' and 'football'.
  * The code should have automated tests
  * Share via code repository or zip (repo preferred)

Here's the solution I came up with:

The key-value store app itself is really nothing to get excited about. What I think is most interesting about it and where I put the most amount of effort is in the test fixture setup. With that in mind, this series of blog posts (of which this is the first) will largely cover my approach to testing the application, with references to the application code itself kept to a minimum. Tentatively speaking, this series will include roughly the following topics organized into a rough weekly publication schedule:

  • Week 0: Developing with Flask and AWS Lambda: Intro (this post)
  • Week 1: Project management; technology stack selection; initial project setup
  • Week 2: Analyzing the requirements for testability; test early, test often
  • Week 3: Abstractions: the lifeblood of reusable code and other such musings
  • Week 4: Pytest fixtures: now with hacky multiple dispatch
  • Week 5: Adapting WebTest and WSGIProxy2 to my way of thinking
  • Week 6: Hacking the Zappa CLI for fun and profit

And that's it for this post! Apologies for not yet having set up any kind of comment system on this blag. Maybe I'll work on that in the near future...