feat(resolvers): JavaScript resolvers

[bboure]

• Adds support for JS resolvers
• JS resolvers are now default
• PIPELINE resolvers are now defaults
• Removes support for default mapping templates and locations
• Removes support for named data sources in resolver definition

[github-actions]

🎉 This PR is included in version 2.0.0-alpha.13 🎉

The release is available on:

• npm package (@alpha dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[ebisbe]

Is there any difference on how to use substitutions? I don't see anything explicit and I want to try it. My guess would be that they can be used from the env but ....

[ebisbe]

Reading the code I see there is no option for that. How could we add vars like substitutions?

[bboure]

This is not supported (yet).
This is more tricky I think than with VTL
Ideally, we'd want ApPSync to support env vars

An alternative would be to use global variables.
Something like

const MY_VAR = "foo";

we could generate those and prepend them to all js files.

in the resolver you could do (fake example)

function request() {
  return {
    "operation": "foo",
    "myVar": MY_VAR,
  }
}

ideas?

[ebisbe]

Yes, it's more tricky. I was reviewing the code and saw how it was implemented with VTL. In a way is much more straight forward as it's al string based.

By the way, your suggestion is to use the actual definition:

substitutions:
  ENV: ${self:provider.stage}
  FlickrKey: ${env:FLICKR_KEY, 'FLICKR_KEY env missing'}

and inject them as:

const ENV = "foo";
const FlickrKey = "bar":

I think that it should be something that it is easy to test at the same time.

[ebisbe]

Not sure what other things we should consider but something like this?

var fs = require('fs')
var data = fs.readFileSync('User.buddyicon.js', 'utf-8');

const replace = data.replace(/#FlickrKey#/g, '123-abc')

fs.writeFile('User.buddyicon_v2.js', replace, 'utf-8', function (err) {
  if (err) throw err;
})

We define:

const FLICKR_KEY = '#FlickrKey#'

and it's replaced for:

const FLICKR_KEY = '123-abc'

We can't use the same ${} as it's a valid JS syntax so maybe we could use a new one for both VTL and JS. Leaving a deprecation for the existing syntax on the VTL.
Also the proposed solution seems testable as we have pre-filled values to do expectations.

[markgibaud-vtail]

Was there an explanation for removing support for default mapping templates and locations? Can defaults be implemented in a different way or is it a case of not doing AppSync AWS's way?

[bboure]

@markgibaud-vtail

Yes, it's explained here

More context: with JS resolvers, it can cause confusion and unexpected results.
Like: What is the default? VTL resolvers? or JS?
I also did not want to introduce a runtime option because it is already implicit from code (JS) or request/response (VTL). Requiring both would be repetitive.

I thought it would be better if the developer has to be explicit about it.

Another reason is that, when you look at the Serverless Framework, the is no default for the Lambda functions' handler, right? You MUST provide the location of your handler. This plugin should not be different.

In V2, I am trying to be more in line with SF's core behaviors.

[github-actions]

🎉 This PR is included in version 2.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