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()

” 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 named handler.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)

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 and controller_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 which create is called, the result would be that app_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 and app.functions.controller_b.handler define functions that are decorated by tight.providers.aws.controllers.lambda_proxy_event the call to app_index.controller_a or app_index.controller_b will in turn call the correct handler for the request method by mapping event['httpMethod'] to the correct module function.

tight.providers.aws.lambda_app.app.run()

Call create on sys.modules['app_index'] and catch any errors.

Typical usage would be to import this module and call run immediately:

from app.vendored.tight.providers.aws.lambda_app import app
app.run()

tight.core.logger

tight.core.logger.error(*args, **kwargs)

tight.core.logger.info(*args, **kwargs)

Log a message using the system logger.

Parameters:

• args –
• kwargs –

Returns:

None

tight.core.logger.warn(*args, **kwargs)