serverless/serverless

⚡ Serverless Framework – Use AWS Lambda and other managed cloud services to build apps that auto-scale, cost nothing when idle, and boast radically low maintenance.

Website • Docs • Community Slack • Forum • Twitter • Meetups

The Serverless Framework – Build applications on AWS Lambda and other next-gen cloud services, that auto-scale and only charge you when they run. This lowers the total cost of running and operating your apps, enabling you to build more and manage less.

The Serverless Framework is a command-line tool with an easy and approachable YAML syntax to deploy both your code and cloud infrastructure needed to make tons of serverless application use-cases. It's a multi-language framework that supports Node.js, Typescript, Python, Go, Java, and more. It's also completely extensible via over 1,000 plugins which add more serverless use-cases and workflows to the Framework.

Actively maintained by Serverless Inc.

Contents

• Features
• Quick Start
• Plugins
• Contributing
• Community
• Licensing

Features

• Hyper-Productive - Build more and manage less with serverless architectures.
• Multiple Use-Cases - Choose from tons of efficient serverless use-cases (APIs, Scheduled Tasks, Event Handlers, Streaming Data Pipelines, Web Sockets & more).
• Infra & Code - Deploys both code and infrastructure together, resulting in out-of-the-box serverless apps.
• Easy - Enjoy simple syntax to safely deploy deploy AWS Lambda functions, event sources and more without being a cloud expert.
• Multi-Language - Supports Node.js, Python, Java, Go, C#, Ruby, Swift, Kotlin, PHP, Scala, & F#
• Full Lifecycle - Manages the lifecycle of your serverless architecture (build, deploy, update, monitor, troubleshoot).
• Multi-Domains - Group domains into Serverless Services for easy management of code, resources & processes, across large projects & teams.
• Multi-Environments - Built-in support for multiple stages (e.g. development, staging, production).
• Guardrails - Loaded with automation, optimization and best practices.
• Extensible - Extend or modify the Framework and its operations via Plugins.
• Plugin Ecosystem - Extend or modify the Framework and its operations via Plugins.
• Welcoming - A passionate and welcoming community!

Quick Start

Here's how to get started quickly, as well as some recommended development workflows.

Installation

Install serverless module via NPM:

npm install -g serverless

If you don’t already have Node.js on your machine, install it first. If you don't want to install Node or NPM, you can install serverless as a standalone binary.

Creating A Service

To create your first project (known as a Serverless Framework "Service"), run the serverless command below, then follow the prompts.

# Create a new serverless project
serverless

# Move into the newly created directory
cd your-service-name

The serverless command will guide you to:

1. Create a new project
2. Configure your AWS credentials
3. Optionally set up a free Serverless Framework account with additional features.

Your new serverless project will contain a serverless.yml file. This file features simple syntax for deploying infrastructure to AWS, such as AWS Lambda functions, infrastructure that triggers those functions with events, and additional infrastructure your AWS Lambda functions may need for various use-cases. You can learn more about this in the Core Concepts documentation.

The serverless command will give you a variety of templates to choose from. If those do not fit your needs, check out the project examples from Serverless Inc. and our community. You can install any example by passing a GitHub URL using the --template-url option:

serverless --template-url=https://github.com/serverless/examples/tree/v3/...

Please note that you can use serverless or sls to run Serverless Framework commands.

Deploying

If you haven't done so already within the serverless command, you can deploy the project at any time by running:

sls deploy

The deployed AWS Lambda functions and other essential information such as API Endpoint URLs will be displayed in the command output.

More details on deploying can be found here.

Developing On The Cloud

Many Serverless Framework users choose to develop on the cloud, since it matches reality and emulating Lambda locally can be complex. To develop on the cloud quickly, without sacrificing speed, we recommend the following workflow...

To deploy code changes quickly, skip the serverless deploy command which is much slower since it triggers a full AWS CloudFormation update. Instead, deploy code and configuration changes to individual AWS Lambda functions in seconds via the deploy function command, with -f [function name in serverless.yml] set to the function you want to deploy.

sls deploy function -f my-api

More details on the deploy function command can be found here.

