Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add possibility to access SQS raw message #27

Open
Kralizek opened this issue Feb 3, 2023 · 3 comments
Open

Add possibility to access SQS raw message #27

Kralizek opened this issue Feb 3, 2023 · 3 comments

Comments

@Kralizek
Copy link
Owner

Kralizek commented Feb 3, 2023

Let's discuss here how to give access to the raw SQS message.

This issue was spawned by #25

@bartpio
Copy link

bartpio commented Feb 3, 2023

I drafted a possible approach. This was inspired by IHttpContextAccessor. The injection idea makes it possible to access the raw SQS message, but doesn't really encourage it. Also, it avoids breaking changes to the message handler interface.

I included an SqsRecord wrapper around Amazon.Lambda.SQSEvents.SQSEvent.SQSMessage to:

  1. Hide facts of limited use, namely, the raw non-deserialized body.
  2. Hide facts that I'm not sure actually work when SQS is paired with Lambda, namely, custom SQS message attributes. AWS's event source implementation would have to ask the SQS ReceiveMessage API to include such attributes. Further testing could determine if these work or not.
  3. Make AWS-defined message attributes more convenient to access (typed properties vs. Dictionary<string, string>).
  4. Protect our library from consumers mutating the SQSMessage.

All that being said, perhaps wrapping the SQSMessage is overkill.

@Kralizek
Copy link
Owner Author

Kralizek commented Feb 8, 2023

I see the problem but I think the solution feels a bit over engineered.

Give me some time to look for alternatives.

@bartpio
Copy link

bartpio commented Feb 8, 2023

I agree. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants