Then, once this is done, within the resulting project they should be able to run sbt deploy and immediately get a running, functioning HTTP lambda. Assume we have an AWS_API_KEY in an environment variable (or similar), presumably referenced in some way from the build.sbt.
Interact with the SAM YAML template. This seems to be a combination of:
boilerplate our sbt plugin should provide, like the path to the generated JS, the name of the handler function
config our sbt plugin could try and figure out, but hard to retrieve in practice: e.g. the type of event. These kinds of settings seem perfect for a g8 for various kinds of lambdas.
any other custom user config
Not sure what the best approach is. One option is to go full sbt-gh-actions and manage the template entirely from within sbt. Otherwise, will need some kind of hybrid approach.
Ideally we should have a plugin for both JVM lambdas and JS lambdas (or a hybrid plugin that can handle both) but let's focus on JS use-case for now since that's newer/more foreign to Scala folks. The nice thing is the SJS plugin can also adjust the Scala.js settings that tend to trip users up (namely, module configs).
As described in https://gist.github.com/djspiewak/37a4ea0d7a5237144ec8b56a76ed080d
I have an example of how to deploy an AWS lambda with SAM in https://github.com/christopherdavenport/js-test/tree/serverless.
Easy:
.js
andpackage.json
Hard:
Interact with the SAM YAML template. This seems to be a combination of:
Not sure what the best approach is. One option is to go full sbt-gh-actions and manage the template entirely from within sbt. Otherwise, will need some kind of hybrid approach.
Ideally we should have a plugin for both JVM lambdas and JS lambdas (or a hybrid plugin that can handle both) but let's focus on JS use-case for now since that's newer/more foreign to Scala folks. The nice thing is the SJS plugin can also adjust the Scala.js settings that tend to trip users up (namely, module configs).