Can I just say that I’ve used CDK before and loved it…. but man its A LOT more fun to use with SST. Simple things are just simple to do where this in not always the case with core CDK.

We're all pretty confused as to how Serverless Inc makes money haha. We have our CI tool https://seed.run/ but I think the vision for it is to expand it to support all kinds of workflows that typically require logging into the AWS console

Similar to Epsagon (for logging)? We use them now.

Observability is definitely an angle we can explore

anyway…. I’m very interested in SST. We were about to start working on something MUCH more modest in features but headed in the same direction. Glad someone beat us to it. 😄

I'm working on it 🙂

Glad to hear it @Dan Van Brunt! We want to keep SST open source and running on your AWS account. I’m personally not a big fan of the Serverless Framework/Serverless Components/Cloud approach of mixing open, closed source with hosted solutions. With Seed, we want to keep a clear separation between the open source and the commercial side. Also, I’m curious if you have some thoughts on the type of plugins you might want to create. It’ll help us do a better job designing the system.

@Jay Sounds great! Just out of curiosity, where are you located, looks like we’re in the same timezone. For a list of possible plugins… I would likely just look at what we have already w SLS…. but also some custom construct ideas that we’d inter-sourced but would be great to add to a better managed OS project. Plugins • serverless-scriptable-plugin • serverless-export-outputs Custom Construct • cross-region replicated bucket. (CFN CR that creates a bucket in n number of other regions) After looking a bit closer to our sls plugins I notice that simply moving to CDK, actually nicely replaces most of them. the need for

serverless-scriptable-plugin

is more out of the desire to turn SST / CDK into a single line deployer that handles all pre and post deploy steps.

Yeah let me get @Frank’s eyes on this. Frank and I are in Toronto. While Dax is in NYC.

Yeah, I have this love-hate feeling toward SLS’s plugin system. A lot of commonly used plugins (ie. sls-offline, sls-webpack) I wish they were baked into the framework, and worked smoother out of the box.

@Frank regarding common Lambda event, context related things…. we use middy , its also what middy-reroute is built on. Only 2.7KBs and lots of really great helpers: • `rds-signer`: Fetches token for connecting to RDS with IAM users. • `s3-object-response`: Gets and write S3 object response. • `secrets-manager`: Fetches parameters from AWS Secrets Manager. • `ssm`: Fetches parameters from AWS Systems Manager Parameter Store. • `sts`: Fetches credentials to assumes IAM roles for connection to other AWS services. and a TON more…

Ah yup. Something I had in mind was:

new sst.Function(this, "MyFunction", {
  handler: "src/handler.main",
  plugins: [
    "sst-sentry-plugin": {
      key: "my-ssm/sentry/prod"
    }
  ],
});

And behind the scene, the plugin does 2 things: 1. adds a Sentry layer; and 2. uses the

secrets-manaer

middy to load the Sentry key from SSM