tight
¶
tight.providers
¶
The tight
package currently supports only one provider: AWS.
tight.providers.aws.lambda_app.app
¶
Use this package to create an entry point module. Typical usage is quite simple, as demonstrated in the following code example. Read on to learn about how module internals work.
from app.vendored.tight.providers.aws.lambda_app import app
app.run()
When creating an app using tight-cli
a file, app_index.py, will be automatically generated which will contain code like the snippet above.
-
tight.providers.aws.lambda_app.app.
collect_controllers
()[source]¶ ” Inspect the application directory structure and discover controller modules.
Given the following directory structure, located at
TIGHT.APP_ROOT
:|-app_index.py |-app/ |---functions/ |-----controller_a/ |-------handler.py |-----controller_b/ |-------handler.py |-----not_a_controller/ |-------some_module.py
Descend into
TIGHT.APP_ROOT/app/functions
and collect the names of directories that contain a file namedhandler.py
. The directory structure above would produce the return value:['controller_a', 'controller_b']
Return type: list Returns: A list of application controller names.
-
tight.providers.aws.lambda_app.app.
create
(current_module)[source]¶ Attach functions to the app entry module.
Introspect the application function root and create function attributes on the provided module that map to each application controller. An application controller is defined as any directory in the app root that contains a handler.py file. The name of the controller is the enclosing directory.
Given the following app structure:
|-app_index.py |-app/ |---functions/ |-----controller_a/ |-------handler.py |-----controller_b/ |-------handler.py |-----not_a_controller/ |-------some_module.py
The controller names collected would be:
controller_a
andcontroller_b
Notice that not_a_controller is omitted because there is no handler.py file in the directory.
Assuming that
app_index.py
is the module from whichcreate
is called, the result would be thatapp_index.py
will behave as if it had been statically defined as:def controller_a(controller_module_path, controller_name, event, context): controller_module_path # 'app.functions.controller_a.handler' controller_name # controller_a callback = importlib.import_module(controller_module_path, 'handler') return callback.handler(event, context, **kwargs) def controller_b(controller_module_path, controller_name, event, context): controller_module_path # 'app.functions.controller_b.handler' controller_name # controller_b callback = importlib.import_module(controller_module_path, 'handler') return callback.handler(event, context, **kwargs)
This means that the handler value provided to lambda can follow the format:
'app_index.controller_a' 'app_index.controller_b'
So long as
app.functions.controller_a.handler
andapp.functions.controller_b.handler
define functions that are decorated bytight.providers.aws.controllers.lambda_proxy_event
the call toapp_index.controller_a
orapp_index.controller_b
will in turn call the correct handler for the request method by mappingevent['httpMethod']
to the correct module function.