To invoke your AWS Lambda function on the cloud, you can find URLs for your functions w/ API endpoints in the serverless deploy output, or retrieve them via serverless info. If your functions do not have API endpoints, you can use the invoke command, like this:

sls invoke -f hello

# Invoke and display logs:
serverless invoke -f hello --log

More details on the invoke command can be found here.

To stream your logs while you work, use the sls logs command in a separate terminal window:

sls logs -f [Function name in serverless.yml] -t

Target a specific function via the -f option and enable streaming via the -t option.

Developing Locally

Many Serverless Framework users rely on local emulation to develop more quickly. Please note, emulating AWS Lambda and other cloud services is never accurate and the process can be complex. We recommend the following workflow to develop locally...

Use the invoke local command to invoke your function locally:

sls invoke local -f my-api

You can also pass data to this local invocation via a variety of ways. Here's one of them:

serverless invoke local --function functionName --data '{"a":"bar"}'

More details on the invoke local command can be found here

Serverless Framework also has a great plugin that allows you to run a server locally and emulate AWS API Gateway. This is the serverless-offline command.

More details on the serverless-offline plugins command can be found here

Monitoring, Secrets & Collaboration

If you're looking for easy, out-of-the-box monitoring, secrets management and collaboration features, sign into the Serverless Framework Dashboard. It's free!

sls login

Remove your service

If you want to delete your service, run remove. This will delete all the AWS resources created by your project and ensure that you don't incur any unexpected charges. It will also remove the service from Serverless Dashboard.

sls remove

More details on the remove command can be found here.

What's Next

Here are some helpful resources for continuing with the Serverless Framework:

• Study Serverless Framework's core concepts
• Get inspiration from these Serverless Framework templates
• Discover all of the events that can trigger Lambda functions
• Bookmark Serverless Framework's serverless.yml guide
• Search the plugins registry to extend Serverless Framework

Contributing

We love our contributors! Please read our Contributing Document to learn how you can start working on the Framework yourself.

Check out our help wanted or good first issue labels to find issues we want to move forward on with your help.

Community

• Twitter
• Community Slack
• Serverless Meetups
• Stackoverflow
• Facebook
• Contact Us

Licensing

Serverless is licensed under the MIT License.

All files located in the node_modules and external directories are externally maintained libraries used by this software which have their own licenses; we recommend you read them, as their terms may differ from the terms in the MIT License.

serverless's Issues

Deployed Lambda not available as resource

Hey Austen,

Thanks for putting this together, I've been reading a lot about Lambda's recently and this was the inspiration I needed to dive in.

I am running into an issue deploying Lambda's that I'm hoping you can shed some light on.

I'm not sure if it is a false positive deployment or not, but the lambda never shows up in the AWS console.

Keep up the great work,
Austin

Your Input Is Needed For JAWS V1

We've listened to everyone's requests and I sincerely think we've implemented all of them!

Please take a second to review the specifications for JAWS v1 in the Google Document located below.

You can comment on the document. Bigger spec issues should be posted as a new issue and prefixed with SPEC V1: in the Issue title.

I hope you all like this. We're working hard to deliver the greatest server-less framework ever (powered by AWS, of course).

Cheers,
Austen

The JAWS V1 Specifications Document

JAWS React Front-End Module: Design Specs & Help Wanted

This thread is for discussing the JAWS-site-react module's design and finding developers who want to help build it

Overall, JAWS should support all front-end frameworks. There has been a lot of demand for JAWS + React support. So, let's start with React!

JAWS already comes with a site module. But you should be able to swap this out with another site module that is focused on a specific front-end framework. So, I'm proposing a new JAWS-site-react module/repo, which will contain JAWS + React boilerplate. Here are some design considerations:

• Keep It Simple: There should be little bloat in this module. This module is for convenience, not strong opinions and obscure React patterns. Make it the best possible starting point for a React project, that is all.
• Make It Extendable While this module is meant for convenience, there should be some mechanism for plugging in other JAWS + React modules. There have been lots of requests to do AWS stuff without API Gateway, since many tasks can be accomplished by using the AWS JS SDK in the browser to interact directly with AWS services. For example, a JAWS-site-react-s3-upload module would be incredibly useful and fast since it would upload from the browser, directly to S3. This module needs to also contain config files for the AWS Browser JS SDK and make them accessible to other JAWS + React modules.
• Integrate With JAWS REST API JAWS will have Swagger integration finished soon. There should be some service that allows you easily interact with your JAWS REST API. Keeping this simple again is key. Perhaps we can get the JAWS-cli to automatically scaffold this for you based on your Swagger JSON.

