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

That slide deck is very helpful.

I wasn't counting stars, I was counting contributions. You have some catching up to do.

For what it's worth I tried to weight my post because I think the project looks pretty good and I don't want to discount that achievement. Just Serverless is mature and used but a lot of people in production / live environments you have a lot of work to catch up.

One place where you can potentially not just meet Serverless but win is getting started documentation.

And I don't mean just hello world.

For example: how do I create and use a DynamoDB database in your Framework? Serverless certainly supports that but it is a learning curve and trips up new users.

Another concern I have is the edge cases. Stuff Serverless isn't even good at. For example:

- CloudFormation has a 200 resource limit. How do you deal with that. Severless hasn't solved it yet.

- How do Lambda functions get versioned? Serverless does this very well.

- How do I hook up a lambda to a SNS stream. Serverless does this really well too but the documentation is poor.

One think Serverless does very well is letting you set up various Lambda triggers without having to know much of the internals.

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,

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.

- 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#...