Serverless Python

Overview

Zappa Rocks!

Zappa - Serverless Python

Build Status Coverage PyPI Slack Gun.io Patreon

About

Zappa Slides

In a hurry? Click to see (now slightly out-dated) slides from Serverless SF!

Zappa makes it super easy to build and deploy server-less, event-driven Python applications (including, but not limited to, WSGI web apps) on AWS Lambda + API Gateway. Think of it as "serverless" web hosting for your Python apps. That means infinite scaling, zero downtime, zero maintenance - and at a fraction of the cost of your current deployments!

If you've got a Python web app (including Django and Flask apps), it's as easy as:

$ pip install zappa
$ zappa init
$ zappa deploy

and now you're server-less! Wow!

What do you mean "serverless"?

Okay, so there still is a server - but it only has a 40 millisecond life cycle! Serverless in this case means "without any permanent infrastructure."

With a traditional HTTP server, the server is online 24/7, processing requests one by one as they come in. If the queue of incoming requests grows too large, some requests will time out. 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.

Better still, with Zappa you only pay for the milliseconds of server time that you use, so it's many orders of magnitude cheaper than VPS/PaaS hosts like Linode or Heroku - and in most cases, it's completely free. Plus, there's no need to worry about load balancing or keeping servers online ever again.

It's great for deploying serverless microservices with frameworks like Flask and Bottle, and for hosting larger web apps and CMSes with Django. Or, you can use any WSGI-compatible app you like! You probably don't need to change your existing applications to use it, and you're not locked into using it.

Zappa also lets you build hybrid event-driven applications that can scale to trillions of events a year with no additional effort on your part! You also get free SSL certificates, global app deployment, API access management, automatic security policy generation, precompiled C-extensions, auto keep-warms, oversized Lambda packages, and many other exclusive features!

And finally, Zappa is super easy to use. You can deploy your application with a single command out of the box!

Awesome!

Zappa Demo Gif

Installation and Configuration

Before you begin, make sure you are running Python 3.6/3.7/3.8 and you have a valid AWS account and your AWS credentials file is properly installed.

Zappa can easily be installed through pip, like so:

$ pip install zappa

Please note that Zappa must be installed into your project's virtual environment. The virtual environment name should not be the same as the Zappa project name, as this may cause errors.

(If you use pyenv and love to manage virtualenvs with pyenv-virtualenv, you just have to call pyenv local [your_venv_name] and it's ready. Conda users should comment here.)

Next, you'll need to define your local and server-side settings.

Running the Initial Setup / Settings

Zappa can automatically set up your deployment settings for you with the init command:

$ zappa init

This will automatically detect your application type (Flask/Django - Pyramid users see here) and help you define your deployment configuration settings. Once you finish initialization, you'll have a file named zappa_settings.json in your project directory defining your basic deployment settings. It will probably look something like this for most WSGI apps:

{
    // The name of your stage
    "dev": {
        // The name of your S3 bucket
        "s3_bucket": "lambda",

        // The modular python path to your WSGI application function.
        // In Flask and Bottle, this is your 'app' object.
        // Flask (your_module.py):
        // app = Flask()
        // Bottle (your_module.py):
        // app = bottle.default_app()
        "app_function": "your_module.app"
    }
}

or for Django:

{
    "dev": { // The name of your stage
       "s3_bucket": "lambda", // The name of your S3 bucket
       "django_settings": "your_project.settings" // The python path to your Django settings.
    }
}

Psst: If you're deploying a Django application with Zappa for the first time, you might want to read Edgar Roman's Django Zappa Guide.

You can define as many stages as your like - we recommend having dev, staging, and production.

Now, you're ready to deploy!

Basic Usage

Initial Deployments

Once your settings are configured, you can package and deploy your application to a stage called "production" with a single command:

$ zappa deploy production
Deploying..
Your application is now live at: https://7k6anj0k99.execute-api.us-east-1.amazonaws.com/production

And now your app is live! How cool is that?!

To explain what's going on, when you call deploy, Zappa will automatically package up your application and local virtual environment into a Lambda-compatible archive, replace any dependencies with versions precompiled for Lambda, set up the function handler and necessary WSGI Middleware, upload the archive to S3, create and manage the necessary Amazon IAM policies and roles, register it as a new Lambda function, create a new API Gateway resource, create WSGI-compatible routes for it, link it to the new Lambda function, and finally delete the archive from your S3 bucket. Handy!

Be aware that the default IAM role and policy created for executing Lambda applies a liberal set of permissions. These are most likely not appropriate for production deployment of important applications. See the section Custom AWS IAM Roles and Policies for Execution for more detail.

Updates

If your application has already been deployed and you only need to upload new Python code, but not touch the underlying routes, you can simply:

$ zappa update production
Updating..
Your application is now live at: https://7k6anj0k99.execute-api.us-east-1.amazonaws.com/production

This creates a new archive, uploads it to S3 and updates the Lambda function to use the new code, but doesn't touch the API Gateway routes.

Rollback

You can also rollback the deployed code to a previous version by supplying the number of revisions to return to. For instance, to rollback to the version deployed 3 versions ago:

$ zappa rollback production -n 3

Scheduling

Zappa can be used to easily schedule functions to occur on regular intervals. This provides a much nicer, maintenance-free alternative to Celery! These functions will be packaged and deployed along with your app_function and called from the handler automatically. Just list your functions and the expression to schedule them using cron or rate syntax in your zappa_settings.json file:

{
    "production": {
       ...
       "events": [{
           "function": "your_module.your_function", // The function to execute
           "expression": "rate(1 minute)" // When to execute it (in cron or rate format)
       }],
       ...
    }
}

And then:

$ zappa schedule production

And now your function will execute every minute!

If you want to cancel these, you can simply use the unschedule command:

$ zappa unschedule production

And now your scheduled event rules are deleted.

See the example for more details.

Advanced Scheduling

Sometimes a function needs multiple expressions to describe its schedule. To set multiple expressions, simply list your functions, and the list of expressions to schedule them using cron or rate syntax in your zappa_settings.json file:

{
    "production": {
       ...
       "events": [{
           "function": "your_module.your_function", // The function to execute
           "expressions": ["cron(0 20-23 ? * SUN-THU *)", "cron(0 0-8 ? * MON-FRI *)"] // When to execute it (in cron or rate format)
       }],
       ...
    }
}

This can be used to deal with issues arising from the UTC timezone crossing midnight during business hours in your local timezone.

It should be noted that overlapping expressions will not throw a warning, and should be checked for, to prevent duplicate triggering of functions.

Undeploy

If you need to remove the API Gateway and Lambda function that you have previously published, you can simply:

$ zappa undeploy production

You will be asked for confirmation before it executes.

If you enabled CloudWatch Logs for your API Gateway service and you don't want to keep those logs, you can specify the --remove-logs argument to purge the logs for your API Gateway and your Lambda function:

$ zappa undeploy production --remove-logs

Package

If you want to build your application package without actually uploading and registering it as a Lambda function, you can use the package command:

$ zappa package production

If you have a zip callback in your callbacks setting, this will also be invoked.

{
    "production": { // The name of your stage
        "callbacks": {
            "zip": "my_app.zip_callback"// After creating the package
        }
    }
}

You can also specify the output filename of the package with -o:

$ zappa package production -o my_awesome_package.zip

How Zappa Makes Packages

Zappa will automatically package your active virtual environment into a package which runs smoothly on AWS Lambda.

During this process, it will replace any local dependencies with AWS Lambda compatible versions. Dependencies are included in this order:

  • Lambda-compatible manylinux wheels from a local cache
  • Lambda-compatible manylinux wheels from PyPI
  • Lambda-specific versions from lambda-package
  • Packages from the active virtual environment
  • Packages from the local project directory

It also skips certain unnecessary files, and ignores any .py files if .pyc files are available.

In addition, Zappa will also automatically set the correct execution permissions, configure package settings, and create a unique, auditable package manifest file.

To further reduce the final package file size, you can:

Template

Similarly to package, if you only want the API Gateway CloudFormation template, use the template command:

$ zappa template production --l your-lambda-arn -r your-role-arn

Note that you must supply your own Lambda ARN and Role ARNs in this case, as they may not have been created for you.

You can get the JSON output directly with --json, and specify the output file with --output.

Status

If you need to see the status of your deployment and event schedules, simply use the status command.

$ zappa status production

Tailing Logs

You can watch the logs of a deployment by calling the tail management command.

$ zappa tail production

By default, this will show all log items. In addition to HTTP and other events, anything printed to stdout or stderr will be shown in the logs.

You can use the argument --http to filter for HTTP requests, which will be in the Apache Common Log Format.

$ zappa tail production --http

Similarly, you can do the inverse and only show non-HTTP events and log messages:

$ zappa tail production --non-http

If you don't like the default log colors, you can turn them off with --no-color.

You can also limit the length of the tail with --since, which accepts a simple duration string:

$ zappa tail production --since 4h # 4 hours
$ zappa tail production --since 1m # 1 minute
$ zappa tail production --since 1mm # 1 month

You can filter out the contents of the logs with --filter, like so:

$ zappa tail production --http --filter "POST" # Only show POST HTTP requests

Note that this uses the CloudWatch Logs filter syntax.

To tail logs without following (to exit immediately after displaying the end of the requested logs), pass --disable-keep-open:

$ zappa tail production --since 1h --disable-keep-open

Remote Function Invocation

You can execute any function in your application directly at any time by using the invoke command.

For instance, suppose you have a basic application in a file called "my_app.py", and you want to invoke a function in it called "my_function". Once your application is deployed, you can invoke that function at any time by calling:

$ zappa invoke production 'my_app.my_function'

Any remote print statements made and the value the function returned will then be printed to your local console. Nifty!

You can also invoke interpretable Python 3.6/3.7/3.8 strings directly by using --raw, like so:

$ zappa invoke production "print(1 + 2 + 3)" --raw

For instance, it can come in handy if you want to create your first superuser on a RDS database running in a VPC (like Serverless Aurora): $ zappa invoke staging "from django.contrib.auth import get_user_model; User = get_user_model(); User.objects.create_superuser('username', 'email', 'password')" --raw

Django Management Commands

As a convenience, Zappa can also invoke remote Django 'manage.py' commands with the manage command. For instance, to perform the basic Django status check:

$ zappa manage production showmigrations admin

Obviously, this only works for Django projects which have their settings properly defined.

For commands which have their own arguments, you can also pass the command in as a string, like so:

$ zappa manage production "shell --version"

Commands which require direct user input, such as createsuperuser, should be replaced by commands which use zappa invoke <env> --raw.

For more Django integration, take a look at the zappa-django-utils project.

(Please note that commands which take over 30 seconds to execute may time-out preventing output from being returned - but the command may continue to run. See this related issue for a work-around.)

SSL Certification

Zappa can be deployed to custom domain names and subdomains with custom SSL certificates, Let's Encrypt certificates, and AWS Certificate Manager (ACM) certificates.

Currently, the easiest of these to use are the AWS Certificate Manager certificates, as they are free, self-renewing, and require the least amount of work.

Once configured as described below, all of these methods use the same command:

$ zappa certify

When deploying from a CI/CD system, you can use:

$ zappa certify --yes

to skip the confirmation prompt.

Deploying to a Domain With AWS Certificate Manager

Amazon provides their own free alternative to Let's Encrypt called AWS Certificate Manager (ACM). To use this service with Zappa:

  1. Verify your domain in the AWS Certificate Manager console.
  2. In the console, select the N. Virginia (us-east-1) region and request a certificate for your domain or subdomain (sub.yourdomain.tld), or request a wildcard domain (*.yourdomain.tld).
  3. Copy the entire ARN of that certificate and place it in the Zappa setting certificate_arn.
  4. Set your desired domain in the domain setting.
  5. Call $ zappa certify to create and associate the API Gateway distribution using that certificate.

Deploying to a Domain With a Let's Encrypt Certificate (DNS Auth)

If you want to use Zappa on a domain with a free Let's Encrypt certificate using automatic Route 53 based DNS Authentication, you can follow this handy guide.

Deploying to a Domain With a Let's Encrypt Certificate (HTTP Auth)

If you want to use Zappa on a domain with a free Let's Encrypt certificate using HTTP Authentication, you can follow this guide.

However, it's now far easier to use Route 53-based DNS authentication, which will allow you to use a Let's Encrypt certificate with a single $ zappa certify command.

Deploying to a Domain With Your Own SSL Certs

  1. The first step is to create a custom domain and obtain your SSL cert / key / bundle.
  2. Ensure you have set the domain setting within your Zappa settings JSON - this will avoid problems with the Base Path mapping between the Custom Domain and the API invoke URL, which gets the Stage Name appended in the URI
  3. Add the paths to your SSL cert / key / bundle to the certificate, certificate_key, and certificate_chain settings, respectively, in your Zappa settings JSON
  4. Set route53_enabled to false if you plan on using your own DNS provider, and not an AWS Route53 Hosted zone.
  5. Deploy or update your app using Zappa
  6. Run $ zappa certify to upload your certificates and register the custom domain name with your API gateway.

Executing in Response to AWS Events

Similarly, you can have your functions execute in response to events that happen in the AWS ecosystem, such as S3 uploads, DynamoDB entries, Kinesis streams, SNS messages, and SQS queues.

In your zappa_settings.json file, define your event sources and the function you wish to execute. For instance, this will execute your_module.process_upload_function in response to new objects in your my-bucket S3 bucket. Note that process_upload_function must accept event and context parameters.

{
    "production": {
       ...
       "events": [{
            "function": "your_module.process_upload_function",
            "event_source": {
                  "arn":  "arn:aws:s3:::my-bucket",
                  "events": [
                    "s3:ObjectCreated:*" // Supported event types: http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html#supported-notification-event-types
                  ]
               }
            }],
       ...
    }
}

And then:

$ zappa schedule production

And now your function will execute every time a new upload appears in your bucket!

To access the key's information in your application context, you'll want process_upload_function to look something like this:

import boto3
s3_client = boto3.client('s3')

def process_upload_function(event, context):
    """
    Process a file upload.
    """

    # Get the uploaded file's information
    bucket = event['Records'][0]['s3']['bucket']['name'] # Will be `my-bucket`
    key = event['Records'][0]['s3']['object']['key'] # Will be the file path of whatever file was uploaded.

    # Get the bytes from S3
    s3_client.download_file(bucket, key, '/tmp/' + key) # Download this file to writable tmp space.
    file_bytes = open('/tmp/' + key).read()

Similarly, for a Simple Notification Service event:

        "events": [
            {
                "function": "your_module.your_function",
                "event_source": {
                    "arn":  "arn:aws:sns:::your-event-topic-arn",
                    "events": [
                        "sns:Publish"
                    ]
                }
            }
        ]

Optionally you can add SNS message filters:

        "events": [
            {
                "function": "your_module.your_function",
                "event_source": {
                    "arn":  "arn:aws:sns:::your-event-topic-arn",
                    "filters": {
                        "interests": ["python", "aws", "zappa"],
                        "version": ["1.0"]
                    },
                    ...
                }
            }
        ]

DynamoDB and Kinesis are slightly different as it is not event based but pulling from a stream:

       "events": [
           {
               "function": "replication.replicate_records",
               "event_source": {
                    "arn":  "arn:aws:dynamodb:us-east-1:1234554:table/YourTable/stream/2016-05-11T00:00:00.000",
                    "starting_position": "TRIM_HORIZON", // Supported values: TRIM_HORIZON, LATEST
                    "batch_size": 50, // Max: 1000
                    "enabled": true // Default is false
               }
           }
       ]

SQS is also pulling messages from a stream. At this time, only "Standard" queues can trigger lambda events, not "FIFO" queues. Read the AWS Documentation carefully since Lambda calls the SQS DeleteMessage API on your behalf once your function completes successfully.

       "events": [
           {
               "function": "your_module.process_messages",
               "event_source": {
                    "arn":  "arn:aws:sqs:us-east-1:12341234:your-queue-name-arn",
                    "batch_size": 10, // Max: 10. Use 1 to trigger immediate processing
                    "enabled": true // Default is false
               }
           }
       ]

For configuring Lex Bot's intent triggered events:

    "bot_events": [
        {
            "function": "lexbot.handlers.book_appointment.handler",
            "event_source": {
                "arn": "arn:aws:lex:us-east-1:01234123123:intent:TestLexEventNames:$LATEST", // optional. In future it will be used to configure the intent
                "intent":"intentName", // name of the bot event configured
                "invocation_source":"DialogCodeHook", // either FulfillmentCodeHook or DialogCodeHook
            }
        }
    ]

Events can also take keyword arguments:

       "events": [
            {
                "function": "your_module.your_recurring_function", // The function to execute
                "kwargs": {"key": "val", "key2": "val2"},  // Keyword arguments to pass. These are available in the event
                "expression": "rate(1 minute)" // When to execute it (in cron or rate format)
            }
       ]

To get the keyword arguments you will need to look inside the event dictionary:

def your_recurring_function(event, context):
    my_kwargs = event.get("kwargs")  # dict of kwargs given in zappa_settings file

You can find more example event sources here.

Asynchronous Task Execution

Zappa also now offers the ability to seamlessly execute functions asynchronously in a completely separate AWS Lambda instance!

For example, if you have a Flask API for ordering a pie, you can call your bake function seamlessly in a completely separate Lambda instance by using the zappa.asynchronous.task decorator like so:

from flask import Flask
from zappa.asynchronous import task
app = Flask(__name__)

@task
def make_pie():
    """ This takes a long time! """
    ingredients = get_ingredients()
    pie = bake(ingredients)
    deliver(pie)

@app.route('/api/order/pie')
def order_pie():
    """ This returns immediately! """
    make_pie()
    return "Your pie is being made!"

And that's it! Your API response will return immediately, while the make_pie function executes in a completely different Lambda instance.

When calls to @task decorated functions or the zappa.asynchronous.run command occur outside of Lambda, such as your local dev environment, the functions will execute immediately and locally. The zappa asynchronous functionality only works when in the Lambda environment or when specifying Remote Invocations.

Catching Exceptions

Putting a try..except block on an asynchronous task like this:

@task
def make_pie():
    try:
        ingredients = get_ingredients()
        pie = bake(ingredients)
        deliver(pie)
    except Fault as error:
        """send an email"""
    ...
    return Response('Web services down', status=503)

will cause an email to be sent twice for the same error. See asynchronous retries at AWS. To work around this side-effect, and have the fault handler execute only once, change the return value to:

@task
def make_pie():
    try:
        """code block"""
    except Fault as error:
        """send an email"""
    ...
    return {} #or return True

Task Sources

By default, this feature uses direct AWS Lambda invocation. You can instead use AWS Simple Notification Service as the task event source by using the task_sns decorator, like so:

from zappa.asynchronous import task_sns
@task_sns

Using SNS also requires setting the following settings in your zappa_settings:

{
  "dev": {
    ..
      "async_source": "sns", // Source of async tasks. Defaults to "lambda"
      "async_resources": true, // Create the SNS topic to use. Defaults to true.
    ..
    }
}

This will automatically create and subscribe to the SNS topic the code will use when you call the zappa schedule command.

Using SNS will also return a message ID in case you need to track your invocations.

Direct Invocation

You can also use this functionality without a decorator by passing your function to zappa.asynchronous.run, like so:

from zappa.asynchronous import run

run(your_function, args, kwargs) # Using Lambda
run(your_function, args, kwargs, service='sns') # Using SNS

Remote Invocations

By default, Zappa will use lambda's current function name and current AWS region. If you wish to invoke a lambda with a different function name/region or invoke your lambda from outside of lambda, you must specify the remote_aws_lambda_function_name and remote_aws_region arguments so that the application knows which function and region to use. For example, if some part of our pizza making application had to live on an EC2 instance, but we wished to call the make_pie() function on its own Lambda instance, we would do it as follows:

@task(remote_aws_lambda_function_name='pizza-pie-prod', remote_aws_region='us-east-1')
def make_pie():
   """ This takes a long time! """
   ingredients = get_ingredients()
   pie = bake(ingredients)
   deliver(pie)

If those task() parameters were not used, then EC2 would execute the function locally. These same remote_aws_lambda_function_name and remote_aws_region arguments can be used on the zappa.asynchronous.run() function as well.

Restrictions

The following restrictions to this feature apply:

  • Functions must have a clean import path -- i.e. no closures, lambdas, or methods.
  • args and kwargs must be JSON-serializable.
  • The JSON-serialized arguments must be within the size limits for Lambda (256K) or SNS (256K) events.

All of this code is still backwards-compatible with non-Lambda environments - it simply executes in a blocking fashion and returns the result.

Running Tasks in a VPC

If you're running Zappa in a Virtual Private Cloud (VPC), you'll need to configure your subnets to allow your lambda to communicate with services inside your VPC as well as the public Internet. A minimal setup requires two subnets.

In subnet-a:

  • Create a NAT
  • Create an Internet gateway
  • In the route table, create a route pointing the Internet gateway to 0.0.0.0/0.

In subnet-b:

  • Place your lambda function
  • In the route table, create a route pointing the NAT that belongs to subnet-a to 0.0.0.0/0.

You can place your lambda in multiple subnets that are configured the same way as subnet-b for high availability.

Some helpful resources are this tutorial, this other tutorial and this AWS doc page.

Responses

It is possible to capture the responses of Asynchronous tasks.

Zappa uses DynamoDB as the backend for these.

To capture responses, you must configure a async_response_table in zappa_settings. This is the DynamoDB table name. Then, when decorating with @task, pass capture_response=True.

Async responses are assigned a response_id. This is returned as a property of the LambdaAsyncResponse (or SnsAsyncResponse) object that is returned by the @task decorator.

Example:

from zappa.asynchronous import task, get_async_response
from flask import Flask, make_response, abort, url_for, redirect, request, jsonify
from time import sleep

app = Flask(__name__)

@app.route('/payload')
def payload():
    delay = request.args.get('delay', 60)
    x = longrunner(delay)
    return redirect(url_for('response', response_id=x.response_id))

@app.route('/async-response/<response_id>')
def response(response_id):
    response = get_async_response(response_id)
    if response is None:
        abort(404)

    if response['status'] == 'complete':
        return jsonify(response['response'])

    sleep(5)

    return "Not yet ready. Redirecting.", 302, {
        'Content-Type': 'text/plain; charset=utf-8',
        'Location': url_for('response', response_id=response_id, backoff=5),
        'X-redirect-reason': "Not yet ready.",
    }

@task(capture_response=True)
def longrunner(delay):
    sleep(float(delay))
    return {'MESSAGE': "It took {} seconds to generate this.".format(delay)}

Advanced Settings

There are other settings that you can define in your local settings to change Zappa's behavior. Use these at your own risk!

 {
    "dev": {
        "alb_enabled": false, // enable provisioning of application load balancing resources. If set to true, you _must_ fill out the alb_vpc_config option as well.
        "alb_vpc_config": {
            "CertificateArn": "your_acm_certificate_arn", // ACM certificate ARN for ALB
            "SubnetIds": [], // list of subnets for ALB
            "SecurityGroupIds": [] // list of security groups for ALB
        },
        "api_key_required": false, // enable securing API Gateway endpoints with x-api-key header (default False)
        "api_key": "your_api_key_id", // optional, use an existing API key. The option "api_key_required" must be true to apply
        "apigateway_enabled": true, // Set to false if you don't want to create an API Gateway resource. Default true.
        "apigateway_description": "My funky application!", // Define a custom description for the API Gateway console. Default None.
        "assume_policy": "my_assume_policy.json", // optional, IAM assume policy JSON file
        "attach_policy": "my_attach_policy.json", // optional, IAM attach policy JSON file
        "apigateway_policy": "my_apigateway_policy.json", // optional, API Gateway resource policy JSON file
        "async_source": "sns", // Source of async tasks. Defaults to "lambda"
        "async_resources": true, // Create the SNS topic and DynamoDB table to use. Defaults to true.
        "async_response_table": "your_dynamodb_table_name",  // the DynamoDB table name to use for captured async responses; defaults to None (can't capture)
        "async_response_table_read_capacity": 1,  // DynamoDB table read capacity; defaults to 1
        "async_response_table_write_capacity": 1,  // DynamoDB table write capacity; defaults to 1
        "aws_endpoint_urls": { "aws_service_name": "endpoint_url" }, // a dictionary of endpoint_urls that emulate the appropriate service.  Usually used for testing, for instance with `localstack`.
        "aws_environment_variables" : {"your_key": "your_value"}, // A dictionary of environment variables that will be available to your deployed app via AWS Lambdas native environment variables. See also "environment_variables" and "remote_env" . Default {}.
        "aws_kms_key_arn": "your_aws_kms_key_arn", // Your AWS KMS Key ARN
        "aws_region": "aws-region-name", // optional, uses region set in profile or environment variables if not set here,
        "binary_support": true, // Enable automatic MIME-type based response encoding through API Gateway. Default true.
        "callbacks": { // Call custom functions during the local Zappa deployment/update process
            "settings": "my_app.settings_callback", // After loading the settings
            "zip": "my_app.zip_callback", // After creating the package
            "post": "my_app.post_callback", // After command has executed
        },
        "cache_cluster_enabled": false, // Use APIGW cache cluster (default False)
        "cache_cluster_size": 0.5, // APIGW Cache Cluster size (default 0.5)
        "cache_cluster_ttl": 300, // APIGW Cache Cluster time-to-live (default 300)
        "cache_cluster_encrypted": false, // Whether or not APIGW Cache Cluster encrypts data (default False)
        "certificate": "my_cert.crt", // SSL certificate file location. Used to manually certify a custom domain
        "certificate_key": "my_key.key", // SSL key file location. Used to manually certify a custom domain
        "certificate_chain": "my_cert_chain.pem", // SSL certificate chain file location. Used to manually certify a custom domain
        "certificate_arn": "arn:aws:acm:us-east-1:1234512345:certificate/aaaa-bbb-cccc-dddd", // ACM certificate ARN (needs to be in us-east-1 region).
        "cloudwatch_log_level": "OFF", // Enables/configures a level of logging for the given staging. Available options: "OFF", "INFO", "ERROR", default "OFF".
        "cloudwatch_data_trace": false, // Logs all data about received events. Default false.
        "cloudwatch_metrics_enabled": false, // Additional metrics for the API Gateway. Default false.
        "cognito": { // for Cognito event triggers
            "user_pool": "user-pool-id", // User pool ID from AWS Cognito
            "triggers": [{
                "source": "PreSignUp_SignUp", // triggerSource from http://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools-working-with-aws-lambda-triggers.html#cognito-user-pools-lambda-trigger-syntax-pre-signup
                "function": "my_app.pre_signup_function"
            }]
        },
        "context_header_mappings": { "HTTP_header_name": "API_Gateway_context_variable" }, // A dictionary mapping HTTP header names to API Gateway context variables
        "cors": false, // Enable Cross-Origin Resource Sharing. Default false. If true, simulates the "Enable CORS" button on the API Gateway console. Can also be a dictionary specifying lists of "allowed_headers", "allowed_methods", and string of "allowed_origin"
        "dead_letter_arn": "arn:aws:<sns/sqs>:::my-topic/queue", // Optional Dead Letter configuration for when Lambda async invoke fails thrice
        "debug": true, // Print Zappa configuration errors tracebacks in the 500. Default true.
        "delete_local_zip": true, // Delete the local zip archive after code updates. Default true.
        "delete_s3_zip": true, // Delete the s3 zip archive. Default true.
        "django_settings": "your_project.production_settings", // The modular path to your Django project's settings. For Django projects only.
        "domain": "yourapp.yourdomain.com", // Required if you're using a domain
        "base_path": "your-base-path", // Optional base path for API gateway custom domain base path mapping. Default None. Not supported for use with Application Load Balancer event sources.
        "environment_variables": {"your_key": "your_value"}, // A dictionary of environment variables that will be available to your deployed app. See also "remote_env" and "aws_environment_variables". Default {}.
        "events": [
            {   // Recurring events
                "function": "your_module.your_recurring_function", // The function to execute
                "expression": "rate(1 minute)" // When to execute it (in cron or rate format)
            },
            {   // AWS Reactive events
                "function": "your_module.your_reactive_function", // The function to execute
                "event_source": {
                    "arn":  "arn:aws:s3:::my-bucket", // The ARN of this event source
                    "events": [
                        "s3:ObjectCreated:*" // The specific event to execute in response to.
                    ]
                }
            }
        ],
        "endpoint_configuration": ["EDGE", "REGIONAL", "PRIVATE"],  // Specify APIGateway endpoint None (default) or list `EDGE`, `REGION`, `PRIVATE`
        "exception_handler": "your_module.report_exception", // function that will be invoked in case Zappa sees an unhandled exception raised from your code
        "exclude": ["*.gz", "*.rar"], // A list of regex patterns to exclude from the archive. To exclude boto3 and botocore (available in an older version on Lambda), add "boto3*" and "botocore*".
        "extends": "stage_name", // Duplicate and extend another stage's settings. For example, `dev-asia` could extend from `dev-common` with a different `s3_bucket` value.
        "extra_permissions": [{ // Attach any extra permissions to this policy. Default None
            "Effect": "Allow",
            "Action": ["rekognition:*"], // AWS Service ARN
            "Resource": "*"
        }],
        "iam_authorization": false, // optional, use IAM to require request signing. Default false. Note that enabling this will override the authorizer configuration.
        "include": ["your_special_library_to_load_at_handler_init"], // load special libraries into PYTHONPATH at handler init that certain modules cannot find on path
        "authorizer": {
            "function": "your_module.your_auth_function", // Local function to run for token validation. For more information about the function see below.
            "arn": "arn:aws:lambda:<region>:<account_id>:function:<function_name>", // Existing Lambda function to run for token validation.
            "result_ttl": 300, // Optional. Default 300. The time-to-live (TTL) period, in seconds, that specifies how long API Gateway caches authorizer results. Currently, the maximum TTL value is 3600 seconds.
            "token_header": "Authorization", // Optional. Default 'Authorization'. The name of a custom authorization header containing the token that clients submit as part of their requests.
            "validation_expression": "^Bearer \\w+$", // Optional. A validation expression for the incoming token, specify a regular expression.
        },
        "keep_warm": true, // Create CloudWatch events to keep the server warm. Default true. To remove, set to false and then `unschedule`.
        "keep_warm_expression": "rate(4 minutes)", // How often to execute the keep-warm, in cron and rate format. Default 4 minutes.
        "lambda_description": "Your Description", // However you want to describe your project for the AWS console. Default "Zappa Deployment".
        "lambda_handler": "your_custom_handler", // The name of Lambda handler. Default: handler.lambda_handler
        "layers": ["arn:aws:lambda:<region>:<account_id>:layer:<layer_name>:<layer_version>"], // optional lambda layers
        "lambda_concurrency": 10, // Sets the maximum number of simultaneous executions for a function, and reserves capacity for that concurrency level. Default is None.
        "lets_encrypt_key": "s3://your-bucket/account.key", // Let's Encrypt account key path. Can either be an S3 path or a local file path.
        "log_level": "DEBUG", // Set the Zappa log level. Can be one of CRITICAL, ERROR, WARNING, INFO and DEBUG. Default: DEBUG
        "manage_roles": true, // Have Zappa automatically create and define IAM execution roles and policies. Default true. If false, you must define your own IAM Role and role_name setting.
        "memory_size": 512, // Lambda function memory in MB. Default 512.
        "num_retained_versions":null, // Indicates the number of old versions to retain for the lambda. If absent, keeps all the versions of the function.
        "payload_compression": true, // Whether or not to enable API gateway payload compression (default: true)
        "payload_minimum_compression_size": 0, // The threshold size (in bytes) below which payload compression will not be applied (default: 0)
        "prebuild_script": "your_module.your_function", // Function to execute before uploading code
        "profile_name": "your-profile-name", // AWS profile credentials to use. Default 'default'. Removing this setting will use the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables instead.
        "project_name": "MyProject", // The name of the project as it appears on AWS. Defaults to a slugified `pwd`.
        "remote_env": "s3://my-project-config-files/filename.json", // optional file in s3 bucket containing a flat json object which will be used to set custom environment variables.
        "role_name": "MyLambdaRole", // Name of Zappa execution role. Default <project_name>-<env>-ZappaExecutionRole. To use a different, pre-existing policy, you must also set manage_roles to false.
        "role_arn": "arn:aws:iam::12345:role/app-ZappaLambdaExecutionRole", // ARN of Zappa execution role. Default to None. To use a different, pre-existing policy, you must also set manage_roles to false. This overrides role_name. Use with temporary credentials via GetFederationToken.
        "route53_enabled": true, // Have Zappa update your Route53 Hosted Zones when certifying with a custom domain. Default true.
        "runtime": "python3.6", // Python runtime to use on Lambda. Can be one of "python3.6", "python3.7" or "python3.8". Defaults to whatever the current Python being used is.
        "s3_bucket": "dev-bucket", // Zappa zip bucket,
        "slim_handler": false, // Useful if project >50M. Set true to just upload a small handler to Lambda and load actual project from S3 at runtime. Default false.
        "settings_file": "~/Projects/MyApp/settings/dev_settings.py", // Server side settings file location,
        "tags": { // Attach additional tags to AWS Resources
            "Key": "Value",  // Example Key and value
            "Key2": "Value2",
            },
        "timeout_seconds": 30, // Maximum lifespan for the Lambda function (default 30, max 900.)
        "touch": true, // GET the production URL upon initial deployment (default True)
        "touch_path": "/", // The endpoint path to GET when checking the initial deployment (default "/")
        "use_precompiled_packages": true, // If possible, use C-extension packages which have been pre-compiled for AWS Lambda. Default true.
        "vpc_config": { // Optional Virtual Private Cloud (VPC) configuration for Lambda function
            "SubnetIds": [ "subnet-12345678" ], // Note: not all availability zones support Lambda!
            "SecurityGroupIds": [ "sg-12345678" ]
        },
        "xray_tracing": false // Optional, enable AWS X-Ray tracing on your lambda function.
    }
}

YAML Settings

If you prefer YAML over JSON, you can also use a zappa_settings.yml, like so:

---
dev:
  app_function: your_module.your_app
  s3_bucket: your-code-bucket
  events:
  - function: your_module.your_function
    event_source:
      arn: arn:aws:s3:::your-event-bucket
      events:
      - s3:ObjectCreated:*

You can also supply a custom settings file at any time with the -s argument, ex:

$ zappa deploy dev -s my-custom-settings.yml

Similarly, you can supply a zappa_settings.toml file:

[dev]
  app_function = "your_module.your_app"
  s3_bucket = "your-code-bucket"

Advanced Usage

Keeping The Server Warm

Zappa will automatically set up a regularly occurring execution of your application in order to keep the Lambda function warm. This can be disabled via the keep_warm setting.

Serving Static Files / Binary Uploads

Zappa is now able to serve and receive binary files, as detected by their MIME-type.

However, generally Zappa is designed for running your application code, not for serving static web assets. If you plan on serving custom static assets in your web application (CSS/JavaScript/images/etc.,), you'll likely want to use a combination of AWS S3 and AWS CloudFront.

Your web application framework will likely be able to handle this for you automatically. For Flask, there is Flask-S3, and for Django, there is Django-Storages.

Similarly, you may want to design your application so that static binary uploads go directly to S3, which then triggers an event response defined in your events setting! That's thinking serverlessly!

Enabling CORS

The simplest way to enable CORS (Cross-Origin Resource Sharing) for your Zappa application is to set cors to true in your Zappa settings file and update, which is the equivalent of pushing the "Enable CORS" button in the AWS API Gateway console. This is disabled by default, but you may wish to enable it for APIs which are accessed from other domains, etc.

You can also simply handle CORS directly in your application. Your web framework will probably have an extension to do this, such as django-cors-headers or Flask-CORS. Using these will make your code more portable.

Large Projects

AWS currently limits Lambda zip sizes to 50 megabytes. If your project is larger than that, set slim_handler: true in your zappa_settings.json. In this case, your fat application package will be replaced with a small handler-only package. The handler file then pulls the rest of the large project down from S3 at run time! The initial load of the large project may add to startup overhead, but the difference should be minimal on a warm lambda function. Note that this will also eat into the storage space of your application function. Note that AWS currently limits the /tmp directory storage to 512 MB, so your project must still be smaller than that.

Enabling Bash Completion

Bash completion can be enabled by adding the following to your .bashrc:

  eval "$(register-python-argcomplete zappa)"

register-python-argcomplete is provided by the argcomplete Python package. If this package was installed in a virtualenv then the command must be run there. Alternatively you can execute:

activate-global-python-argcomplete --dest=- > file

The file's contents should then be sourced in e.g. ~/.bashrc.

Enabling Secure Endpoints on API Gateway

API Key

You can use the api_key_required setting to generate an API key to all the routes of your API Gateway. The process is as follows:

  1. Deploy/redeploy (update won't work) and write down the id for the key that has been created
  2. Go to AWS console > Amazon API Gateway and
    • select "API Keys" and find the key value (for example key_value)
    • select "Usage Plans", create a new usage plan and link the API Key and the API that Zappa has created for you
  3. Send a request where you pass the key value as a header called x-api-key to access the restricted endpoints (for example with curl: curl --header "x-api-key: key_value"). Note that without the x-api-key header, you will receive a 403.

IAM Policy

You can enable IAM-based (v4 signing) authorization on an API by setting the iam_authorization setting to true. Your API will then require signed requests and access can be controlled via IAM policy. Unsigned requests will receive a 403 response, as will requesters who are not authorized to access the API. Enabling this will override the Authorizer configuration (see below).

API Gateway Lambda Authorizers

If you deploy an API endpoint with Zappa, you can take advantage of API Gateway Lambda Authorizers to implement a token-based authentication - all you need to do is to provide a function to create the required output, Zappa takes care of the rest. A good start for the function is the AWS Labs blueprint example.

If you are wondering for what you would use an Authorizer, here are some potential use cases:

  1. Call out to OAuth provider
  2. Decode a JWT token inline
  3. Lookup in a self-managed DB (for example DynamoDB)

Zappa can be configured to call a function inside your code to do the authorization, or to call some other existing lambda function (which lets you share the authorizer between multiple lambdas). You control the behavior by specifying either the arn or function_name values in the authorizer settings block.

For example, to get the Cognito identity, add this to a zappa_settings.yaml:

  context_header_mappings:
    user_id: authorizer.user_id

Which can now be accessed in Flask like this:

from flask import request

@route('/hello')
def hello_world:
   print(request.headers.get('user_id'))

Cognito User Pool Authorizer

You can also use AWS Cognito User Pool Authorizer by adding:

{
    "authorizer": {
        "type": "COGNITO_USER_POOLS",
        "provider_arns": [
            "arn:aws:cognito-idp:{region}:{account_id}:userpool/{user_pool_id}"
        ]
    }
}

API Gateway Resource Policy

You can also use API Gateway Resource Policies. Example of IP Whitelisting:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": "execute-api:/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "1.2.3.4/32"
                    ]
                }
            }
        }
    ]
}

