Tag Archives: Zappa

App Infrastructure, Tools

Deployment

Deploying a Python app isn’t as simple as uploading and installing PHP apps such as WordPress. WordPress is installed on a server and database, but with Python you need to supply all that yourself. I have done much of the development on CodeAnywhere which can provide a container, a virtual computer which is fired up when you want to use it which is suitable for testing purposes. Flask creates a very lightweight web server but it isn’t suitable for production use, so a more robust solution needs to be found.

As already mentioned the developer needs to organise a rented virtual computer with server software and a database. I have set up a database on MongoDB provider MLab instead of installing MongoDB on the development container, as then I don’t have to change anything when deploying to a publicly accessible URL. A traditional web server is online 100% of the time and processes HTTP requests as they come in, some of which will time out (Jones, 2018). Plus it is a long process to set up a server from scratch.

Serverless

Many web apps can now be deployed using third-party services and “custom code run on ephemeral containers” (Maruti Techlabs, 2017) such as Amazon Web Services’ Lambda. Zappa is a tool that makes it easy to run Python web apps on Lambda. From the documentation:

“With Zappa, each request is given its own virtual HTTP “server” by Amazon API Gateway. AWS handles the horizontal scaling automatically, so no requests ever time out. Each request then calls your application from a memory cache in AWS Lambda and returns the response via Python’s WSGI interface. After your app returns, the “server” dies.” (Jones, 2018)

CianTube is already using a third-party database and the YouTube API so it is a good candidate for using Lambda to serve the core app.

I cloned the app from GitHub and installed it on my Mac as I needed to install the AWS credentials on the machine that the app is running on locally and I couldn’t do that on the CodeAnywhere container. Zappa needs to be installed in a Virtual Environment, which isolates the app from the rest of the system so it can’t do any damage if anything goes wrong. Once this is done, the terminal command zappa init sets up the deployment settings, including defining one or more stages so you can run an app on the web without exposing it to users before it is properly tested.

To deploy the app the command zappa deploy stagename is used, which packages and uploads the local files, and when complete the URL of the app is displayed. To update, the command zappa update production is used.

zappa

I did this and the app worked on the web without a problem.

zappa_web

References

Maruti Techlabs. (2017). What is Serverless Architecture? What are its criticisms and drawbacks?. [online] Available at: https://medium.com/@MarutiTech/what-is-serverless-architecture-what-are-its-criticisms-and-drawbacks-928659f9899a [Accessed 24 Apr. 2018].

Jones, R. (2018). Miserlou/Zappa. [online] Available at: https://github.com/Miserlou/Zappa#about [Accessed 24 Apr. 2018].

Standard
App Infrastructure

Scheduling actions

Structure of the App

  1. Flask web app
  2. Grabber – fetches video IDs from a specified YouTube Playlist and saves them as JSON files
  3. Loader – loads video IDs and the ID of the device that added the playlist into the database

Functionality

The app needs to be able to ingest playlist URLs and work with them at regular intervals.

  1. When someone enters a new playlist
    1. Run Grabber
    2. Run Loader
  2. When someone returns to the app
    1. Run Grabber
    2. Run Loader
  3. At intervals
    1. Run Grabber
    2. Run Loader

Possibilities

Things to consider

  • Running concurrently – as the app gets more widely used, waiting for one user’s videos to be included before another’s can start (running serially) will be inconvenient.
  • How long does it take? If it’s too long I may need to store when videos were last checked for and only bring in those added since then.
  • Running Grabber and Loader at intervals is relatively unimportant, it’s utility would be for when a parent is actively adding videos to a playlist while the child is using it.
  • Should Grabber and Loader be added to the main app as functions?

  • Do I need to refactor the app into separate files? I’m reluctant to do that as it’s actually working now.

Standard
App Infrastructure

Workflow

I have the app set up both on my CodeAnywhere container and my Mac, with both connected to the same GitHub repository, so I can work on them from anywhere.

Zappa enables you to set up several stages, for example /dev, /staging and /production, and once the initial setup is done, the app can just be deployed by entering zappa deploy STAGENAME in Terminal. It can be updated with zappa update STAGENAME.

I don’t have Zappa installed on the CodeAnywhere container as the AWS login credentials method is a bit complicated for a terminal-only container, so to deploy changes made on there from my Mac I need to get the changes from GitHub with the command git pull origin master.

Standard