feral icon indicating copy to clipboard operation
feral copied to clipboard

sbt plugin

Open armanbilge opened this issue 4 years ago • 1 comments

As described in https://gist.github.com/djspiewak/37a4ea0d7a5237144ec8b56a76ed080d

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.

I have an example of how to deploy an AWS lambda with SAM in https://github.com/christopherdavenport/js-test/tree/serverless.

Easy:

  • Use @ChristopherDavenport's forward-thinking sbt-npm-package to prepare the .js and package.json
  • Interact with SAM cli from sbt

Hard:

  • Interact with the SAM YAML template. This seems to be a combination of:

    1. boilerplate our sbt plugin should provide, like the path to the generated JS, the name of the handler function
    2. 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.
    3. 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).

armanbilge avatar Dec 15 '21 01:12 armanbilge

As of #97 the easy part is done. So now, the hard part 😅

Correction: hmm, actually not. Didn't do the SAM cli stuff yet.

armanbilge avatar Dec 16 '21 06:12 armanbilge