These are just my opinions. Please contribute your thoughts/ideas/advice. Also, I'm not a great React developer, so I'm looking for some better people to take the lead on this. If you'd like to do that, please say so here :)

Contributing Guide minor issues

I hate to put two issues in one... but here we go:

1. Some text to clarify the relationship between installation guide and this guide would be really helpful. I had both open at once, but a definitive statement on the matter would be great.
2. Under Step 3: Commit, users are advised to make global git config commands. These configs should be local to this repository only, as contributors may also use their workstation for other organizations.

Reduce Scope of IAM User policy during Installation

AWS best practices dictates that IAM Users and Roles should have the most restrictive policies possible for their function. The installation guide recommends creating a user with Administrator access to the AWS account. The scope of the IAM User jaws_user should be revised.

Design proposal: jaws new, jaws routes, jaws deploy

Hi ac360,

Thanks for making this open source and great work! I have a design proposal, would you be open to making JAWS a standalone CLI to keep a user's app separate? The user can then generate a new app using a convenience generator like jaws new app-name (kind of like rails), or they can integrate with their existing app by including it in package.json.

An additional proposal would be to have rails-like convenience methods like jaws routes to list all the lambda routes, jaws new api users/signup to generate a blank lambda function from a template, and jaws deploy to update all the lambda functions as well as compress & upload static assets to s3.

I would be happy to make some PRs but just curious about your thoughts on this.

Thanks!

Installation guide missing initial npm installation

Current behavior:
The installation guide starts with configuration and does not walk the dev through npm installation.

The installation step "open the temp.env file located in the lib folder" assumes the module is installed in the application, but does not list it as a prerequisite step.

Expected behavior:
The installation guide should start with running the command npm install --save jaws-stack in their project.

Notes:
Trivial, but a potential stumbling block.

Error handling

First, awesome work guys!

I've been trying out JAWS and at the beginning was a bit hard to debug what are the errors that AWS API Gateway returns.

Since context.fail expects a message (string) and all examples (sign in, signup...) are returning an object [1], as a response you usually get something like:

{
  "errorMessage": "[object Object]"
}

[1] Example error thrown:

{
      status: 401,
      message: 'Invalid login credentials'
}

Temporarily I changed some of the functions to return a string instead of object (e.g. 401: Invalid login credentials). With that I'm able to use "Integration response" that uses lambda regex and on the end returns proper response.

Also a mapping template like this:

{
    "error" : $input.json('$.errorMessage'),
    "status" : 401
}

This seems like an ugly hack. Is there any other way to do this? Like with using the error model lambda has or anything else? Otherwise, it is obviously a limitation on AWS' side.

Pre-rendered Responses

This project seems very cool, great job 😄

I'm interested in building something with a React front-end, and a backend using something like JAWS. It seems if all I wanted was a fat static client, I could use JAWS as-is. But it's possible, and in my case, required, that we render initial requests first, to both speed up the initial page load and to support clients without JavaScript.

It seems like it would be trivial to set up a lambda function that takes care of an initial render, but who calls that function? API Gateway seems to be JSON only, so that seems like a non-starter. It seems like in this case that having a server might be unavoidable.

Any thoughts would be greatly appreciated 😄 Thanks!

demo site and response time ?

demo site would be great to see it in action / have a starting app ...
I'm also curious what the average response time of these lambda functions is, do you guys have any data / graphs to share ?

Suggestion: Implement JS Standard Style

I wanted to suggest adoption of JavaScript Standard Style. This is purely in the interest of enforcing some consistency in the code from many contributors. Since it's pretty early in the codebase's life, it wouldn't be too hard to do, and it may help a lot down the road.

requires node 0.12.x?

Great start here man.

