Serverless AWS AppSync Offline Plugin

serverless-appsync-offline

This is a wrapper for the excellent AppSync Emulator.

This Plugin Requires

serverless@v1-rc.1

Features

Emulate Appsync with AppSync Emulator and depends on Serverless-AppSync-Plugin
Connect to any DynamoDB or install DynamoDB Local
Start DynamoDB Local with all the parameters supported (e.g port, inMemory, sharedDb)
Table Creation for DynamoDB Local

This plugin is updated by its users, I just do maintenance and ensure that PRs are relevant to the community. In other words, if you find a bug or want a new feature, please help us by becoming one of the contributors.

Install Plugin

npm install --save serverless-appsync-offline

Then in serverless.yml add following entry to the plugins array: serverless-appsync-offline

plugins:
  - serverless-appsync-offline

Using the Plugin

Add Appsync Resource definitions to your Serverless configuration, as defined here: https://github.com/sid88in/serverless-appsync-plugin#configuring-the-plugin

Start appsync-offline

sls appsync-offline start

All CLI options are optional:

--port            -p  Port to provide the graphgl api. Default: dynamic
--dynamoDbPort            -d  Port to access the dynamoDB. Default: dynamic
--inMemory                -i  DynamoDB; will run in memory, instead of using a database file. When you stop DynamoDB;, none of the data will be saved. Note that you cannot specify both -dbPath and -inMemory at once.
--dbPath                  -b  The directory where DynamoDB will write its database file. If you do not specify this option, the file will be written to the current directory. Note that you cannot specify both -dbPath and -inMemory at once. For the path, current working directory is <projectroot>/node_modules/serverless-appsync-offline/dynamob. For example to create <projectroot>/node_modules/serverless-appsync-offline/dynamob/<mypath> you should specify -d <mypath>/ or --dbPath <mypath>/ with a forwardslash at the end.
--sharedDb                -h  DynamoDB will use a single database file, instead of using separate files for each credential and region. If you specify -sharedDb, all DynamoDB clients will interact with the same set of tables regardless of their region and credential configuration.
--delayTransientStatuses  -t  Causes DynamoDB to introduce delays for certain operations. DynamoDB can perform some tasks almost instantaneously, such as create/update/delete operations on tables and indexes; however, the actual DynamoDB service requires more time for these tasks. Setting this parameter helps DynamoDB simulate the behavior of the Amazon DynamoDB web service more closely. (Currently, this parameter introduces delays only for global secondary indexes that are in either CREATING or DELETING status.)
--optimizeDbBeforeStartup -o  Optimizes the underlying database tables before starting up DynamoDB on your computer. You must also specify -dbPath when you use this parameter.

All the above options can be added to serverless.yml to set default configuration: e.g.

Minimum Options:

custom:
  appsync-offline:
    port: 62222
    dynamodb:
      server:
        port: 8000

All Options:

custom:
  appsync-offline:
    port: 62222
    dynamodb:
      client:
        # if endpoint is provided, no local database server is started and and appsync connects to the endpoint - e.g. serverless-dynamodb-local
        endpoint: "http://localhost:8000"
        region: localhost
        accessKeyId: a
        secretAccessKey: a
      server:
        port: 8000
        dbPath: "./.dynamodb"
        inMemory: false,
        sharedDb: false,
        delayTransientStatuses: false,
        optimizeDbBeforeStartup: false,

How to Query:

curl -X POST \
  http://localhost:62222/graphql \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: APIKEY' \
  -d '{
    "query": "{ hello { world } }"
}'

Note: If you're using API_KEY as your authenticationType, then a x-api-key header has to be present in the request. The value of the key doesn't really matter.

Using DynamoDB Local in your code

You need to add the following parameters to the AWS NODE SDK dynamodb constructor

e.g. for dynamodb document client sdk

var AWS = require('aws-sdk');

new AWS.DynamoDB.DocumentClient({
    region: 'localhost',
    endpoint: 'http://localhost:8000'
})

e.g. for dynamodb document client sdk

new AWS.DynamoDB({
    region: 'localhost',
    endpoint: 'http://localhost:8000'
})

Using with serverless-offline plugin

When using this plugin with serverless-offline, it is difficult to use above syntax since the code should use DynamoDB Local for development, and use DynamoDB Online after provisioning in AWS. Therefore we suggest you to use serverless-dynamodb-client plugin in your code.

The serverless appsync-offline start command can be triggered automatically when using serverless-offline plugin.

Add both plugins to your serverless.yml file:

plugins:
  - serverless-appsync-offline
  - serverless-offline

Make sure that serverless-appsync-offline is above serverless-offline so it will be loaded earlier.

