Closed dbatyuk closed 3 years ago
It's a good suggestion, but I don't think we can change our current format, because existing consumers would break (unless we do some versioning which is even more complicated). I think the way to go is to make it configurable. Unfortunately it's not our focus atm, but feel free to sumbit a PR.
Stumbled over the same issue. We use some components written in Java that use the SQS Extended library (by awslabs) or python that use compatible libraries, but we didn't find anything compatible for node.
I implemented an opt-in compatibility mode here: https://github.com/FrederikP/sns-sqs-big-payload/tree/introduce-awslabs-compatibility-optin
It's hard to write an integration test because that would mean creation java resources etc. in this project. For now I'll just test in our dev environment. I'll let you know how it goes.
Feel free to suggest changes and I will gladly open up a PR if it helps. Thanks for this library ;)
Okay we tested the compatibility mode in our environment. (sending in non nodejs component, receiving in nodejs component) and it works. Is someone interested in using this? I can open up a PR.
Hi @FrederikP, sounds great, please open a PR.
Ok. See https://github.com/aspecto-io/sns-sqs-big-payload/pull/26 Feel free to change stuff as you see fit.
Released in v0.1.0
Is it possible to use same schema as https://docs.aws.amazon.com/sns/latest/dg/large-message-payloads.html https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-s3-messages.html java libraries for SNS and SQS to be able to produce/consume using nodeJs and consume/produce using Java.
they use next Json
[ "software.amazon.payloadoffloading.PayloadS3Pointer", { "s3BucketName": "extended-client-bucket", "s3Key": "xxxx-xxxxx-xxxxx-xxxxxx" } ]
or at least maybe make it configurable
Thanks