Curious - why do all your package.json files require node 0.12 when lambda only supports 0.10.33?

FWIW we've been trying to get an official response from AWS on how they are going to support versions because the current way of packaging your own doesn't appeal to us.

Investigate simpler installation process

I think it would be possible to automate some of the steps in the installation process.

I could investigate this.

JAWS REST API: Multi-Region/Cross-Region Replication (Out of the box?)

This thread is for discussing changes in API Gateway, Lambda, etc., and how JAWS supports Multi-Region/Cross-Region Replication.

If the JAWS REST API can come out-of-the-box with cross-region replication of your Lambda functions to reduce network latency, it will be incredible. Imagine, instant cross-region replication of your REST API and you only pay for when it's used via AWS Lambda (!!!).

However, the tools JAWS uses are still new and rapidly evolving (i.e., Lambda, API Gateway), and there is no clear way to do this (yet).

So, we have to figure this out. Here are the puzzle pieces...

• First, we want one REST API URL that can route requests to JAWS resources (Lambdas) with the lowest network latency. I'm not sure how to do this yet. AWS Route 53 has latency-based routing. But, I haven't seen/researched how we can configure this to API Gateway.
• Also, API Gateway now allows you to pass in more context variables to your Lambda functions. This is useful.

Thoughts?

jaws run

If I understand it right, launching jaws run in an api folder performs an unit test according to the date provided in event.jsrather than running the lambda function.

IMO, jaws run should rather set up an http listener with the right endpoint.

With a little express app, there could be possible to both serve the static part out of the site folder (I would rather name it client) and set up all the api endpoints.

Any thoughts?

And last but not least: a great thanks for your work.

Stage naming needs validation and maybe specific transformations

It looks like you can only currently use stage names that are lowercase alphanumeric. Due to the mix of services consuming these names and some toLowerCase calls in different commands.

It looks like currently CloudFormation requires names to be alphanumeric w/ dash (no underscore)
API Gateway stage names are alphanumeric w/ underscore (no dash)

So it looks like we have a few options:

1. Enforce that stage names are alphanumeric and all lowercase. By just adding some validation to jaws new (project and stage) we could gloss over many of these issues.
2. Audit code that handles stage names and ensure we don't have any toLowerCase calls, and then we should be safe to use alphanumeric mixed case.
3. Write an abstraction around stage names that allows dash or underscore internally, and then converts the stage name for AWS services to the other for AWS services that don't support that special character. (It looks like dashes are supported most places, and the API Gateway stage name restriction is a bit odd)

I'd love to open a PR resolving this issue, but I've seen requests to hold off for the time being in other issues.

Let me know if this is something you'd be open to a PR for.

Why site isn't simply static?

I'm wondering why /site are not containing a simple single page app but a node+express app.

If you want to deploy the client part on AWS S3, it needs to be fully static.

Support for Asymmetric (Public Key) JWT Validation

Modify this to support alternative validation schemes: https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback.

config.js Bug AWS_LAMBDA_REGIONS

I try JAWS with my aws account. But return error:

ResourceNotFoundException: Requested resource not found

I find that my aws machine run on 'ap-northeast-1'. The config.js just write aws object with 'us-east-1' like:

aws: {
        admin_access_key: process.env.AWS_ADMIN_ACCESS_KEY,
        admin_secret_access_key: process.env.AWS_ADMIN_SECRET_ACCESS_KEY,
        aws_region: 'us-east-1'
    },

Change it with:

aws_region: process.env.AWS_LAMBDA_REGIONS

that work for me :)

Cron job support with Lambda?

https://alestic.com/2015/05/aws-lambda-recurring-schedule/ - this will be cool.

No license defined

Unless I'm missing it, I don't see a license on this project.

I see you used MIT on your some of your other repositories, is this MIT licensed?

Inconsistency between jaws run result and actual lambda result

According to the lambda programming model the context.succeed method JSON.stringify-ies its result.

I noticed this while trying to build a react ssr lambda described here.

The result of jaws run locally was inconsistent with the results I was getting on aws.

I created a pr that JSON.strigifies the context result locally and fixes this issue.

Binary responses?

