How to Name Handlers

[freeformflow]

Right now, we rely on a convention for Lambda names:

appName-environment-resource-HttpVerb

Sky assumes this pattern when it creates and names Lambdas, but that's not enforced in the actual code that constitutes Lambdas. So, within the code, we are relying on convention.

We should solidify our design and then enforce it, both in the CloudFormation template and the Lambda code.

[automatthew]

With the request Mapping Template now transforming the Lambda events into Panda Request Representation, we now have access to the HTTP Method in the event object passed to the Lambda handler.

This opens up some new possibilities that I need to muse on.

[automatthew]

Consider this as a new approach to the Sky Lambda dispatcher:

exports.handle = (request, context, callback) ->
  resource = Blurb.getResource(context)
  methodName = request.method
  resource[methodName](request, context)
  .then (result) ->
    callback null, result
  .catch (e) ->
    callback e

[automatthew]

resource = Blurb.getResource(context) could be handled in at least a couple of ways.

1. using conventions in context.functionName as at present
2. determining the API Gateway "resource path" using a Mapping Template and $context.resource_path. This provides the parameterized resource path, e.g. "/request-mapping-test/{key}"

[automatthew]

Currently in the CloudFormation template:

  BlurbGetLambdaHandler:
    Type: 'AWS::Lambda::Function'
    Properties:
      Description: Handler for APIblurb9
      FunctionName: blurb9-staging-blurb-get

[automatthew]

We could simplify by having one Lambda per resource, instead of per (resource X method).

[automatthew]

In API Gateway, we can determine the deployment environment using Mapping Template's $context.stage. This means we don't necessarily need to put it in the Lambda FunctionName, just to get Sky dispatching working. We may still need it as part of namespacing Lambdas themselves.

[automatthew]

https://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html

[automatthew]

https://aws.amazon.com/blogs/compute/using-api-gateway-stage-variables-to-manage-lambda-functions/

[automatthew]

Implication of the above two links is that we may be able use API Gateway stageVariables instead of putting stage names in our function names.

[automatthew]

semi-helpful discussion: https://forums.aws.amazon.com/thread.jspa?messageID=681736

[automatthew]

I have not found any AWS native way to deal with the application namespacing (e.g. "blurb9") though.

[automatthew]

It's risky to jump straight into trusting all the AWS affordances I've just described. Here's an idea for the next safe step:

exports.handle = (request, context, callback) ->
  [_app, _stage, resource] = context.functionName.split('-')
  resource = Blurb9.getResource(resource)
  methodName = request.method
  resource[methodName](request, context)
  .then (result) ->
    callback null, result
  .catch (e) ->
    callback e

[automatthew]

This moves us one---very important---step closer to isomorphism between the AWS concepts and the Sky API concepts.

[automatthew]

Blurb9 = Sky.API
  resources:
    Blurbs: require "./resources/blurbs"
    Blurb: require "./resources/blurb"

[dyoder]

• One lambda per resources makes sense, given that we're providing helper methods to unpack this anyway.

• We can also make the callback go away with a helper.

• Why is the request not part of the context?

[automatthew]

We can also make the callback go away with a helper.

Yeah, in a variety of ways. My code example is just a riff on the current helper.

Why is the request not part of the context?

Because AWS has them as separate (confusing) arguments. In these examples, I'm trying to cleave close to our existing work and the AWS apis, to make it easier to see what's going on.

[automatthew]

Both "API Gateway Mapping Templates" and "Lambda handler functions" use the term context, and it means totally different things. Which is unfortunate and confusing, but eh.

[automatthew]

With the sky.method wrapper I describe elsewhere, we get to provide our own interface to these resource-method functions, so we can easily reorganize the information into a single skyContext if we so desire.