text: [![NPM version][npm-image]][npm-url] [![Build status][travis-image]][travis-url] [![Test coverage][codecov-image]][codecov-url] [![Dependency Status][david-image]][david-url] [![License][license-image]][license-url] [![Downloads][downloads-image]][downloa
  Slowly modularize your app into AWS Lambda Functions.
  In our example, we create a lambda function around bcryptjs. Password hashing is a good use-case for lambda since it's CPU intensive, is a very simple function, and can be easily outsourced to Lambda.
  Suppose you have lambda functions
  bcrypt-compare and
  bcrypt-hash defined in your app:
  lambdas/bcrypt-compare/index.jslambda.jsonpackage.jsonbcrypt-hash/index.jslambda.jsonpackage.jsonserver/index.js
  From
  server/index.js, you can
  theta/require any lambda function:
  import lambda from 'theta/require'const bcryptCompare = lambda'bcrypt-compare'bcryptComparepassword: 'mypassword'hash: '$some$bcrypt$hash'thenvalid =>console.logvalid
  By default, the local version of the lambda is used. In other words, in development, AWS Lambdas are not actually used. This makes development and testing both simpler and faster.
  In production, lambdas are used by default.
  You can also enable lambdas using the environment variable
  THETA_ENABLED=1.
  Each lambda could have its own dependencies via
  package.json.
  For example,
  lambdas/bcrypt-compare might have:
  However, you could also require other modules within your app and not define your explicitly
  require()d dependencies in each lambda.
  import fn from '../../lib/fn'export defaultreturn fneventthenval => contextsucceedval err => contextfailerr
  theta will:
  package.jsonby crawling through the dependency tree.
  Each lambda is published with its
  package.json's name and the git repository's git commit as the version.
  This means that each commit of your app will have its own set of lambdas.
  The publishing logic is as follows:
  package.json
  index.jsfile and save it into the temporary directory as
  index.js
  npm install --saveall the crawled dependencies of the lambda
  Compiling is done with the
  theta push command.
  Each lambda should have its own tests.
  theta test will run all of your lambdas' tests locally.
  theta will run the tests using lambdas after publishing.
  You could test your app both with and without Lambdas.
  One way is to run parallel tests (one test with
  THETA_ENABLED=1, one without).
  Another is to run separate tests (i.e. Lambda functions only) in parallel to actual tests.
  theta push takes a while to run.
  It's intended to be run in your CI, never locally.
  Here's what your test script could look like:
  # run tests locally without remote lambdasnpm test# create your lambda functions./node_modules/theta push# run the tests again with remote lambdasTHETA_ENABLED=1 npm test
  Push all your lambda functions to AWS.
  Options:
  --test- run all the tests against the lambda functions as they are published
  Run all your lambda tests locally.
  Acts kind of like
  require().
  See below:
  Require a lambda function. Depending on the configuration, this could just run the JS locally or it could be running the lambda remotely.
  name- the name of the lambda
  The first set of options are the Lambda Invoke options:
  InvocationType
  LogType
  Qualifier
  The second set of options are
  theta options:
  remote- overriding
  THETA_ENABLED, whether to use a Lambda
  Calls a lambda function.
  context is optional.
  The function always returns a
  Promise instance,
  even if the underlying lambda function is synchronous.
  theta environment variables:
  THETA_ENABLED <optional>- whether
  theta/requireuses lambdas or not.
  THETA_PATH <optional>- the path of the
  lambdas/folder defaulting to
  path.resolve('lambdas')
  AWS environment variables (which can just be set in
  lambdas/config.js below):
  AWS_ACCESS_KEY_ID
  AWS_SECRET_ACCESS_KEY
  AWS_REGION
  AWS_LAMBDA_ROLE
  The babel configuration to be used when bundling your lambda function. If not defined, the following configuration will be used:
  Note that this will overwrite any other
  .babelrc.
  Configuration for all your lambdas.
  Optional options for each of your lambdas
  thetawill include any
  require()d modules in the lambda. For example, refactor to do
  import fn from 'lib/fn'instead of
  import { fn } from 'lib'
  __dirnameand
  __filenameare not supported. Do not use these when the module will be used in lambda functions.
  imported down the lambda's dependency tree, you should add it in the lambda's
  package.jsonor
  lambdas/package.json.