Have you figured out a way to output binary responses (like dynamic images, etc.)?

Last time I looked, API Gateway can be configured to pass through anything from upstream, but Lambda will only return JSON-formatted responses (i.e. no binary responses without base64-encoding, which couldn't be decoded on API Gateway at the time).

Unit testing lambda functions

JAWS is going to need unit testing to be considered production ready. I came across https://github.com/SamVerschueren/aws-lambda-mock-context - wondering how others are doing this.

jaws deploy - InvalidSignatureException: Signature expired

I've tried to deploy a lambda function and got this:

****** JAWS: Deploying your Lambda function to AWS Lambda.  This could take a few minutes...
****** JAWS: Zipping up your Lambda Function's files...
****** JAWS: Uploading your Lambda Function to AWS Lambda with these parameters: 
{ Code: { ZipFile: <Buffer 50 4b 03 04 0a 00 00 00 08 00 00 76 06 47 4c 26 27 f8 d9 00 00 00 fa 00 00 00 0a 00 00 00 65 76 65 6e 74 2e 6a 73 6f 6e 25 8e 4d 8f 82 30 14 45 f7 fe ... > },
  FunctionName: 'api_users_show',
  Handler: 'index.handler',
  Role: 'arn:aws:iam::343927519172:role/jaws_lambda_role',
  Runtime: 'nodejs',
  Description: 'None',
  MemorySize: 513,
  Timeout: 5 }
{ [InvalidSignatureException: Signature expired: 20150806T131223Z is now earlier than 20150806T131534Z (20150806T132034Z - 5 min.)]
  message: 'Signature expired: 20150806T131223Z is now earlier than 20150806T131534Z (20150806T132034Z - 5 min.)',
  code: 'InvalidSignatureException',
  time: Thu Aug 06 2015 15:20:34 GMT+0200 (CEST),
  statusCode: 403,
  retryable: true }

Any clue what happened?

Using MySQL (with RDS), Redis(Elasticache), and Elasticsearch

I've adapted this to use MySQL as the backend along with elasticsearch and redis. Is it interesting to this project at all to submit a pull request with how I'm doing it?

Windows needs Shell to be run as an Administrator for symlink to work

I use Windows 7 at work, when trying to deploy my function, jaws deploy returned this error:

****** JAWS: Deploying your Lambda function to AWS Lambda.  This could take a few minutes...
fs.js:848
  return binding.symlink(preprocessSymlinkDestination(destination, type),
                 ^
Error: EPERM, operation not permitted

It turns out Windows needs Admin authentication for symlink to work.
I figured posting this as an issue would help people save some time debugging.

Best.

[Thoughts on]

Deploy from S3

Lambda can be setup to deploy from S3, useful for tying in with a CI pipeline.

Would it be possible to add to a module's jaws.json manifest?

JAWS v0.0.3 causes breaking changes. Here's how to fix them.

In v0.0.3, I had to make some breaking changes and I apologize for this. JAWS literally went from 9 - 2000 github stars in 24 hours. I thought I would have some more time to make some changes before people cared about it. Either way, I still have to make the changes, and they are a bit ugly for people using v0.0.1.

Here is how you can upgrade from v0.0.1 to v0.0.3:

• Download JAWS v0.0.3
• In the cli module, run npm install, then run npm install ./ -g to install the new JAWS CLI globally.
• In the lib module, run npm install. You will have to re-npm-link it to your Lambda functions since the name in the lib module was changed from app-lib to 'jaws-lib'. So, in lib run npm link.
• In each of your Lambda functions run npm link jaws-lib.
• Lastly, there was an issue with the users/signin function creating a new user record in the DynamoDB database on each sign-in. This issue was due to a mistake in setting up the DynamoDB.
• You need to delete the existing Users DynamoDB table and recreate it. When you create the new table, name it jaws_users, and set the Primary Key Type as Hash. Make sure the Hash Attribute Name is set to string and name it _id.

Again, I apologize for this. This is the last big breaking change for a while. Soon, I will bring JAWS out of pre-release and use proper semantic versioning.

Let me know if you haves issues. I'm here to help you :)

Lots of awesome stuff is coming soon to JAWS and soon we will all be building massively scalable web apps that do not require managing servers!

Mitigating AWS Lamdbda limits

I'm sure you have already seen this AWS Lambda Limits.

I see the 1.5Gb total limit, and 50mb deploy limits as huge problems for the current deploy script.

Some things that I believe can help mitigate the impact of these limits are:

• Implementing a build pipeline to minify the packaged source, here is a great example in Gulp
• Using webpack or another compile time bundler to avoid copying external node_modules

Please correct me if I missed something, just trying to look ahead and identify areas that I might be able to contribute.

• Austin

Running `signin` lambda example fails

It because the variables JWT_ISSUER and JWT_SECRET are not set but they weren't mentioned in the installation guide.

First-time install: executing the api/users/show fails with 401

I ran through the installation guide. I tried running the api/users/show locally first and it fails with 401 (I didn't install the JAWS client globally yet, but I don't expect that to be a problem):

$../../../cli/bin/jaws run
****** JAWS: Running Lambda Function Locally...
****** JAWS: Lambda Returned An Error:
{ status: 401, message: 'Invalid or expired access token' }

I went back and checked the steps from the installation guide; I updated the .env file with my own values (I made up JWT_ISSUER and JWT_SECRET, and copied in AWS_ADMIN_KEY, AWS_ADMIN_SECRET_KEY, AWS_LAMBDA_ROLE), and I updated the model_user.js with my table name. The only suspicious step was that when creating the role ("jaws_lambda_role"), the wizard asked me to select a "role type"; the installation guide didn't mention this step, so I guessed that I should use "AWS Lambda".

Anything else I should check, or that I can try to help troubleshoot?

V1: Distinct repos for frontend and backend

Hey guys, JAWS is looking really great can't wait to try out v1. I've been following the doc and am curious if you would consider separating the backend and frontend into their own distinct repos?

I'm not too familiar yet with JAWS or lambda so I don't know if this is feasible but I find separating the client code from the server code into separate repos much easier to maintain with a larger app, especially when the backend is strictly an API.

This might also allow for front-end guys (like myself) to contribute easier by extending the core frontend repo. I may also already have the client built and just want JAWS to serve as my backend API or I just want to quickly deploy a static site with no backend using JAWS' cli tools.

Like I said, I don't really know what implications separating them has but just some food for thought!

JAWS V1.0 Installation Guide

Hi, I can't test or contribute for 1.0 at the moment because I have no idea how to install it.

Can you throw some rough instructions in this issue? If you can I'll test and document them.

And I get that it may well change before 1.0 is baked, but this will allow me to get up to speed and we'll have some install docs evolving along with the code.

[SPEC V1] SNS subscriptions

At the moment SNS subscriptions - event sources - are lost when redeploying lambdas.

So a file that has sns subscription descriptors, and sns.subscribe() as part of jaws deploy would be good.

JAWS: Multiple Environment Support

This thread is for the discussion of how JAWS handles multiple environments

JAWS must have support for multiple environments. Let's discuss the optimal way to do this...

Things to consider:

• For the JAWS REST API: API Gateway uses stages for specifying different environments.
• The stage variable is now available in API Gateway's mapping templates. Though, I'm not sure if they are merely parsing the request path. If this is the case, then those variables may break when using a custom domain name. Ultimately, these can be used to request AWS resources that are scoped by environment.
• Are there different Lambda functions for each environment, or do all environments share the same Lambda functions and merely swap out the resources they use?

How can I help?

This looks awesome and I want it to work yesterday. I don't have a time machine so i will settle for it working tomorrow. How can I help?

I see a few issues marked as "help wanted" and I see a top of great stuff in the roadmap doc. How do i find the highest value thing that needs to get done?

Any ETA on v1.0?

I've downloaded and tested JAWS (master) and it's working great. Now I'm ready to dig deeper and create some modules/lambda functions for image resize, payments, twilio...etc. However, looking at the v1.0 specs on google docs, I'm not sure if I should wait for v1.0 for a more "stable" architecture, or is it safe to write some modules now and they should "probably" work with v1.0?

I know that @ac360 and @doapp-ryanp are committing hardcore right now on v1.0. Should I shift my focus into helping you guys on core instead of the modules?

Thoughts...?

jaws new fails without .aws/credentials

Without .aws/credentials, I get this:

REMI:test remi$ jaws new
       ____   _____  __      __  _________ 
      |    | /  _  \/  \    /  \/   _____/ 
      |    |/  /_\  \   \/\/   /\_____  \  
  /\__|    /    |    \        / /        \ 
  \________\____|__  /\__/\__/ /_________/ 

      *** The Server-less Framework ***     

? Please enter the ACCESS KEY ID for your ADMIN AWS IAM User: AZERTY
? Please enter the SECRET ACCESS KEY for your ADMIN AWS IAM User: +AZERTERTERTERDFVDFGDF
? Type a name for your new project (max 20 chars): test2
? Which stage would you like to create? (you can import more later) test
? Email would you like to use for AWS alarms: [email protected]
Unhandled rejection TypeError: Cannot read property 'trim' of undefined
    at Object.module.exports.setAwsAdminCreds (/Users/remi/Workspaces/JAWS/JAWS/lib/utils/index.js:75:35)
    at Promise.then.adminEnv (/Users/remi/Workspaces/JAWS/JAWS/lib/commands/new.js:160:21)
    at tryCatcher (/Users/remi/Workspaces/JAWS/JAWS/node_modules/bluebird/js/main/util.js:26:23)
    at Promise._resolveFromResolver (/Users/remi/Workspaces/JAWS/JAWS/node_modules/bluebird/js/main/promise.js:476:31)
    at new Promise (/Users/remi/Workspaces/JAWS/JAWS/node_modules/bluebird/js/main/promise.js:69:37)
    at Object.JAWS.new (/Users/remi/Workspaces/JAWS/JAWS/lib/commands/new.js:137:12)
    at /Users/remi/Workspaces/JAWS/JAWS/bin/jaws:18:17
    at tryCatcher (/Users/remi/Workspaces/JAWS/JAWS/node_modules/bluebird/js/main/util.js:26:23)
    at Promise._settlePromiseFromHandler (/Users/remi/Workspaces/JAWS/JAWS/node_modules/bluebird/js/main/promise.js:503:31)
    at Promise._settlePromiseAt (/Users/remi/Workspaces/JAWS/JAWS/node_modules/bluebird/js/main/promise.js:577:18)
    at Promise._settlePromises (/Users/remi/Workspaces/JAWS/JAWS/node_modules/bluebird/js/main/promise.js:693:14)
    at Async._drainQueue (/Users/remi/Workspaces/JAWS/JAWS/node_modules/bluebird/js/main/async.js:123:16)
    at Async._drainQueues (/Users/remi/Workspaces/JAWS/JAWS/node_modules/bluebird/js/main/async.js:133:10)
    at Immediate.Async.drainQueues [as _onImmediate] (/Users/remi/Workspaces/JAWS/JAWS/node_modules/bluebird/js/main/async.js:15:14)
    at processImmediate [as _immediateCallback] (timers.js:358:17)

To API Gateway or to not?

We're in the process of building a Lambda (DynamoDB, S3 etc) based 'API'. Initially, we looked at:
Client (cordova + angular + RESTish client) ->
Server (AWS API Gateway) ->
Lambda (Actual code) ->
DynamoDB etc.

As Cognito Identity seems to be a pretty reasonable choice for auth even if not using Cognito Sync, and given the integration to Lambda (with "identity" in the context hash) perhaps it can actually be used like this (RPC ish):
Client (as before, but with AWS SDK calling lambda.invoke) ->
Server (Lambda function) ->
DynamoDB etc.

The pros:

• No messing around with API Gateway for server side.
• Easier client side updates - no need to generate client SDK for each API Gateway update (although this is still needed for Lambda as mentioned below)
• Immediate support (now) for a calling user's context. API Gateway doesn't currently provide that easily / at all. I last checked ~1 week ago.
• No need to roll own auth (JWT etc) for a lot of stuff, just use Cognito.

The cons:

• Still need some CI deployment mechanism. This could be codepipeline that ultimately pushes to S3 bucket that's used as the Lambda source, then calling the SDK's Lamba update function.
• Versioning? Perhaps it needs to be looked at like the client providing some semver value in the hash and the Lambda function maintaining backwards compatibility either by including all code for different versions, or by directing (proxying) the request to a subsequent Lambda function. Or, maybe naming and direct calls like: GetItems-1_0 ("Function name must contain only letters, numbers, hyphens, or underscores."), skipping the patch version as only major/minor versions should change the return value. Or, maybe the client first looks at a well-known location (S3 json file for example) and obtains the list of correct endpoints it should be using for it's current semver level.
• Security? If the user context isn't checked correctly (by user code), then there's a problem!
• Rate limiting?? This could be an issue. API Gateway provides it, but Lambda doesn't appear to. Maybe AWS will address this as required.

IMHO, I think it's common to implement overkill. The particular app we're working on is complex enough already, so unless API Gateway is really required, we'd prefer to skip it for my our use case.
That being said, I'd love to work with JAWS if it fits properly!

Thoughts?

@ac360

Invoking other Lambda functions

What's the best way to invoke Lambda functions from JAWS? Should I write something to invoke it via REST, or can I use Lambda.invoke?

status: 401 using jaws run

I've followed the instructions in the wiki, and when I run

jaws run

I get:

[~/workspace/JAWS/api/users/show] $ jaws run
****** JAWS: Running Lambda Function Locally...
****** JAWS: Lambda Returned An Error: 
{ status: 401, message: 'Invalid or expired access token' }

GITTER

Not all words/ideas/questions are worth an issue. A Gitter chat room could sometime be the right place to exchange some words.

Confusing name

JAWS is a popular software for blind people, I propose a name change. You could use for example Jama, for Javascript + Amazon stack. You'd need to change the logo to perhaps a Llama (spanish sounding: https://en.wikipedia.org/wiki/Llama).

[JAWS V1] Cross-compiling native modules

http://iswwwup.com/t/5dc20214b79f/node.js-cross-compile-node-module-with-native-bindings-with-node-gyp.html

Contextify (and other native modules compiled with node-gyp) fail when deployed from a Mac. It looks like this:

START RequestId: 6b6c620b-4585-11e5-b7c3-f9f9cd8db2ee
module initialization error: Error at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12) at Module.require (module.js:364:17) at require (module.js:380:17) at bindings (/var/task/node_modules/jsdom/node_modules/contextify/node_modules/bindings/bindings.js:76:44) at Object. (/var/task/node_modules/jsdom/node_modules/contextify/lib/contextify.js:1:96) at Module._compile (module.js:456:26) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12)