Now your local Appsync and the DynamoDB database will be automatically started before running serverless offline.

Debugging

SLS_DEBUG=* NODE_DEBUG=appsync-* yarn offline

SLS_DEBUG=* NODE_DEBUG=appsync-* yarn sls appsync-offline start

Using with serverless-offline and serverless-webpack plugin

Run serverless offline start. In comparison with serverless offline, the start command will fire an init and a end lifecycle hook which is needed for serverless-offline and serverless-appsync-offline to switch off both resources.

Add plugins to your serverless.yml file:

plugins:
  - serverless-webpack
  - serverless-appsync-offline
  - serverless-offline #serverless-offline needs to be last in the list

custom:
  appsync-emulator:
    # when using serverless-webpack it (by default) outputs all the build assets to `<projectRoot>/.webpack/service`
    # this will let appsync-offline know where to find those compiled files
    buildPrefix: .webpack/service

Notes

The AppSync Emulator does not support CloudFormation syntax (e.g. tableName: { Ref: UsersTable }) in dataSources.

Author: Aheissenberger
Source Code: https://github.com/aheissenberger/serverless-appsync-offline
License: MIT

#serverless #aws #sync

What is GEEK

Buddha Community

Christa Stehr

1598408880

How To Unite AWS KMS with Serverless Application Model (SAM)

The Basics

AWS KMS is a Key Management Service that let you create Cryptographic keys that you can use to encrypt and decrypt data and also other keys. You can read more about it here.

Important points about Keys

Please note that the customer master keys(CMK) generated can only be used to encrypt small amount of data like passwords, RSA key. You can use AWS KMS CMKs to generate, encrypt, and decrypt data keys. However, AWS KMS does not store, manage, or track your data keys, or perform cryptographic operations with data keys.

You must use and manage data keys outside of AWS KMS. KMS API uses AWS KMS CMK in the encryption operations and they cannot accept more than 4 KB (4096 bytes) of data. To encrypt application data, use the server-side encryption features of an AWS service, or a client-side encryption library, such as the AWS Encryption SDK or the Amazon S3 encryption client.

Scenario

We want to create signup and login forms for a website.

Passwords should be encrypted and stored in DynamoDB database.

What do we need?

KMS key to encrypt and decrypt data
DynamoDB table to store password.
Lambda functions & APIs to process Login and Sign up forms.
Sign up/ Login forms in HTML.

Lets Implement it as Serverless Application Model (SAM)!

Lets first create the Key that we will use to encrypt and decrypt password.

KmsKey:
    Type: AWS::KMS::Key
    Properties: 
      Description: CMK for encrypting and decrypting
      KeyPolicy:
        Version: '2012-10-17'
        Id: key-default-1
        Statement:
        - Sid: Enable IAM User Permissions
          Effect: Allow
          Principal:
            AWS: !Sub arn:aws:iam::${AWS::AccountId}:root
          Action: kms:*
          Resource: '*'
        - Sid: Allow administration of the key
          Effect: Allow
          Principal:
            AWS: !Sub arn:aws:iam::${AWS::AccountId}:user/${KeyAdmin}
          Action:
          - kms:Create*
          - kms:Describe*
          - kms:Enable*
          - kms:List*
          - kms:Put*
          - kms:Update*
          - kms:Revoke*
          - kms:Disable*
          - kms:Get*
          - kms:Delete*
          - kms:ScheduleKeyDeletion
          - kms:CancelKeyDeletion
          Resource: '*'
        - Sid: Allow use of the key
          Effect: Allow
          Principal:
            AWS: !Sub arn:aws:iam::${AWS::AccountId}:user/${KeyUser}
          Action:
          - kms:DescribeKey
          - kms:Encrypt
          - kms:Decrypt
          - kms:ReEncrypt*
          - kms:GenerateDataKey
          - kms:GenerateDataKeyWithoutPlaintext
          Resource: '*'

The important thing in above snippet is the KeyPolicy. KMS requires a Key Administrator and Key User. As a best practice your Key Administrator and Key User should be 2 separate user in your Organisation. We are allowing all permissions to the root users.

So if your key Administrator leaves the organisation, the root user will be able to delete this key. As you can see **KeyAdmin **can manage the key but not use it and KeyUser can only use the key. ${KeyAdmin} and **${KeyUser} **are parameters in the SAM template.

You would be asked to provide values for these parameters during SAM Deploy.

#aws #serverless #aws-sam #aws-key-management-service #aws-certification #aws-api-gateway #tutorial-for-beginners #aws-blogs

Hermann Frami

1655426640

