Chalice: Middleware support?

[brylie]

Often times, developers want to wrap and share common functionality and insert those functions as part of a middleware pattern. Since Chalice is providing a 'pythonic' way of developing AWS services, it may be worth defining/adopting a common pattern for application middleware. What are some concerns and issues related to providing middleware functionality for AWS applications, in a pythonic manner?

Rationale

Taken verbatim from the middy website:

One of the main strengths of serverless and AWS Lambda is that, from a developer perspective, your focus is mostly shifted toward implementing business logic.

Anyway, when you are writing a handler, you still have to deal with some common technical concerns outside business logic, like input parsing and validation, output serialization, error handling, etc.

Very often, all this necessary code ends up polluting the pure business logic code in your handlers, making the code harder to read and to maintain.

In other contexts, like generic web frameworks (express, fastify, hapi, etc.), this problem has been solved using the middleware pattern.

This pattern allows developers to isolate these common technical concerns into “steps” that decorate the main business logic code. Middleware functions are generally written as independent modules and then plugged in into the application in a configuration step, thus not polluting the main business logic code that remains clean, readable and easy to maintain.

decorator pattern

From the lambda_decorators website:

when using python, decorators pretty much are middleware!

Related resources

• lambda_decorators - a collection of useful decorators for writing Python handlers for AWS Lambda. They allow you to avoid boiler plate for common things such as CORS headers, JSON serialization, etc.
• aws-wsgi - AWSGI allows you to use WSGI-compatible middleware and frameworks like Flask and Django with the AWS API Gateway/Lambda proxy integration.

[bugeats]

This this this.

As it's structured right now, using decorators in Chalice is NOT a substitute for a middlware layer that has the opportunity to modify the entire request/response cycle.

[jamesls]

I would love to have middleware in Chalice. I know there's been discussions about this before, I think we just need to work out the API for this.

We could model middleware similar to existing web frameworks, but we also support other lambda event handlers besides rest APIs (e.g. SNS, SQS, S3, etc.). It seems like we'd want to have some design that works for all lambda functions in chalice.

Or perhaps we have separate rest API middleware, and then a separate middleware API for the other event handlers.

At any rate, I'd like to add this. We just need to work out the API for it.

[jcampanello]

I think it will be good to have. Is there any plan or estimated date for implementing this?

Two comments on this:

1. when defining a route, i think it will be good to be able to define extra parameters for the route that the middleware needs (ex: a json-schema middleware input validator will require the schema associated to the route). Perhaps is a better design to annotate for the specific middleware to not polute the route. If this is the case, i think a base middleware class should have the support for annotation...? Or a generic annotation method should be provided, ex: @app.middleware("name", **kwargs)

2. i think that CORS should actually be a middleware...? I am using (and have used) the HTTP OPTIONS method to return metadata (such as json-schema) and blocking the OPTIONS method with CORS is not necessary in my opinion. Perhaps both options (route option and middleware) are possible?

[jayrogers889csa]

Yes +1 to @jcampanello ideas, particularly around schema validation. Lots of inspiration from Django REST framework around this.

[jamesls]

Implemented in https://github.com/aws/chalice/pull/1514