Setting Environment Variables

Local Environment Variables

If you want to set local environment variables for a deployment stage, you can simply set them in your zappa_settings.json:

{
    "dev": {
        ...
        "environment_variables": {
            "your_key": "your_value"
        }
    },
    ...
}

You can then access these inside your application with:

import os
your_value = os.environ.get('your_key')

If your project needs to be aware of the type of environment you're deployed to, you'll also be able to get SERVERTYPE (AWS Lambda), FRAMEWORK (Zappa), PROJECT (your project name) and STAGE (dev, production, etc.) variables at any time.

Remote AWS Environment Variables

If you want to use native AWS Lambda environment variables you can use the aws_environment_variables configuration setting. These are useful as you can easily change them via the AWS Lambda console or cli at runtime. They are also useful for storing sensitive credentials and to take advantage of KMS encryption of environment variables.

During development, you can add your Zappa defined variables to your locally running app by, for example, using the below (for Django, to manage.py).

if 'SERVERTYPE' in os.environ and os.environ['SERVERTYPE'] == 'AWS Lambda':
    import json
    import os
    json_data = open('zappa_settings.json')
    env_vars = json.load(json_data)['dev']['environment_variables']
    for key, val in env_vars.items():
        os.environ[key] = val

Remote Environment Variables

Any environment variables that you have set outside of Zappa (via AWS Lambda console or cli) will remain as they are when running update, unless they are also in aws_environment_variables, in which case the remote value will be overwritten by the one in the settings file. If you are using KMS-encrypted AWS environment variables, you can set your KMS Key ARN in the aws_kms_key_arn setting. Make sure that the values you set are encrypted in such case.