temp.env missing

The installation wiki ( https://github.com/servant-app/JAWS/wiki/JAWS-Installation ) references a temp.env file, which does not exist in source.

[JAWS V1] jaws deploy --set-gateway

Maybe I've missed it somewhere so pardon me if that's the case, but it would be nice to automatically add an API Endpoint to the AWS API Gateway. I have multiple ways in mind right know:

• Use a parameter in lambda.json to determine which resource and endpoint to use as well as which http method to accept e.g.:

  {
      "endpoint": "users/signup"
  }

• Use your local directory structure, as it is right know. Problem is I didn't came to a good solution yet how to do that with the new module naming coming in 1.0.0. Would be the more convention over configuration way i think.
• Let's pass the endpoint url as parameter after --set-gateway , but thats more an additional option i suppose as it would be unnecessary to do it every time you deploy a function.

Thoughts ? Generally as well as on --set-gateway ?

Of course there would be more to cover AWS Api Gateway.. for example url embed variables for example:

  {
      "endpoint": "users/show/{userId}"
  }

can static pages be stored as lambdas?

can one cut out prices/complexity even more by storing pages in lambdas that return static html/js/css content?

you'd need a lambda for each page, but it seems access cost might be cheaper than s3 - well, depending on free tier allowances, but if one goes for the cheapest request count to these files can be drastically reduced using cloudflare as frontend

Dependencies added to package.json

Due to no dependencies I can not npm install this repository and run it I am running into Error: Cannot find module 'XXXXX'