simonel

We're not comparing dawson's maturity to Serverless, nor we are financially backed as they are, so comparing those numbers is pointless.

Anyway, if someone's interested in diving in deeper, instead of just counting our stars, this deck might be a good resource: http://slides.com/lanzone31/dawson20170303

A few corrections to your comment:

>is extremely powerful (because for AWS it is built on AWS CloudFormation)

dawson is also built entirely upon CloudFormation

>Not to mention in supports other languages

we'll merge python in master in a few weeks

Just a clarification:

NONE of your App's code will run using such "AdministratorAccess" policies. Each function will run in its own iam:Role with limited permissions defined by the developer.

The AdministratorAccess is currently required only for the CLI but, as said in my previous comment, we'll eventually move to using a Service Role and providing a more restrictive policy.

Sure, I agree with you and with most of the replies here.

dawson will soon switch to using an AWS CloudFormation Service Role, which allows us to require users to grant fine-grained permissions. We will then provide a copy-pasteable Policy for users to set, and update the documentation accordingly.

Currently, since CloudFormations runs with the CLI user's AWS Credentials, such user needs to be granted the permission to do every action, including, for example, managing DynamoDB Tables, S3 Buckets etc...

Also, imagine you're adding an S3 Bucket as a custom resource to your app. dawson will create such S3 Bucket using CloudFormation; CloudFormation needs to be run by a user with S3::CreateBucket permission. This applies for each resource managed by dawson/CloudFormation.

Again, thanks for your valuable inputs and feedbacks!

~ The maintainers,

- it should make easier to replicate Lambdas to different AWS Regions or to use different stages (development, testing, production, ...)

- allows running of lambda functions locally, which significantly speeds up development

- provides you with a full production-ready environment (CloudFront + S3 + API Gateway + Lambda + ...) out of the box

Thanks. The main goal here is to cover a couple of use cases without needing a single configuration line (aside from the app name, which is always required).

We'll ship full first-class support for the python runtime (including the dev server) in dawson in a few weeks.

It depends on which solution are you comparing to. Usually, based on my experience, the total cost will be significantly lower than a similar solution deployed to EC2+RDS.

> Any nasty hidden surprises in AWS billing that you've experienced by doing so?

- just a few cents of S3 Storage (if you're out of the free tier) to host versioned Lambda deployment packages - which will expire automatically anyway.

- in production, by default, dawson creates an AWS WAF (Web Application Firewall) WebACL which cost ~5$/mo. You can opt out this behavior if you don't need one.

Apparently, there's no way to use API Gateway with Cognito, it looks (and should be possible) there are so many lacks in the documentation... I'm following this forum thread [0] regarding Cognito integration in JS. [0] https://forums.aws.amazon.com/message.jspa?messageID=645618#...