Note: if you rely on these as well as environment_variables, and you have the same key names, then those in environment_variables will take precedence as they are injected in the lambda handler.

Remote Environment Variables (via an S3 file)

S3 remote environment variables were added to Zappa before AWS introduced native environment variables for Lambda (via the console and cli). Before going down this route check if above make more sense for your usecase.

If you want to use remote environment variables to configure your application (which is especially useful for things like sensitive credentials), you can create a file and place it in an S3 bucket to which your Zappa application has access. To do this, add the remote_env key to zappa_settings pointing to a file containing a flat JSON object, so that each key-value pair on the object will be set as an environment variable and value whenever a new lambda instance spins up.

For example, to ensure your application has access to the database credentials without storing them in your version control, you can add a file to S3 with the connection string and load it into the lambda environment using the remote_env configuration setting.

super-secret-config.json (uploaded to my-config-bucket):

{
    "DB_CONNECTION_STRING": "super-secret:database"
}

zappa_settings.json:

{
    "dev": {
        ...
        "remote_env": "s3://my-config-bucket/super-secret-config.json",
    },
    ...
}

Now in your application you can use:

import os
db_string = os.environ.get('DB_CONNECTION_STRING')

API Gateway Context Variables

If you want to map an API Gateway context variable (http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html) to an HTTP header you can set up the mapping in zappa_settings.json:

{
    "dev": {
        ...
        "context_header_mappings": {
            "HTTP_header_name": "API_Gateway_context_variable"
        }
    },
    ...
}

For example, if you want to expose the $context.identity.cognitoIdentityId variable as the HTTP header CognitoIdentityId, and $context.stage as APIStage, you would have:

{
    "dev": {
        ...
        "context_header_mappings": {
            "CognitoIdentityId": "identity.cognitoIdentityId",
            "APIStage": "stage"
        }
    },
    ...
}

Catching Unhandled Exceptions

By default, if an unhandled exception happens in your code, Zappa will just print the stacktrace into a CloudWatch log. If you wish to use an external reporting tool to take note of those exceptions, you can use the exception_handler configuration option.

zappa_settings.json:

{
    "dev": {
        ...
        "exception_handler": "your_module.unhandled_exceptions",
    },
    ...
}

The function has to accept three arguments: exception, event, and context:

your_module.py

def unhandled_exceptions(e, event, context):
    send_to_raygun(e, event)  # gather data you need and send
    return True # Prevent invocation retry

You may still need a similar exception handler inside your application, this is just a way to catch exception which happen at the Zappa/WSGI layer (typically event-based invocations, misconfigured settings, bad Lambda packages, and permissions issues).

By default, AWS Lambda will attempt to retry an event based (non-API Gateway, e.g. CloudWatch) invocation if an exception has been thrown. However, you can prevent this by returning True, as in example above, so Zappa that will not re-raise the uncaught exception, thus preventing AWS Lambda from retrying the current invocation.

Using Custom AWS IAM Roles and Policies

Custom AWS IAM Roles and Policies for Deployment

You can specify which local profile to use for deploying your Zappa application by defining the profile_name setting, which will correspond to a profile in your AWS credentials file.

Custom AWS IAM Roles and Policies for Execution

The default IAM policy created by Zappa for executing the Lambda is very permissive. It grants access to all actions for all resources for types CloudWatch, S3, Kinesis, SNS, SQS, DynamoDB, and Route53; lambda:InvokeFunction for all Lambda resources; Put to all X-Ray resources; and all Network Interface operations to all EC2 resources. While this allows most Lambdas to work correctly with no extra permissions, it is generally not an acceptable set of permissions for most continuous integration pipelines or production deployments. Instead, you will probably want to manually manage your IAM policies.

To manually define the policy of your Lambda execution role, you must set manage_roles to false and define either the role_name or role_arn in your Zappa settings file.

{
    "dev": {
        ...
        "manage_roles": false, // Disable Zappa client managing roles.
        "role_name": "MyLambdaRole", // Name of your Zappa execution role. Optional, default: <project_name>-<env>-ZappaExecutionRole.
        "role_arn": "arn:aws:iam::12345:role/app-ZappaLambdaExecutionRole", // ARN of your Zappa execution role. Optional.
        ...
    },
    ...
}

Ongoing discussion about the minimum policy requirements necessary for a Zappa deployment can be found here. A more robust solution to managing these entitlements will likely be implemented soon.

To add permissions to the default Zappa execution policy, use the extra_permissions setting:

{
    "dev": {
        ...
        "extra_permissions": [{ // Attach any extra permissions to this policy.
            "Effect": "Allow",
            "Action": ["rekognition:*"], // AWS Service ARN
            "Resource": "*"
        }]
    },
    ...
}

AWS X-Ray

Zappa can enable AWS X-Ray support on your function with a configuration setting:

{
    "dev": {
        ...
        "xray_tracing": true
    },
    ...
}

This will enable it on the Lambda function and allow you to instrument your code with X-Ray. For example, with Flask:

from aws_xray_sdk.core import xray_recorder

app = Flask(__name__)

xray_recorder.configure(service='my_app_name')

@route('/hello')
@xray_recorder.capture('hello')
def hello_world:
    return 'Hello'

You may use the capture decorator to create subsegments around functions, or xray_recorder.begin_subsegment('subsegment_name') and xray_recorder.end_subsegment() within a function. The official X-Ray documentation for Python has more information on how to use this with your code.

Note that you may create subsegments in your code but an exception will be raised if you try to create a segment, as it is created by the lambda worker. This also means that if you use Flask you must not use the XRayMiddleware the documentation suggests.

Globally Available Server-less Architectures

Global Zappa Slides

Click to see slides from ServerlessConf London!

During the init process, you will be given the option to deploy your application "globally." This will allow you to deploy your application to all available AWS regions simultaneously in order to provide a consistent global speed, increased redundancy, data isolation, and legal compliance. You can also choose to deploy only to "primary" locations, the AWS regions with -1 in their names.

To learn more about these capabilities, see these slides from ServerlessConf London.

Raising AWS Service Limits