Serverless Plugin for Microservice Code Management and Deployment

Serverless M

Serverless M (or Serverless Modular) is a plugin for the serverless framework. This plugins helps you in managing multiple serverless projects with a single serverless.yml file. This plugin gives you a super charged CLI options that you can use to create new features, build them in a single file and deploy them all in parallel

Currently this plugin is tested for the below stack only

AWS
NodeJS λ
Rest API (You can use other events as well)

Prerequisites

Make sure you have the serverless CLI installed

# Install serverless globally
$ npm install serverless -g

Getting Started

To start the serverless modular project locally you can either start with es5 or es6 templates or add it as a plugin

ES6 Template install

# Step 1. Download the template
$ sls create --template-url https://github.com/aa2kb/serverless-modular/tree/master/template/modular-es6 --path myModularService

# Step 2. Change directory
$ cd myModularService

# Step 3. Create a package.json file
$ npm init

# Step 3. Install dependencies
$ npm i serverless-modular serverless-webpack webpack --save-dev

ES5 Template install

# Step 1. Download the template
$ sls create --template-url https://github.com/aa2kb/serverless-modular/tree/master/template/modular-es5 --path myModularService

# Step 2. Change directory
$ cd myModularService

# Step 3. Create a package.json file
$ npm init

# Step 3. Install dependencies
$ npm i serverless-modular --save-dev

If you dont want to use the templates above you can just add in your existing project

Adding it as plugin

plugins:
  - serverless-modular

Now you are all done to start building your serverless modular functions

API Reference

The serverless CLI can be accessed by

# Serverless Modular CLI
$ serverless modular

# shorthand
$ sls m

Serverless Modular CLI is based on 4 main commands

sls m init
sls m feature
sls m function
sls m build
sls m deploy

init command

sls m init

The serverless init command helps in creating a basic .gitignore that is useful for serverless modular.

The basic .gitignore for serverless modular looks like this

#node_modules
node_modules

#sm main functions
sm.functions.yml

#serverless file generated by build
src/**/serverless.yml

#main serverless directories generated for sls deploy
.serverless

#feature serverless directories generated sls deploy
src/**/.serverless

#serverless logs file generated for main sls deploy
.sm.log

#serverless logs file generated for feature sls deploy
src/**/.sm.log

#Webpack config copied in each feature
src/**/webpack.config.js

feature command

The feature command helps in building new features for your project

options (feature Command)

This command comes with three options

--name: Specify the name you want for your feature

--remove: set value to true if you want to remove the feature

--basePath: Specify the basepath you want for your feature, this base path should be unique for all features. helps in running offline with offline plugin and for API Gateway

options	shortcut	required	values	default value
--name	-n	✅	string	N/A
--remove	-r	❎	true, false	false
--basePath	-p	❎	string	same as name

Examples (feature Command)

Creating a basic feature

# Creating a jedi feature
$ sls m feature -n jedi

Creating a feature with different base path

# A feature with different base path
$ sls m feature -n jedi -p tatooine

Deleting a feature

# Anakin is going to delete the jedi feature
$ sls m feature -n jedi -r true

function command

The function command helps in adding new function to a feature

options (function Command)

This command comes with four options

--name: Specify the name you want for your function

--feature: Specify the name of the existing feature

--path: Specify the path for HTTP endpoint helps in running offline with offline plugin and for API Gateway

--method: Specify the path for HTTP method helps in running offline with offline plugin and for API Gateway

options	shortcut	required	values	default value
--name	-n	✅	string	N/A
--feature	-f	✅	string	N/A
--path	-p	❎	string	same as name
--method	-m	❎	string	'GET'

Examples (function Command)

Creating a basic function

# Creating a cloak function for jedi feature
$ sls m function -n cloak -f jedi

Creating a basic function with different path and method

# Creating a cloak function for jedi feature with custom path and HTTP method
$ sls m function -n cloak -f jedi -p powers -m POST

build command

The build command helps in building the project for local or global scope

options (build Command)

This command comes with four options

--scope: Specify the scope of the build, use this with "--feature" tag

--feature: Specify the name of the existing feature you want to build

options	shortcut	required	values	default value
--scope	-s	❎	string	local
--feature	-f	❎	string	N/A

Saving build Config in serverless.yml

You can also save config in serverless.yml file

custom:
  smConfig:
    build:
      scope: local

Examples (build Command)

all feature build (local scope)

# Building all local features
$ sls m build

Single feature build (local scope)

# Building a single feature
$ sls m build -f jedi -s local

All features build global scope

# Building all features with global scope
$ sls m build -s global

deploy command

The deploy command helps in deploying serverless projects to AWS (it uses sls deploy command)

