Last Updated: 2024-04-27

How does a lambda heavy project look? Here's some observations from digging into a code-base and reading some textbooks on the topic:

Approach 1: Manual API endpoints

The typical setup is to use lambda functions attached to API endpoints.

Lambdas are often triggerred by standard HTTP requests like a normal web app

Remember here that CORS means that a (e.g.) a React.js browser app will not be allowed to talk to your API unless you add the appropriate permissions. Therefore the amazon API endpoints must have OPTIONS request ability in order to facilitate CORS requests containing specific headers e.g. Access-Control-Allow-Origin: *

Another way of stitching everything together is by subscribing to changes in an AmazonDynamoDB via a stream. Below is an explanation of DynamoDB.

Approach 2: Serverless Framework

It's a lot easier to use a framework to stitch all this stuff together than DIY in the console. Below are some examples with the serverless framework:

Here's an example config file:

service: candidate

frameworkVersion: ">=1.1.0 <2.0.0"

provider:
  name: aws
  runtime: nodejs4.3
  stage: dev
  region: us-east-1

functions:
  candidateSubmission:
    handler: api/candidates.submit
    memorySize: 128
    description: Submit candidate information and starts interview process.
    events:
      - http: 
          path: candidates
          method: post
   candidateDetails:
     handler: api/candidates.get
     events:
      - http:
          path: candidates/{id}
          method: get
          cors: true

What are the most important bits of info here?

• use the serverless framework version 1.1 to 2
• use AWS as a provider (serverless accepts other providers), along with a certain region and programming language
• and then have the lambda named candidateSubmission available at POST /candidates and defined in the file api/candidates.submit
• and another lambda GET candidates/{id}. This one also defines a default CORS header that enables any domain to request this.

Approach 3: DynamoDB

Some info on DynamoDB:

• DynamoDB is based on SSD drives
• it lets you choose between eventually consistent (e.g. reads may differ one second after update) and strongly consistent
• the data is 3x redundant in 3 AZs. Besides safety, this helps scalability and high performance.
• DynamoDB stores its data in tables. Each table contains a set of items, and each item has a set of fields or attributes.
• The DynamoDB is basically a key-value store. It can either have one key (like memcached) for simple GET operations or a composite key (e.g. "orders" and "1") which allows for complex operations like scanning. DynamoDB can store strings, binary data, numbers, lists, and sets.
• Being a key-value store, DynamoDB is especially easy to use in cases where a single item in a single DynamoDB table contains all the data you need for a discrete action in your application. For example, if your application dashboard displays a user and the books they have read, DynamoDB will perform best and cost the least per request if those books reside in the User object. But storing the users in one table and the books in another, where loading the page requires getting one user and ten different book records, might make DynamoDB less of a good fit: extra queries cost you more and slow down your overall application experience compared to a relational datastore. When choosing between DynamoDB and RDS, you might ask yourself the following question: is the data I’ll be storing self-contained (i.e., will a single item contain all the information to be queried) or will it require multiple tables and joining data across them to get the data your application needs?
• A DynamoDB stream really means the stream of changes. It is not the same as the data. It is really a changeset of inserts, updates, and deletions. It is ordered by time and kept around for 24 hours (in case you have downtime)
• You can specify if the stream contains the key only, or some combination of the new and old data (or rather "image") in their lingo.

Here is an example setup for DynamoDB using the serverless framework

  service: usersCrud
  provider: aws
  functions:
  # Your Serverless function definitions go here.

  resources: # raw AWS::CloudFormation template syntax from here on.
    Resources:
      usersTable: 
        Type: AWS::DynamoDB::Table
        Properties:
          TableName: usersTable
          AttributeDefinitions:
            - AttributeName: email
              AttributeType: S
          KeySchema:
            - AttributeName: email
              KeyType: HASH
          ProvisionedThroughput:
            ReadCapacityUnits: 1
            WriteCapacityUnits: 1

This creates a usersTable with an email attribute that is of type string (S)

Next example: Let's provision a DynamoDB with certain iam role credentials:

provider:
  name: aws
  runtime: nodejs4.3
  stage: dev
  region: us-east-1
  environment:
    CANDIDATE_TABLE: ${self:service}-${opt:stage, self:provider.stage}
    CANDIDATE_EMAIL_TABLE: "candidate-email-${opt:stage, self:provider.stage}"
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
      Resource: "*"

resources:
  Resources:
    CandidatesDynamoDbTable:
        TableName: ${self:provider.environment.CANDIDATE_TABLE}
        ...

• then we have some iamrole stuff to allow certain actions
• here we also see the definition of some general environment variables like CANDIDATETABLE and its use in the last line. It will also be available in the node process.env (i think at least_)

Other tidbits

• AWS SNS is used for sending messages e.g. emails

• Beware: A major limitiation is that Lambda functions timeout after a short amount of time

Resources

• https://serverless.com/dynamodb/