Out of the box, AWS sets a limit of 1000 concurrent executions for your functions. If you start to breach these limits, you may start to see errors like ClientError: An error occurred (LimitExceededException) when calling the PutTargets.." or something similar.

To avoid this, you can file a service ticket with Amazon to raise your limits up to the many tens of thousands of concurrent executions which you may need. This is a fairly common practice with Amazon, designed to prevent you from accidentally creating extremely expensive bug reports. So, before raising your service limits, make sure that you don't have any rogue scripts which could accidentally create tens of thousands of parallel executions that you don't want to pay for.

Dead Letter Queues

If you want to utilise AWS Lambda's Dead Letter Queue feature simply add the key dead_letter_arn, with the value being the complete ARN to the corresponding SNS topic or SQS queue in your zappa_settings.json.

You must have already created the corresponding SNS/SQS topic/queue, and the Lambda function execution role must have been provisioned with read/publish/sendMessage access to the DLQ resource.

Unique Package ID

For monitoring of different deployments, a unique UUID for each package is available in package_info.json in the root directory of your application's package. You can use this information or a hash of this file for such things as tracking errors across different deployments, monitoring status of deployments and other such things on services such as Sentry and New Relic. The package will contain:

{
  "build_platform": "darwin",
  "build_user": "frank",
  "build_time": "1509732511",
  "uuid": "9c2df9e6-30f4-4c0a-ac4d-4ecb51831a74"
}

Application Load Balancer Event Source

Zappa can be used to handle events triggered by Application Load Balancers (ALB). This can be useful in a few circumstances:

  • Since API Gateway has a hard limit of 30 seconds before timing out, you can use an ALB for longer running requests.
  • API Gateway is billed per-request; therefore, costs can become excessive with high throughput services. ALBs pricing model makes much more sense financially if you're expecting a lot of traffic to your Lambda.
  • ALBs can be placed within a VPC, which may make more sense for private endpoints than using API Gateway's private model (using AWS PrivateLink).

Like API Gateway, Zappa can automatically provision ALB resources for you. You'll need to add the following to your zappa_settings:

"alb_enabled": true,
"alb_vpc_config": {
    "CertificateArn": "arn:aws:acm:us-east-1:[your-account-id]:certificate/[certificate-id]",
    "SubnetIds": [
        // Here, you'll want to provide a list of subnets for your ALB, eg. 'subnet-02a58266'
    ],
    "SecurityGroupIds": [
        // And here, a list of security group IDs, eg. 'sg-fbacb791'
    ]
}

More information on using ALB as an event source for Lambda can be found here.

An important note: right now, Zappa will provision ONE lambda to ONE load balancer, which means using base_path along with ALB configuration is currently unsupported.

Endpoint Configuration

API Gateway can be configured to be only accessible in a VPC. To enable this; configure your VPC to support then set the endpoint_configuration to PRIVATE and set up Resource Policy on the API Gateway. A note about this; if you're using a private endpoint, Zappa won't be able to tell if the API is returning a successful status code upon deploy or update, so you'll have to check it manually to ensure your setup is working properly.

For full list of options for endpoint configuration refer to API Gateway EndpointConfiguration documentation

Example Private API Gateway configuration

zappa_settings.json:

{
    "dev": {
        ...
        "endpoint_configuration": ["PRIVATE"],
        "apigateway_policy": "apigateway_resource_policy.json",
        ...
    },
    ...
}

