Our great sponsors
-
The example application is a service that performs mathematical operations. It's a pointless service, or rather its only point is to provide an excuse for me to talk about structuring the project. The shared code is located in the layer/shared folder, while the lambda handlers live in the functions folder. Tests have been separated from the application code in the tests folder - since we don't want them to be included with the deployed code.
-
This structure is essentially a variant of what's known as the src package layout - with the src directory renamed as layer. For this project I'm using setuptools as the packaging tool, and I'm configuring the package declaratively using a setup.cfg file.
-
Scout APM
Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.
-
The first step is to turn the internal package into a wheel (a *.whl file). We can use the build tool for this purpose. After installing build with pip we can run it as follows:
-
There is a closed issue in the mypy repo with a discussion about this problem. The problem can be boiled down to this: mypy only understands Python packages and relationships between them, while our functions folder holds multiple discrete, parallel entry-points into the codebase that don't make sense when interpreted as a package. Contents of the functions directory, in other words, is a bit like a monorepo with multiple distinct projects located in separate directories, and mypy doesn't understand monorepos.
