Add AWS SNS Plugin

[ctasada]

Although AsyncAPI allows to add more details for the binding, the underlying library jAsyncApi has no support for further binding information. Therefore, only the sns binding without properties is supported.

Manual configuration is supported through the usual @AsyncPublisher annotation in combination with the @SnsAsyncOperationBinding annotation.

The code is mostly copied and adjusted based on the other plugins.

[netlify]

✅ Deploy Preview for springwolf-ui canceled.

Name	Link
🔨 Latest commit	b1b81f1
🔍 Latest deploy log	https://app.netlify.com/sites/springwolf-ui/deploys/6529409541205c0008849fa4

[timonback]

This is great!

If possible, we like to merge #386 first, which will have an impact on this PR as well.

Can you add SNS also to:

• the README.md file
• the RELEASING.md file
• the springwolf-ui mock-server.ts (we can then map the sqs.demo.springwolf.dev domain)
• update the pipeline (springwolf-plugin.yml -> matrix) after Chore/gh matrix builds #383 has been merged.

[ctasada]

@timonback I just saw #370 which is a great addition.

Since this plugin is only adding a new @SnsAsyncOperationBinding and not a full integration. Does it even make sense to merge it?

SNS is intended for publishing only, and AFAICT there's no AWS annotation for binding it. So this plugin can be easily be replaced by the new GenericBinding you are working on.

[timonback]

Good question. I wasn't aware that there is no snslistener, but instead theses would be sqs queues.

I like the native support of a protocol specific annotations, namely SnsAsyncOperationBinding - even if jAsyncApi does not support further binding info.

When implementing sqs, I wondered if sns should be part of the same plugin as well or whether the plugin should be called aws...
I could imagine the binding annotation to be part of sqs, as there is neither a listener nor additional dependency needed.

An own plugin just for the annotation might be too much.
What are your thoughts?

[ctasada]

SNS can be processed via SQS, HTTP,... so including it in the SQS plugin may make sense, but so adding it to a generic/core library with other bindings like Google PubSub, for example

[timonback]

The change has been merged and will be part of the next release as a new plugin :)

If you want to try and verify it in your application, use the current SNAPSHOT build as described in our README.md

Thank you for the report/contribution!

[timonback]

For context: We decided that we like to extend our support of native supports, therefore adding the custom annotation in favour of having the user figure out which properties to set on the generic binding.
Also, we think the amount of effort to maintain a new plugin is doable and better than to place it somewhere, where it does not really belong to (core, sqs, ...).
Additionally, this leaves options open in case there will be better sqs support in the jAsyncApi library.