apigateway_resource_policy.json:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": "execute-api:/*",
            "Condition": {
                "StringNotEquals": {
                    "aws:sourceVpc": "{{vpcID}}" // UPDATE ME
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": "execute-api:/*"
        }
    ]
}

Zappa Guides

Zappa in the Press

Sites Using Zappa

Are you using Zappa? Let us know and we'll list your site here!

Related Projects

  • lambda-packages - Precompiled C-extension packages for AWS Lambda. Used automatically by Zappa.
  • Mackenzie - AWS Lambda Infection Toolkit
  • NoDB - A simple, server-less, Pythonic object store based on S3.
  • zappa-cms - A tiny server-less CMS for busy hackers. Work in progress.
  • zappa-django-utils - Utility commands to help Django deployments.
  • flask-ask - A framework for building Amazon Alexa applications. Uses Zappa for deployments.
  • zappa-file-widget - A Django plugin for supporting binary file uploads in Django on Zappa.
  • zops - Utilities for teams and continuous integrations using Zappa.
  • cookiecutter-mobile-backend - A cookiecutter Django project with Zappa and S3 uploads support.
  • zappa-examples - Flask, Django, image uploads, and more!
  • zappa-hug-example - Example of a Hug application using Zappa.
  • Zappa Docker Image - A Docker image for running Zappa locally, based on Lambda Docker.
  • zappa-dashing - Monitor your AWS environment (health/metrics) with Zappa and CloudWatch.
  • s3env - Manipulate a remote Zappa environment variable key/value JSON object file in an S3 bucket through the CLI.
  • zappa_resize_image_on_fly - Resize images on the fly using Flask, Zappa, Pillow, and OpenCV-python.
  • zappa-ffmpeg - Run ffmpeg inside a lambda for serverless transformations.
  • gdrive-lambda - pass json data to a csv file for end users who use Gdrive across the organization.
  • travis-build-repeat - Repeat TravisCI builds to avoid stale test results.
  • wunderskill-alexa-skill - An Alexa skill for adding to a Wunderlist.
  • xrayvision - Utilities and wrappers for using AWS X-Ray with Zappa.
  • terraform-aws-zappa - Terraform modules for creating a VPC, RDS instance, ElastiCache Redis and CloudFront Distribution for use with Zappa.
  • zappa-sentry - Integration with Zappa and Sentry
  • IOpipe - Monitor, profile and analyze your Zappa apps.

Hacks

Zappa goes quite far beyond what Lambda and API Gateway were ever intended to handle. As a result, there are quite a few hacks in here that allow it to work. Some of those include, but aren't limited to..

  • Using VTL to map body, headers, method, params and query strings into JSON, and then turning that into valid WSGI.
  • Attaching response codes to response bodies, Base64 encoding the whole thing, using that as a regex to route the response code, decoding the body in VTL, and mapping the response body to that.
  • Packing and Base58 encoding multiple cookies into a single cookie because we can only map one kind.
  • Forcing the case permutations of "Set-Cookie" in order to return multiple headers at the same time.
  • Turning cookie-setting 301/302 responses into 200 responses with HTML redirects, because we have no way to set headers on redirects.

Contributing

This project is still young, so there is still plenty to be done. Contributions are more than welcome!

Please file tickets for discussion before submitting patches. Pull requests should target master and should leave Zappa in a "shippable" state if merged.

If you are adding a non-trivial amount of new code, please include a functioning test in your PR. For AWS calls, we use the placebo library, which you can learn to use in their README. The test suite will be run by Travis CI once you open a pull request.

Please include the GitHub issue or pull request URL that has discussion related to your changes as a comment in the code (example). This greatly helps for project maintainability, as it allows us to trace back use cases and explain decision making. Similarly, please make sure that you meet all of the requirements listed in the pull request template.

Please feel free to work on any open ticket, especially any ticket marked with the "help-wanted" label. If you get stuck or want to discuss an issue further, please join our Slack channel, where you'll find a community of smart and interesting people working dilligently on hard problems.

Zappa does not intend to conform to PEP8, isolate your commits so that changes to functionality with changes made by your linter.

Using a Local Repo

To use the git HEAD, you probably can't use pip install -e . Instead, you should clone the repo to your machine and then pip install /path/to/zappa/repo or ln -s /path/to/zappa/repo/zappa zappa in your local project.

Patrons

If you or your company uses Zappa, please consider giving what you can to support the ongoing development of the project!

You can become a patron by visiting our Patreon page.

Zappa is currently supported by these awesome individuals and companies:

  • Nathan Lawrence
  • LaunchLab
  • Sean Paley
  • Theo Chitayat
  • George Sibble
  • Joe Weiss
  • Nik Bora
  • Zerong Toby Wang
  • Gareth E
  • Matt Jackson
  • Sean Coates
  • Alexander Loschilov
  • Korey Peters
  • Joe Weiss
  • Kimmo Parvianen-Jalanko
  • Patrick Agin
  • Roberto Martinez
  • Charles Dimino
  • Doug Beney
  • Dan "The Man" Gayle
  • Juancito
  • Will Childs-Klein
  • Efi Merdler Kravitz
  • Philippe Trounev

Thank you very, very much!

Support / Development / Training / Consulting

Do you need help with..

  • Porting existing Flask and Django applications to Zappa?
  • Building new applications and services that scale infinitely?
  • Reducing your operations and hosting costs?
  • Adding new custom features into Zappa?
  • Training your team to use AWS and other server-less paradigms?

Good news! We're currently available for remote and on-site consulting for small, large and enterprise teams. Please contact [email protected] with your needs and let's work together!


Made by Gun.io

Issues
  • [Doppins] Upgrade dependency botocore to ==1.6.7

    [Doppins] Upgrade dependency botocore to ==1.6.7

    Hi!

    A new version was just released of botocore, so Doppins has upgraded your project's dependency ranges.

    Make sure that it doesn't break anything, and happy merging! :shipit:


    Upgraded botocore from ==1.5.40 to ==1.5.41

    opened by doppins-bot 133
  • Issue #1715 Beginning support for Application Load Balancer

    Issue #1715 Beginning support for Application Load Balancer

    By adding support for the slightly different request forwarded by an ELB https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html We can alter the handler to begin supporting optional ELB traffic as an alternative to API Gateway

    Description

    (WIP) Support for Application load balancer -> lambda By adjusting the handler to honor the spec for lambda functions as ALB targets defined here: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html

    Known Issues:

    Since ALB is a different animal, not all options with API Gateway are a perfect fit.

    • API gateway features wont work:

      • Stages
      • Authorization
      • Domains (conceivably since youre using an ELB you have other means to accomplish this)
    • Cognito is untested

    • Django management is untested

    • No support for provisioning (via troposphere) the load balancer, nor the targeting. Currently this must be done manually (not for lack of trying, it appears cloudformation hasnt caught up with ALB/lambda targeting yet)

    GitHub Issues

    https://github.com/Miserlou/Zappa/issues/1715

    opened by PeteW 57
  • binary support

    binary support

    Description

    GitHub Issues

    opened by wobeng 45
  • 'certify' doesn't update existing certificates

    'certify' doesn't update existing certificates

    Somewhere, a regression was introduced, I think this was from a PR that I was iffy about.

    Repro: Certify on a new name

    Calling certify for environment prod..
    Certifying domain blah.yourname.io..
    Setting DNS challenge..
    Waiting for DNS to propagate..
    Deleting DNS challenge..
    Updating domain name!
    Certificate updated!
    

    Go to domain, old cert still in production.

    opened by Miserlou 41
  • Apigateway stages

    Apigateway stages

    fixed #628 #254

    help wanted 
    opened by anush0247 37
  • Make it easier to port Celery projects / queue background tasks

    Make it easier to port Celery projects / queue background tasks

    Context

    I have quite some Celery / django-q projects I would like to move to Zappa. Now one can argue that you don't need any of the tasks libs like celery / django-q as lambda's can easily be invoked on a scheduled interval or based on S3 / SNS events. True, but this doesn't mean the api's (of celery for example) to create tasks aren't handy. Think; @task() decorator and some_func.delay() to queue the task.

    I mostly use celery to invoke some background task to be handled later (sending email, updating search indexes etc.). What I would like to see is that I can still use the Celery task creation api in order for my app to be still portable if I want to move away from lambda (something Zappa promises).

    Possible Fix

    As celery already can use SQS as its queue we maybe can add a lambda handler to SQS events and execute the task. I've been digging in the Celery codebase to search for the point where the task data (coming from the queue) is transformed and in the end executed by the worker. Because that is what we would need to do in a lambda handler. Not easy to find, it's here: https://github.com/celery/celery/blob/master/celery/worker/components.py#L229 Definitely not straightforward to get that working.

    Another option would be to have a lambda 'celery worker' to run on a schedule every second (or whatever you want), have it connect to the SQS queue, pull a task (if available), execute it and exit. Far from ideal but workers can be told to only execute 1 task and exit (I'm told, haven't confirmed this yet). If that works we could also get around the 1 second schedule by having the lambda celery worker start on an SQS event but have if pull the task in a celery native fashion, instead of using the actual SQS message data when invoked.

    Having said that I don't think we should try to make Zappa 'compatible' with Celery / django-q and whatever other framework there is. Celery though is a contender in my view as it's widely used.

    The last option (except for not helping dev's on this topic at all) I see is creating helpers in zappa natively to replace the celery / django-q framework api's. Think;

    task_id = zappa.queue.delay('module.my_func', *args, **kwargs)
    # that would upload the tasks definition to for example S3
    # a zappa framework native handler could execute the task based on the S3 event
    # when finished the task result is uploaded back to S3 again.
    task_result = zappa.queue.get_result(task_id, remove=True)  
    # if finished, returns the task result and deletes the S3 task entry (if you want to), else None
    

    If that existed I wouldn't have brought this up and I would happily write logic to use zappa vs celery based on the platform I'm running on.

    One thing that does bother me with the 'zappa native' approach is that we'll be reinventing the wheel regarding task serialization, queueing, task de-serialization and executing the task. Possibly we might want to include some retry handling as well in that case.

    The django-q codebase by the way is much smaller and easier to dig in. If we decide zappa should have some helpers for this it's a good starting point to look at.

    Goal of this issue

    I would like to start the discussion around this and collect everyone's opinion. If we come to the conclusion that Zappa should/could support something like this I'll work on a POC. If not, we can just close this issue :)

    opened by michi88 36
  • Error loading psycopg2 module on Python 3.6 (when on Lambda)

    Error loading psycopg2 module on Python 3.6 (when on Lambda)

    Context

    Shiny new Zappa 0.41 and Python 3.6

    Django==1.11 djangorestframework==3.6.2 psycopg2==2.6.1 zappa==0.41.0 ...

    Expected Behavior

    It works fine locally, but on Lambda the following happens:

    [1492873312435] File "/var/task/django_zappa_app.py", line 20, in get_django_wsgi
    [1492873312435] return get_wsgi_application()
    [1492873312435] File "/var/task/django/core/wsgi.py", line 13, in get_wsgi_application
    [1492873312435] django.setup(set_prefix=False)
    [1492873312435] File "/var/task/django/__init__.py", line 27, in setup
    [1492873312435] apps.populate(settings.INSTALLED_APPS)
    [1492873312435] File "/var/task/django/apps/registry.py", line 108, in populate
    [1492873312435] app_config.import_models()
    [1492873312435] File "/var/task/django/apps/config.py", line 202, in import_models
    [1492873312436] self.models_module = import_module(models_module_name)
    [1492873312436] File "/var/lang/lib/python3.6/importlib/__init__.py", line 126, in import_module
    [1492873312436] return _bootstrap._gcd_import(name[level:], package, level)
    [1492873312436] File "<frozen importlib._bootstrap>", line 978, in _gcd_import
    [1492873312436] File "<frozen importlib._bootstrap>", line 961, in _find_and_load
    [1492873312436] File "<frozen importlib._bootstrap>", line 950, in _find_and_load_unlocked
    [1492873312436] File "<frozen importlib._bootstrap>", line 655, in _load_unlocked
    [1492873312436] File "<frozen importlib._bootstrap_external>", line 678, in exec_module
    [1492873312436] File "<frozen importlib._bootstrap>", line 205, in _call_with_frames_removed
    [1492873312436] File "/var/task/django/contrib/auth/models.py", line 4, in <module>
    [1492873312436] from django.contrib.auth.base_user import AbstractBaseUser, BaseUserManager
    [1492873312436] File "/var/task/django/contrib/auth/base_user.py", line 52, in <module>
    [1492873312436] class AbstractBaseUser(models.Model):
    [1492873312436] File "/var/task/django/db/models/base.py", line 124, in __new__
    [1492873312436] new_class.add_to_class('_meta', Options(meta, app_label))
    [1492873312436] File "/var/task/django/db/models/base.py", line 330, in add_to_class
    [1492873312437] value.contribute_to_class(cls, name)
    [1492873312437] File "/var/task/django/db/models/options.py", line 214, in contribute_to_class
    [1492873312437] self.db_table = truncate_name(self.db_table, connection.ops.max_name_length())
    [1492873312437] File "/var/task/django/db/__init__.py", line 33, in __getattr__
    [1492873312437] return getattr(connections[DEFAULT_DB_ALIAS], item)
    [1492873312437] File "/var/task/django/db/utils.py", line 211, in __getitem__
    [1492873312437] backend = load_backend(db['ENGINE'])
    [1492873312437] File "/var/task/django/db/utils.py", line 115, in load_backend
    [1492873312437] return import_module('%s.base' % backend_name)
    [1492873312437] File "/var/lang/lib/python3.6/importlib/__init__.py", line 126, in import_module
    [1492873312437] return _bootstrap._gcd_import(name[level:], package, level)
    [1492873312437] File "/var/task/django/db/backends/postgresql/base.py", line 25, in <module>
    [1492873312437] raise ImproperlyConfigured("Error loading psycopg2 module: %s" % e)
    [1492873312437] django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 module: dynamic module does not define module export function (PyInit__psycopg)
    [1492873312437] During handling of the above exception, another exception occurred:
    [1492873312437] Traceback (most recent call last):
    [1492873312437] File "/var/runtime/awslambda/bootstrap.py", line 466, in <module>
    [1492873312437] main()
    [1492873312437] File "/var/runtime/awslambda/bootstrap.py", line 462, in main
    [1492873312438] handle_event_request(request_handler, invokeid, event_body, context_objs, invoked_function_arn)
    [1492873312438] File "/var/runtime/awslambda/bootstrap.py", line 248, in handle_event_request
    [1492873312438] result = to_json(result)
    [1492873312438] File "/var/runtime/awslambda/bootstrap.py", line 224, in to_json
    [1492873312438] return json.dumps(obj, default=decimal_serializer)
    [1492873312438] File "/var/lang/lib/python3.6/json/__init__.py", line 238, in dumps
    [1492873312438] **kw).encode(obj)
    [1492873312438] File "/var/lang/lib/python3.6/json/encoder.py", line 199, in encode
    [1492873312438] chunks = self.iterencode(o, _one_shot=True)
    [1492873312438] File "/var/lang/lib/python3.6/json/encoder.py", line 257, in iterencode
    [1492873312438] return _iterencode(o, 0)
    [1492873312438] File "/var/runtime/awslambda/bootstrap.py", line 42, in decimal_serializer
    [1492873312439] raise TypeError(repr(o) + " is not JSON serializable")
    [1492873312439] TypeError: <FrameSummary file /var/task/handler.py, line 514 in lambda_handler> is not JSON serializable
    [1492873312598] Error loading psycopg2 module: dynamic module does not define module export function (PyInit__psycopg)
    ImproperlyConfigured
    

    Possible Fix

    No idea yet, but before I dig further, I was wondering if someone had any pointers. I assume its something to do with pre-compiled C-extension packages not working on Python 3.6 yet.

    opened by wagmiwiz 30
  • AttributeError: 'module' has no attribute 'get_installed_distributions'

    AttributeError: 'module' has no attribute 'get_installed_distributions'

    Context

    When deploying a project with "zappa deploy [project-name]" I get the error: AttributeError: 'module' has no attribute 'get_installed_distributions'

    I honestly do not know what is wrong or what I am missing. Any help please provide simple step by step instructions to solve this. zappa error

    non-bug 
    opened by matinde 28
  • Cloud watch event management improvements

    Cloud watch event management improvements

    • Use lambda name as prefix for all CW events.
    • Make scheduling/un-scheduling part of deploy/undeploy.
    • Schedule warm-up event together with the rest of CW events.
    opened by aectann 27
  • Only works with Python 2.7?

    Only works with Python 2.7?

    First of all, awesome work, folks! Really liked it and intend to use.

    This is more of a reminder for the README, because, when reading the code, I saw "python2.7" hardcoded and I figured it would be best to write that in the README

    enhancement 
    opened by tiagofassoni 27
  • Bump django from 3.0.7 to 3.1.13

    Bump django from 3.0.7 to 3.1.13

    Bumps django from 3.0.7 to 3.1.13.

    Commits
    • 43873b9 [3.1.x] Bumped version for 3.1.13 release.
    • 0bd57a8 [3.1.x] Fixed CVE-2021-35042 -- Prevented SQL injection in QuerySet.order_by().
    • 8dc1cc0 [3.1.x] Added stub release notes for 3.1.13.
    • 1471ec4 [3.1.x] Fixed docs header underlines in security archive.
    • 6022181 [3.1.x] Added CVE-2021-33203 and CVE-2021-33571 to security archive.
    • 064c0c5 [3.1.x] Post-release version bump.
    • 625d3c1 [3.1.x] Bumped version for 3.1.12 release.
    • 203d4ab [3.1.x] Fixed CVE-2021-33571 -- Prevented leading zeros in IPv4 addresses.
    • 20c67a0 [3.1.x] Fixed CVE-2021-33203 -- Fixed potential path-traversal via admindocs'...
    • aa8781c [3.1.x] Confirmed release date for Django 3.1.12, and 2.2.24.
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 0
  • Troposphere v3 updates its lib from add to set

    Troposphere v3 updates its lib from add to set

    Description

    GitHub Issues

    opened by jpadmin 0
  • AttributeError: 'Template' object has no attribute 'add_description'

    AttributeError: 'Template' object has no attribute 'add_description'

    Context

    Setup of a Django environment for deployment onto AWS Lambda. Had the following pip packages installed pip install NearBeach zappa pymysql django-storages cryptography

    Ran the following command zappa update to update my live environment.

    Expected Behavior

    Zappa to deploy the site correctly.

    Actual Behavior

    Failed to deploy. With the following errors (pulled from my terminal)

    Updating Lambda function code..
    Updating Lambda function configuration..
    Oh no! An error occurred! :(
    
    ==============
    
    Traceback (most recent call last):
      File "/home/ubuntu/clients/zappa_test/venv/lib/python3.6/site-packages/zappa/cli.py", line 2785, in handle
        sys.exit(cli.handle())
      File "/home/ubuntu/clients/zappa_test/venv/lib/python3.6/site-packages/zappa/cli.py", line 510, in handle
        self.dispatch_command(self.command, stage)
      File "/home/ubuntu/clients/zappa_test/venv/lib/python3.6/site-packages/zappa/cli.py", line 557, in dispatch_command
        self.update(self.vargs['zip'], self.vargs['no_upload'])
      File "/home/ubuntu/clients/zappa_test/venv/lib/python3.6/site-packages/zappa/cli.py", line 993, in update
        endpoint_configuration=self.endpoint_configuration
      File "/home/ubuntu/clients/zappa_test/venv/lib/python3.6/site-packages/zappa/core.py", line 2106, in create_stack_template
        self.cf_template.add_description('Automatically generated with Zappa')
    AttributeError: 'Template' object has no attribute 'add_description'
    
    ==============
    
    

    Possible Fix

    As discussed on the stackoverflow - https://stackoverflow.com/questions/68391621/zappa-deploy-fails-with-attributeerror-template-object-has-no-attribute-add - the error looks like it has something to do with the NEW troposphere.

    Running the following command (i.e. downgrading the troposphere) worked for me: pip install troposphere==2.7.1

    Your Environment

    • Zappa version used: 0.53.0
    • Operating System and Python version: 3.6.9
    • The output of pip freeze:
    argcomplete==1.12.3
    asgiref==3.4.1
    boto3==1.18.1
    botocore==1.21.1
    certifi==2021.5.30
    cffi==1.14.6
    cfn-flip==1.2.3
    charset-normalizer==2.0.3
    click==8.0.1
    cryptography==3.4.7
    Django==3.2.5
    django-storages==1.11.1
    durationpy==0.5
    future==0.18.2
    hjson==3.0.2
    idna==3.2
    importlib-metadata==4.6.1
    jmespath==0.10.0
    kappa==0.6.0
    NearBeach==0.28.9.1
    pep517==0.11.0
    Pillow==8.3.1
    pip-tools==6.2.0
    placebo==0.9.0
    pycparser==2.20
    PyMySQL==1.0.2
    python-dateutil==2.6.1
    python-slugify==5.0.2
    pytz==2021.1
    PyYAML==5.4.1
    requests==2.26.0
    s3transfer==0.5.0
    simplejson==3.17.3
    six==1.16.0
    sqlparse==0.4.1
    text-unidecode==1.3
    toml==0.10.2
    tomli==1.0.4
    tqdm==4.61.2
    troposphere==2.7.1
    typing-extensions==3.10.0.0
    urllib3==1.26.6
    Werkzeug==0.16.1
    wsgi-request-logger==0.4.6
    zappa==0.53.0
    zipp==3.5.0
    
    • Link to your project (optional): https://github.com/robotichead/NearBeach
    opened by robotichead 8
  • Zappa Deploy | Update error on

    Zappa Deploy | Update error on "No such file or directory" Possible duplicate of https://github.com/Miserlou/Zappa/issues/1232

    Hey,

    I'm having a similar problem mentioned in the duplicate. The only difference is, the solution mentioned is not working. I've put hours to debug it but nothing successful. Kindly help in this regard.

    Error

    Traceback (most recent call last):
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/cli.py", line 3422, in handle
        sys.exit(cli.handle())
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/cli.py", line 588, in handle
        self.dispatch_command(self.command, stage)
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/cli.py", line 641, in dispatch_command
        self.update(
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/cli.py", line 1088, in update
        self.create_package()
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/cli.py", line 2743, in create_package
        self.zip_path = self.zappa.create_lambda_zip(
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/core.py", line 632, in create_lambda_zip
        copytree(
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/utilities.py", line 69, in copytree
        copy_file(src, dst, item)
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/utilities.py", line 50, in copy_file
        copytree(s, d, metadata, symlinks, ignore)
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/utilities.py", line 69, in copytree
        copy_file(src, dst, item)
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/utilities.py", line 50, in copy_file
        copytree(s, d, metadata, symlinks, ignore)
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/utilities.py", line 69, in copytree
        copy_file(src, dst, item)
      File "/home/khizar/.local/lib/python3.8/site-packages/zappa/utilities.py", line 52, in copy_file
        shutil.copy2(s, d) if metadata else shutil.copy(s, d)
      File "/usr/lib/python3.8/shutil.py", line 418, in copy
        copyfile(src, dst, follow_symlinks=follow_symlinks)
      File "/usr/lib/python3.8/shutil.py", line 264, in copyfile
        with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
    FileNotFoundError: [Errno 2] No such file or directory: '/home/khizar/Repositories/comradly/lambda/.serverless/requirements'
    

    Contents of pip list

    Package                          Version  
    -------------------------------- ---------
    argcomplete                      1.12.3   
    boto3                            1.17.110 
    botocore                         1.20.110 
    CacheControl                     0.12.6   
    cachetools                       4.2.2    
    certifi                          2021.5.30
    cffi                             1.14.6   
    cfn-flip                         1.2.3    
    chardet                          3.0.4    
    click                            8.0.1    
    dj-database-url                  0.5.0    
    Django                           2.2.5    
    django-admin-rangefilter         0.5.4    
    django-allow-cidr                0.3.1    
    django-cors-headers              3.1.1    
    django-extensions                2.2.1    
    django-middleware-global-request 0.2.0    
    django-sendgrid-v5               0.8.1    
    djangorestframework              3.10.3   
    docutils                         0.15.2   
    durationpy                       0.5      
    firebase-admin                   4.4.0    
    future                           0.18.2   
    google-api-core                  1.31.0   
    google-api-python-client         1.12.8   
    google-auth                      1.23.0   
    google-auth-httplib2             0.0.4    
    google-auth-oauthlib             0.4.4    
    google-cloud-core                1.7.1    
    google-cloud-firestore           2.0.1    
    google-cloud-storage             1.40.0   
    google-crc32c                    1.1.2    
    google-resumable-media           1.3.1    
    googleapis-common-protos         1.53.0   
    grpcio                           1.38.1   
    gspread                          3.1.0    
    gunicorn                         19.9.0   
    hjson                            3.0.2    
    honeycomb-beeline                2.11.2   
    httplib2                         0.18.1   
    idna                             2.8      
    jmespath                         0.10.0   
    jsonfield                        2.0.2    
    kappa                            0.6.0    
    libhoney                         1.10.0   
    msgpack                          1.0.2    
    netaddr                          0.8.0    
    oauth2client                     4.1.3    
    oauthlib                         3.1.0    
    packaging                        21.0     
    pep517                           0.10.0   
    Pillow                           7.0.0    
    pip                              20.0.2   
    pip-tools                        6.2.0    
    pkg-resources                    0.0.0    
    placebo                          0.9.0    
    proto-plus                       1.19.0   
    protobuf                         3.17.3   
    pyasn1                           0.4.8    
    pyasn1-modules                   0.2.8    
    pycparser                        2.20     
    pyfcm                            1.4.7    
    pygsheets                        2.0.2    
    pyparsing                        2.4.7    
    python-dateutil                  2.4.2    
    python-http-client               3.3.2    
    python-slugify                   5.0.2    
    pytz                             2021.1   
    PyYAML                           5.4.1    
    reportlab                        3.5.48   
    requests                         2.22.0   
    requests-oauthlib                1.2.0    
    rsa                              4.7.2    
    s3transfer                       0.4.2    
    sendgrid                         6.4.1    
    sentry-sdk                       0.14.4   
    setuptools                       44.0.0   
    six                              1.16.0   
    sqlparse                         0.4.1    
    starkbank-ecdsa                  1.1.1    
    statsd                           3.3.0    
    text-unidecode                   1.3      
    toml                             0.10.2   
    tqdm                             4.61.2   
    troposphere                      3.0.1    
    uritemplate                      3.0.1    
    urllib3                          1.25.11  
    Werkzeug                         0.16.1   
    wheel                            0.36.2   
    whitenoise                       4.1.4    
    wrapt                            1.12.1   
    wsgi-request-logger              0.4.6    
    zappa                            0.53.0   
    

    I've no idea why it's going in the lambda/.serverless directory for finding a file

    Dup link: https://github.com/Miserlou/Zappa/issues/1232

    opened by khixer 0
  • Zappa not compatible with Python3.8

    Zappa not compatible with Python3.8

    Summary - Zappa version 0.52.0 not working with Python 3.8

    Context

    I created the virtualenv using python 3.8 and tried to deploy the environment. Its showing some error. Same thing with python3.7 is working seamlessly.

    Expected Behavior

    zappa deploy should start deploying the project.

    Actual Behavior

    zappa deploy with python3.8 version, its showing below error-- Traceback (most recent call last): File "/home/user/Development/serverless_project/virt/demo_zappa/bin/zappa", line 5, in from zappa.cli import handle File "/home/user/Development/serverless_project/virt/demo_zappa/lib/python3.8/site-packages/zappa/cli.py", line 44, in from .core import Zappa, logger, API_GATEWAY_REGIONS File "/home/user/Development/serverless_project/virt/demo_zappa/lib/python3.8/site-packages/zappa/core.py", line 33, in import troposphere File "/home/user/Development/serverless_project/virt/demo_zappa/lib/python3.8/site-packages/troposphere/init.py", line 586, in class Template(object): File "/home/user/Development/serverless_project/virt/demo_zappa/lib/python3.8/site-packages/troposphere/init.py", line 588, in Template 'AWSTemplateFormatVersion': (basestring, False), NameError: name 'basestring' is not defined

    Steps to Reproduce(Similar steps with python3.7 are working fine)

    1. Created Django Project
    2. Created virualenv for python3.8 (virtualenv -p /usr/bin/python3.8 virt/demo_zappa/)
    3. Setup zappa_settings.json with runtime "python3.8"
    4. Executing zappa init or zappa deploy is producing errors.

    Your Environment

    • Zappa version used: 0.52.0

    • Operating System and Python version: Ubuntu 18.04 LTS and Python 3.8.10

    • The output of pip freeze: argcomplete==1.12.3 asgiref==3.3.4 boto3==1.17.89 botocore==1.20.89 certifi==2021.5.30 cfn-flip==1.2.3 chardet==4.0.0 click==8.0.1 Django==3.2.3 django-extensions==3.1.3 djangorestframework==3.12.4 durationpy==0.5 future==0.18.2 hjson==3.0.2 idna==2.9 importlib-metadata==4.5.0 jmespath==0.10.0 kappa==0.6.0 pep517==0.10.0 pip-tools==6.1.0 placebo==0.9.0 PyMySQL==1.0.2 python-dateutil==2.8.1 python-slugify==5.0.2 pytz==2021.1 PyYAML==5.4.1 requests==2.25.1 s3transfer==0.4.2 six==1.16.0 sqlparse==0.4.1 text-unidecode==1.3 toml==0.10.2 tqdm==4.61.0 troposphere==2.7.1 typing-extensions==3.10.0.0 urllib3==1.26.5 Werkzeug==0.16.1 wsgi-request-logger==0.4.6 zappa==0.52.0 zipp==3.4.1

    • Your zappa_settings.json:

    { "dev": { "aws_region": "ap-south-1", "django_settings": "python_zappa.settings", "profile_name": "default", "project_name": "python-zappa", "runtime": "python3.8", "s3_bucket": "", "manage_roles": false, "role_arn": "arn:aws:iam:::role/", "slim_handler": false, "delete_local_zip": true } }

    opened by divyaarya 1
  • AWS CodeBuild Error

    AWS CodeBuild Error

    Hi, Am trying to automate the build process for the Deployment of a Flask Project using Zappa to AWS. The desired behaviour is that when a user commits code to a branch, the code should be deployed.

    Have created a pipeline in AWS to deploy the code.

    Following is the BuildSpec version: 0.2

    phases: install: commands: - virtualenv venv - . venv/bin/activate - pip install -r requirements.txt pre_build: commands: # - if [ ! -v STAGE ]; then echo stage not set; exit 1; fi # - zappa manage --no-color $STAGE "collectstatic --noinput" build: commands: - echo Build started on date - echo Building and running tests # - zappa update --disable_progress $STAGE post_build: commands: - if [ $CODEBUILD_BUILD_SUCCEEDING = 1 ]; then echo Build completed on date; echo Starting deployment; zappa update dev; else echo Build failed ignoring deployment; fi - echo Deployment completed

    The Build gets successfully pulled from Github, but during the application build stage, the following errors are resulting when "zappa update dev" is being called. In addition, i have also setup an EC2 Server through which I usually deploy from. In that server I HAVE NOT created any Profile for AWS. Just Wanted to understand if the build spec or any other setting is missing. Havent really found any guide for integration of Zappa with CodePipeline.

    _Traceback (most recent call last): 192 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/zappa/cli.py", line 2778, in handle 193 | sys.exit(cli.handle()) 194 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/zappa/cli.py", line 512, in handle 195 | self.dispatch_command(self.command, stage) 196 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/zappa/cli.py", line 538, in dispatch_command 197 | self.load_settings(self.vargs.get('settings_file')) 198 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/zappa/cli.py", line 2116, in load_settings 199 | self.zappa = Zappa( boto_session=session, 200 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/zappa/core.py", line 306, in init 201 | self.load_credentials(boto_session, profile_name) 202 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/zappa/core.py", line 3187, in load_credentials 203 | self.boto_session = boto3.Session(profile_name=profile_name, region_name=self.aws_region) 204 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/boto3/session.py", line 80, in init 205 | self._setup_loader() 206 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/boto3/session.py", line 120, in _setup_loader 207 | self._loader = self._session.get_component('data_loader') 208 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/botocore/session.py", line 698, in get_component 209 | return self._components.get_component(name) 210 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/botocore/session.py", line 937, in get_component 211 | self._components[name] = factory() 212 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/botocore/session.py", line 158, in <lambda> 213 | lambda: create_loader(self.get_config_variable('data_path'))) 214 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/botocore/session.py", line 251, in get_config_variable 215 | return self.get_component('config_store').get_config_variable( 216 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/botocore/configprovider.py", line 313, in get_config_variable 217 | return provider.provide() 218 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/botocore/configprovider.py", line 410, in provide 219 | value = provider.provide() 220 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/botocore/configprovider.py", line 471, in provide 221 | scoped_config = self.session.get_scoped_config() 222 | File "/codebuild/output/src244337581/src/venv/lib/python3.8/site-packages/botocore/session.py", line 351, in get_scoped_config 223 | raise ProfileNotFound(profile=profile_name) 224 | botocore.exceptions.ProfileNotFound: The config profile (default) could not be found 225 |   226 | [Container] 2021/06/14 13:35:47 Command did not exit successfully if [ $CODEBUILD_BUILD_SUCCEEDING = 1 ]; then echo Build completed on date; echo Starting deployment; zappa update dev; else echo Build failed ignoring deployment; fi exit status 255 227 | [Container] 2021/06/14 13:35:47 Phase complete: POST_BUILD State: FAILED 228 | [Container] 2021/06/14 13:35:47 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: if [ $CODEBUILD_BUILD_SUCCEEDING = 1 ]; then echo Build completed on date; echo Starting deployment; zappa update dev; else echo Build failed ignoring deployment; fi. Reason: exit status 255 229

    Your Environment

    • Zappa version used: latest

    • Operating System and Python version: Ubuntu

    • Your zappa_settings.json: "dev": { "app_function": "app.app", "profile_name": "default", "project_name": "analytics-platform", "runtime": "python3.7", "s3_bucket": "XXX-houm-dashboard-lambda", "aws_region": "us-east-2", "timeout_seconds": 900, "memory_size": 1024, "debug": false, "cors": true, "manage_roles": false, "role_name": "XXX-dashbboard--lambda", "role_arn": "arn:aws:iam::XXXXXX:role/XXX-XXX-dashbboard--lambda", "environment_variables": { "SECRET_KEY": "XXXXXXXXX", "region": "us-east-2", "db_host": "XXXXXX", "port": "3306", "db": "XXXX_anaylytics", "user": "admin", "password": "XXXXXXXX" }

      }

    opened by sidAtHoumm 0
  • Decorating a event function may cause unexpected errors

    Decorating a event function may cause unexpected errors

    Context

    It's not technically a bug, but current behaviour of a mechanism to run a scheduled function just doesn't seem to be correct. Adding a very subtle, safe looking change can cause scheduled events to fail.

    Expected Behavior

    Event functions should be required to accept kwargs

    Actual Behavior

    Params passed to functions are different depending if it has varargs or not

    Possible Fix

    Make "function" in events deprecated, replace it with "handler" or some other key and add checks to ensure that function is correct.

    Steps to Reproduce

    1. Create a event function:
    def some_task():
       # do something
       return True
    
    1. Add it to events in zappa_settings.json
    "events": [
         {
             "function": "my_tasks.some_task",
             "expression": "cron(0 1 * * ? *)"
         }
    ]
    
    1. One day someone adds a generic decorator:
    def generic_decorator(func):
       @wraps(func)
       def wrapper(*args, **kwargs):
           # do something
           return func(*args, **kwargs)
       return wrapper
    
    @generic_decorator
    def some_task():
       # do something
       return True
    
    1. Task fails at night. event and context variables get passed to some_task, but it doesn't accept any arguments. Works like a charm in unit tests.

    Your Environment

    n/a

    opened by mlubimow 0
  • Bump pyyaml from 5.3.1 to 5.4

    Bump pyyaml from 5.3.1 to 5.4

    Bumps pyyaml from 5.3.1 to 5.4.

    Changelog

    Sourced from pyyaml's changelog.

    5.4 (2021-01-19)

    Commits
    • 58d0cb7 5.4 release
    • a60f7a1 Fix compatibility with Jython
    • ee98abd Run CI on PR base branch changes
    • ddf2033 constructor.timezone: _copy & deepcopy
    • fc914d5 Avoid repeatedly appending to yaml_implicit_resolvers
    • a001f27 Fix for CVE-2020-14343
    • fe15062 Add 3.9 to appveyor file for completeness sake
    • 1e1c7fb Add a newline character to end of pyproject.toml
    • 0b6b7d6 Start sentences and phrases for capital letters
    • c976915 Shell code improvements
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 1
  • Bump jinja2 from 2.11.2 to 2.11.3

    Bump jinja2 from 2.11.2 to 2.11.3

    Bumps jinja2 from 2.11.2 to 2.11.3.

    Release notes

    Sourced from jinja2's releases.

    2.11.3

    This contains a fix for a speed issue with the urlize filter. urlize is likely to be called on untrusted user input. For certain inputs some of the regular expressions used to parse the text could take a very long time due to backtracking. As part of the fix, the email matching became slightly stricter. The various speedups apply to urlize in general, not just the specific input cases.

    Changelog

    Sourced from jinja2's changelog.

    Version 2.11.3

    Released 2021-01-31

    • Improve the speed of the urlize filter by reducing regex backtracking. Email matching requires a word character at the start of the domain part, and only word characters in the TLD. :pr:1343
    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 1
Releases(0.51.0)
Owner
Rich Jones
Î̢̢ ̢̢̢̢̢̛ͪ̄̂å̢̢̢̢̢̢̜͐͢͝m̢̢ͦ ̢̢ͭa̢̢̝ ̢̢̢̢̢̢̗̱̩̆̅h̢̢̢ͩͭṵ̢̢̢͒ṃ̵̢̢̢̢̢̢ͮ͌̇a̢̢̢̢̢̟͂̌͠n̢̢̢̘ͨ ̵̢̢͉b̢̢̢̢̞͡ͅu̢̢̢̢̢̢͒͌͌́̕g̢͏̢ ̴̢̢̢̢ͤ͢r̢̢̄҉̢̢̱e̢̢͑p̢̢̒o̢̢̢̢̹r̷̢̢̢͊t̢̢͑.
Rich Jones
A comprehensive reference for all topics related to building and maintaining microservices

This pandect (πανδέκτης is Ancient Greek for encyclopedia) was created to help you find and understand almost anything related to Microservices that i

Ivan Bilan 45 Sep 30, 2021
Goblet is an easy-to-use framework that enables developers to quickly spin up fully featured REST APIs with python on GCP

GOBLET Goblet is a framework for writing serverless rest apis in python in google cloud. It allows you to quickly create and deploy python apis backed

Austen 30 Oct 13, 2021
Embrace the APIs of the future. Hug aims to make developing APIs as simple as possible, but no simpler.

Read Latest Documentation - Browse GitHub Code Repository hug aims to make developing Python driven APIs as simple as possible, but no simpler. As a r

Hug API Framework 6.6k Oct 18, 2021
Swagger/OpenAPI First framework for Python on top of Flask with automatic endpoint validation & OAuth2 support

Connexion Connexion is a framework that automagically handles HTTP requests based on OpenAPI Specification (formerly known as Swagger Spec) of your AP

Zalando SE 3.8k Oct 22, 2021
Swagger/OpenAPI First framework for Python on top of Flask with automatic endpoint validation & OAuth2 support

Connexion Connexion is a framework that automagically handles HTTP requests based on OpenAPI Specification (formerly known as Swagger Spec) of your AP

Zalando SE 3.5k Feb 17, 2021
The Modern And Developer Centric Python Web Framework. Be sure to read the documentation and join the Slack channel questions: http://slack.masoniteproject.com

NOTE: Masonite 2.3 is no longer compatible with the masonite-cli tool. Please uninstall that by running pip uninstall masonite-cli. If you do not unin

Masonite 1.7k Oct 23, 2021
WebSocket and WAMP in Python for Twisted and asyncio

Autobahn|Python WebSocket & WAMP for Python on Twisted and asyncio. Quick Links: Source Code - Documentation - WebSocket Examples - WAMP Examples Comm

Crossbar.io 2.3k Oct 12, 2021
FastAPI framework, high performance, easy to learn, fast to code, ready for production

FastAPI framework, high performance, easy to learn, fast to code, ready for production Documentation: https://fastapi.tiangolo.com Source Code: https:

Sebastián Ramírez 37.2k Oct 23, 2021
NO LONGER MAINTAINED - A Flask extension for creating simple ReSTful JSON APIs from SQLAlchemy models.

NO LONGER MAINTAINED This repository is no longer maintained due to lack of time. You might check out the fork https://github.com/mrevutskyi/flask-res

null 1k Oct 20, 2021
NO LONGER MAINTAINED - A Flask extension for creating simple ReSTful JSON APIs from SQLAlchemy models.

NO LONGER MAINTAINED This repository is no longer maintained due to lack of time. You might check out the fork https://github.com/mrevutskyi/flask-res

null 1k Jan 15, 2021
Library for building WebSocket servers and clients in Python

What is websockets? websockets is a library for building WebSocket servers and clients in Python with a focus on correctness and simplicity. Built on

Aymeric Augustin 3.6k Oct 24, 2021
A public API written in Python using the Flask web framework to determine the direction of a road sign using AI

python-public-API This repository is a public API for solving the problem of the final of the AIIJC competition. The task is to create an AI for the c

Lev 1 Oct 16, 2021
The no-nonsense, minimalist REST and app backend framework for Python developers, with a focus on reliability, correctness, and performance at scale.

The Falcon Web Framework Falcon is a reliable, high-performance Python web framework for building large-scale app backends and microservices. It encou

Falconry 8.6k Oct 21, 2021
Chisel is a light-weight Python WSGI application framework built for creating well-documented, schema-validated JSON web APIs

chisel Chisel is a light-weight Python WSGI application framework built for creating well-documented, schema-validated JSON web APIs. Here are its fea

Craig Hobbs 2 Oct 1, 2021
bottle.py is a fast and simple micro-framework for python web-applications.

Bottle: Python Web Framework Bottle is a fast, simple and lightweight WSGI micro web-framework for Python. It is distributed as a single file module a

Bottle Micro Web Framework 7.4k Oct 23, 2021
News search API developed for the purposes of the ColdCase Project.

Saxion - Cold Case - News Search API Setup Local – Linux/MacOS Make sure you have python 3.9 and pip 21 installed. This project uses a MySQL database,

Dimitar Rangelov 3 Jul 1, 2021
Asynchronous HTTP client/server framework for asyncio and Python

Async http client/server framework Key Features Supports both client and server side of HTTP protocol. Supports both client and server Web-Sockets out

aio-libs 11.8k Oct 23, 2021
Appier is an object-oriented Python web framework built for super fast app development.

Joyful Python Web App development Appier is an object-oriented Python web framework built for super fast app development. It's as lightweight as possi

Hive Solutions 116 Oct 2, 2021
APIFlask is a lightweight Python web API framework based on Flask and marshmallow-code projects

APIFlask APIFlask is a lightweight Python web API framework based on Flask and marshmallow-code projects. It's easy to use, highly customizable, ORM/O

Grey Li 316 Oct 15, 2021