AWS-Lambda-Quick

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

1.0002 2019-12-15

- FEATURE: Create greedy proxy URLs for Lambda functions

1.0001 (internal release)

- BUGFIX: Fix accidental line deletion (oops)
- BUGFIX: Use the correct prebuilt public lambda layer in me-south-1
- FEATURE: Add support for extra layers

1.0000   2019-12-14

- Initial release

README.md  view on Meta::CPAN

not familiar with AWS this is somewhat like specifying a path for the
API to be callable on.) This will be created directly off the top level
resource (i.e. off of "/") and will be named after the name of the
Lambda function (i.e. calling `use AWS::Lambda::Quick (name =` "foo")>
will create a resource `/foo`)

### Create a new method

Each Lambda function we create gets its own method, which is where
AWS specifies what HTTP method it accepts (`GET`,`POST`,`PUT`,
etc.) and how it decides who can access it.

This module always sets the type of method to `ANY` (i.e. we always
call the lambda function and let it figure out what it wants to accept
or not.)

We setup the `NONE` authentication, meaning anyone can call the API
over the internet - i.e. it's configured as a public API.

### Create a new integration

Integrations are how AWS decides both where a request is routed to
and what extracted from that HTTP request is passed on and how.

We configure an AWS\_PROXY integration routing to our new Lambda
function.  This essentially means everything is passed "as is"
through to our handler as the first argument.

Upload and GET the following to see what is being passed in
your environment:

    #!/usr/bin/perl

lib/AWS/Lambda/Quick.pm  view on Meta::CPAN

not familiar with AWS this is somewhat like specifying a path for the
API to be callable on.) This will be created directly off the top level
resource (i.e. off of "/") and will be named after the name of the
Lambda function (i.e. calling C<use AWS::Lambda::Quick (name => "foo")>
will create a resource C</foo>)

=head3 Create a new method

Each Lambda function we create gets its own method, which is where
AWS specifies what HTTP method it accepts (C<GET>,C<POST>,C<PUT>,
etc.) and how it decides who can access it.

This module always sets the type of method to C<ANY> (i.e. we always
call the lambda function and let it figure out what it wants to accept
or not.)

We setup the C<NONE> authentication, meaning anyone can call the API
over the internet - i.e. it's configured as a public API.

=head3 Create a new integration

Integrations are how AWS decides both where a request is routed to
and what extracted from that HTTP request is passed on and how.

We configure an AWS_PROXY integration routing to our new Lambda
function.  This essentially means everything is passed "as is"
through to our handler as the first argument.

Upload and GET the following to see what is being passed in
your environment:

    #!/usr/bin/perl

perlcriticrc  view on Meta::CPAN

[-ErrorHandling::RequireCarping]
[-InputOutput::RequireBriefOpen]

[-ValuesAndExpressions::ProhibitConstantPragma]

# No need for /xsm everywhere
[-RegularExpressions::RequireDotMatchAnything]
[-RegularExpressions::RequireExtendedFormatting]
[-RegularExpressions::RequireLineBoundaryMatching]

# by concensus in standup 2015-05-12 we decided to allow return undef
# this is mainly so bar can be written to return undef so that
# foo( bar => bar(), bazz => baz() ) won't cause problems
[-Subroutines::ProhibitExplicitReturnUndef]

# This incorrectly thinks signatures are prototypes.
[-Subroutines::ProhibitSubroutinePrototypes]

# http://stackoverflow.com/questions/2275317/why-does-perlcritic-dislike-using-shift-to-populate-subroutine-variables
[-Subroutines::RequireArgUnpacking]