Should we deprecate Subject?

[slang25]

Currently when receiving a message from SNS -> SQS it's an SNS message, with a Message property with the serialized message json within it.

SNS has an optional Subject parameter (which primarily comes from SNS support for email endpoints) which appears as a top level property in the SNS message body (outside of the "regular message body").

JustSaying sets this property today, and sets it from the message type that is being published. We apply a deterministic function to get the subject name, and then we use that as a key to the serializer for that subscription, in something we call the "message serializer registry".

This seems a bit pointless, in that we have enough context within JustSaying to know from the queue url being subscribed to, which serializer to use. The subject doesn't "tell us" anything really, it's more of an implementation detail, and is simply required to match on both sides (publisher & subscriber) in order to pick the right serializer from the many that might be available as a result of subscribing to different events.

To say it another way, the subject may look like it's the message type name and has meaning, but really it's just a hash of the message type (but human readable).

One problem that follows from requiring a subject property is that vanilla message bodies cannot be supported transparently, there are at least two scenarios this pops up:

• "Point-to-Point" subscriptions; i.e. send a message straight to a queue
• Raw message delivery subscriptions; SNS -> SQS subscriptions, but with raw delivery mode switched on.

Today the above two approaches require wrapping the message in a JSON object, double escaping the underlying message and added a subject property. We could remove this requirement if we made subject optional.

A negative to removing subject is you couldn't easily support different message types in 1 queue. Also if you started to remove subject from publishers, this would be a breaking change to previous subscribers.

[gkinsman]

Interesting idea!

A couple of thoughts spring to mind:

1. Currently at JE we tend to prefer datatype channels where every message in a topic/queue is the same type, but as you mentioned it's possible to go the other way and have endpoints that support multiple message types. Some messaging libraries choose to offer flexibility here whereas this would be an explicit choice to encode the datatype pattern as an opinion.

2. I like the idea of being able to send/receive raw messages without any of the SNS baggage, but is the real problem here that we have a base message instead of a message envelope? If we were to switch to e.g. a cloud events envelope with our existing data as a property of it, then perhaps a Subject could live on that and we could deprecate the SQS-specific Subject? The lack of a proper way to handle headers (currently we use SQS/SNS attributes) hurts us in other ways too I think, e.g. our metadata has to be in the limited transport-specific headers instead of our own envelope.

3. If we were to deprecate subject in favour of extracting this information from a queue name, we'd need to provide an extension mechanism for users to parse the type identifier from it. Given the limitation on queue names of 80 characters, this could mean more work for devs if they need to provide code to convert their queue names to type id's. Maybe its not a big deal, but worth considering.

[slang25]

Great points.

On point 3, we would not extract anything from the queue name, but we'd instead key the serializer on the queue url, rather than subject. We could have subject be a key override, or something.

I think when people are using the fluent API, their intent is to add an implicit serializer for this subscription, rather than "add a subscription for this message type, and also add a serializer for this message type, but it may or may not be used for this subscription, but it almost certainly will", which is what happens today.