Handle incoming SNS from a multi instance ECS hosted application

[kaihendry]

This issue carries on from #13

This might be tricky since we run TWO instances of meteor.

https://s.natalian.org/2018-05-21/sns-web-hook.mp4 demonstrates how it might work, using SNS from the dev account & https://github.com/unee-t/showhook

[kaihendry]

I'm starting to think SQS is a better option than a Webhook https://s.natalian.org/2018-05-18/sqs.mp4

Also see https://console.aws.amazon.com/support/v1#/case/?displayId=5045385721&language=en if you can (on account 812644853088).

[kaihendry]

I'm confident that SQS is the way to go after asking around and creating a prototype.

I am creating a debug tool in Golang since I am not very good with Javascript over here: https://github.com/unee-t/showhook (probably will be renamed, since it's not working via a hook)

In Javascript you would use either:

• https://www.npmjs.com/package/squiss https://twitter.com/nathankpeck/status/999665627353755648
• https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/sqs-examples-enable-long-polling.html

To get the messages from the SNS Topic and then route them to the user by ID (assuming there is some mapping) and caseid. Once processed, i.e. the user is notified in the application, the message is deleted from the SQS queue.

[kaihendry]

After speaking with @nbiton, we decided on a different direction to shownotication of writing directly into MongoDB via a lambda, and then Meteor's (MongoDB) observers will notice the changes and present that to the user via a Facebook Bell like notification UI element.

So I need to create a:

• ut_notification_messages_cases >- mongodb
• ut_notification_messages_units >- mongodb

One way mapping service.

[franck-boullier]

ut_notification_messages_units >- mongodb is not needed anymore: the source of truth is Mongo DB for this
See the description of the Notification project for more details.