options (deploy Command)

This command comes with four options

--sm-parallel: Specify if you want to deploy parallel (will only run in parallel when doing multiple deployments)

--sm-scope: Specify if you want to deploy local features or global

--sm-features: Specify the local features you want to deploy (comma separated if multiple)

options	shortcut	required	values	default value
--sm-parallel	❎	❎	true, false	true
--sm-scope	❎	❎	local, global	local
--sm-features	❎	❎	string	N/A
--sm-ignore-build	❎	❎	string	false

Saving deploy Config in serverless.yml

You can also save config in serverless.yml file

custom:
  smConfig:
    deploy:
      scope: local
      parallel: true
      ignoreBuild: true

Examples (deploy Command)

Deploy all features locally

# deploy all local features
$ sls m deploy

Deploy all features globally

# deploy all global features
$ sls m deploy --sm-scope global

Deploy single feature

# deploy all global features
$ sls m deploy --sm-features jedi

Deploy Multiple features

# deploy all global features
$ sls m deploy --sm-features jedi,sith,dark_side

Deploy Multiple features in sequence

# deploy all global features
$ sls m deploy  --sm-features jedi,sith,dark_side --sm-parallel false

Author: aa2kb
Source Code: https://github.com/aa2kb/serverless-modular
License: MIT license

#serverless #aws #node #lambda

Hermann Frami

1651368420

Serverless AWS AppSync Offline Plugin

serverless-appsync-offline

This is a wrapper for the excellent AppSync Emulator.

This Plugin Requires

serverless@v1-rc.1

Features

Emulate Appsync with AppSync Emulator and depends on Serverless-AppSync-Plugin
Connect to any DynamoDB or install DynamoDB Local
Start DynamoDB Local with all the parameters supported (e.g port, inMemory, sharedDb)
Table Creation for DynamoDB Local

Install Plugin

npm install --save serverless-appsync-offline

Then in serverless.yml add following entry to the plugins array: serverless-appsync-offline

plugins:
  - serverless-appsync-offline

Using the Plugin

Add Appsync Resource definitions to your Serverless configuration, as defined here: https://github.com/sid88in/serverless-appsync-plugin#configuring-the-plugin

Start appsync-offline

sls appsync-offline start

All CLI options are optional:

--port            -p  Port to provide the graphgl api. Default: dynamic
--dynamoDbPort            -d  Port to access the dynamoDB. Default: dynamic
--inMemory                -i  DynamoDB; will run in memory, instead of using a database file. When you stop DynamoDB;, none of the data will be saved. Note that you cannot specify both -dbPath and -inMemory at once.
--dbPath                  -b  The directory where DynamoDB will write its database file. If you do not specify this option, the file will be written to the current directory. Note that you cannot specify both -dbPath and -inMemory at once. For the path, current working directory is <projectroot>/node_modules/serverless-appsync-offline/dynamob. For example to create <projectroot>/node_modules/serverless-appsync-offline/dynamob/<mypath> you should specify -d <mypath>/ or --dbPath <mypath>/ with a forwardslash at the end.
--sharedDb                -h  DynamoDB will use a single database file, instead of using separate files for each credential and region. If you specify -sharedDb, all DynamoDB clients will interact with the same set of tables regardless of their region and credential configuration.
--delayTransientStatuses  -t  Causes DynamoDB to introduce delays for certain operations. DynamoDB can perform some tasks almost instantaneously, such as create/update/delete operations on tables and indexes; however, the actual DynamoDB service requires more time for these tasks. Setting this parameter helps DynamoDB simulate the behavior of the Amazon DynamoDB web service more closely. (Currently, this parameter introduces delays only for global secondary indexes that are in either CREATING or DELETING status.)
--optimizeDbBeforeStartup -o  Optimizes the underlying database tables before starting up DynamoDB on your computer. You must also specify -dbPath when you use this parameter.

All the above options can be added to serverless.yml to set default configuration: e.g.

Minimum Options:

custom:
  appsync-offline:
    port: 62222
    dynamodb:
      server:
        port: 8000

All Options:

custom:
  appsync-offline:
    port: 62222
    dynamodb:
      client:
        # if endpoint is provided, no local database server is started and and appsync connects to the endpoint - e.g. serverless-dynamodb-local
        endpoint: "http://localhost:8000"
        region: localhost
        accessKeyId: a
        secretAccessKey: a
      server:
        port: 8000
        dbPath: "./.dynamodb"
        inMemory: false,
        sharedDb: false,
        delayTransientStatuses: false,
        optimizeDbBeforeStartup: false,

How to Query:

curl -X POST \
  http://localhost:62222/graphql \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: APIKEY' \
  -d '{
    "query": "{ hello { world } }"
}'

Note: If you're using API_KEY as your authenticationType, then a x-api-key header has to be present in the request. The value of the key doesn't really matter.

Using DynamoDB Local in your code

You need to add the following parameters to the AWS NODE SDK dynamodb constructor

e.g. for dynamodb document client sdk

var AWS = require('aws-sdk');

new AWS.DynamoDB.DocumentClient({
    region: 'localhost',
    endpoint: 'http://localhost:8000'
})

e.g. for dynamodb document client sdk

new AWS.DynamoDB({
    region: 'localhost',
    endpoint: 'http://localhost:8000'
})

Using with serverless-offline plugin

The serverless appsync-offline start command can be triggered automatically when using serverless-offline plugin.

Add both plugins to your serverless.yml file:

plugins:
  - serverless-appsync-offline
  - serverless-offline

Make sure that serverless-appsync-offline is above serverless-offline so it will be loaded earlier.

Now your local Appsync and the DynamoDB database will be automatically started before running serverless offline.

Debugging

SLS_DEBUG=* NODE_DEBUG=appsync-* yarn offline

SLS_DEBUG=* NODE_DEBUG=appsync-* yarn sls appsync-offline start

Using with serverless-offline and serverless-webpack plugin

Add plugins to your serverless.yml file:

plugins:
  - serverless-webpack
  - serverless-appsync-offline
  - serverless-offline #serverless-offline needs to be last in the list

custom:
  appsync-emulator:
    # when using serverless-webpack it (by default) outputs all the build assets to `<projectRoot>/.webpack/service`
    # this will let appsync-offline know where to find those compiled files
    buildPrefix: .webpack/service

Notes

The AppSync Emulator does not support CloudFormation syntax (e.g. tableName: { Ref: UsersTable }) in dataSources.

Author: Aheissenberger
Source Code: https://github.com/aheissenberger/serverless-appsync-offline
License: MIT

#serverless #aws #sync

Matt Towne

1589791867

Serverless CI/CD on the AWS Cloud

CI/CD pipelines have long played a major role in speeding up the development and deployment of cloud-native apps. Cloud services like AWS lend themselves to more agile deployment through the services they offer as well as approaches such as Infrastructure as Code. There is no shortage of tools to help you manage your CI/CD pipeline as well.

While the majority of development teams have streamlined their pipelines to take full advantage of cloud-native features, there is still so much that can be done to refine CI/CD even further. The entire pipeline can now be built as code and managed either via Git as a single source of truth or by using visual tools to help guide the process.

The entire process can be fully automated. Even better, it can be made serverless, which allows the CI/CD pipeline to operate with immense efficiency. Git branches can even be utilized as a base for multiple pipelines. Thanks to the three tools from Amazon; AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy, serverless CI/CD on the AWS cloud is now easy to set up.

#aws #aws codebuild #aws codecommit #aws codedeploy #cd #cd pipeline #ci #ci/cd processes #ci/cd workflow #serverless

Fredy Larson

1599105420

AWS AppSync: Conditional Resolvers Using the Info Context

AWS AppSync

AppSync is a managed GraphQL service offered by Amazon Web Services and can be used to build scalable enterprise APIs. A typical AppSync solution consists of small resolvers that can be combined to access various data sources such as databases, HTTP APIs or AWS Lambda.

Introduction

In this example, I will be talking about using AWS AppSync with AWS Lambda data sources and one of the challenges I have come across while developing enterprise scale solutions with these technologies.

Each Lambda resolver you have in a particular request triggers an invocation. The problem comes with having nested resolvers where you only request data from the nested Lambda rather than the parent Lambda. As a result you will cause several invocations, incur cost and resource for the first Lambda without needing to.

If you’re running enterprise serverless it is important to consider the architecture to reduce the amount of compute where possible and lower the risk of hitting limits imposed by AWS.

Thankfully, AWS released an AppSync update in Feb 2020 giving us access to the context info object so we can mitigate this issue. Read more here.

Let’s dive in! 💥

Say you have a GraphQL endpoint and schema to retrieve a typical blog post:

type Post{
  id: ID!
  title: String!
  content: String!
  image: ImageData!
}
type ImageData{
  id: ID!
  postId: ID!
  path: String!
  tags: String
}
type Query{
  getPost(id: ID!): Post!
}

Using GraphQL, your query could look like:

query GetPost{
  getPost(id: $id){
    title
    content
    image{
      path
      tags
    }
  }
}

#aws-appsync #graphql #aws-lambda #serverless #aws