CODEWITHSUNDEEP
messageesbmasstransitmessagecontract
SwissCoder
SwissCoder

Reputation: 2590

How are message contracts versioned for service buses?

Let's say we use message contracts based on interfaces, as recommended for MassTransit for example.

First how are those interfaces shared across all the applications? Let's say we provide them in a nuget package. (Is that the way to go?)

So second, how do we now make sure all the applications use the same version?

Should we use new interfaces every time (e.g. messageV1, messageV2) to be backwards compatible? That would require us to send multiple messages at once instead of 1...

Or should we have an upgrade window, where all applications are updated at the same time?

Please check out both the answers and the comments, if you are looking in the same.
Really got some quality feedback here :D

Upvotes: 2

Views: 1529

Answers (2)

nizmow
nizmow

Reputation: 589

MassTransit doesn't explicitly support any kind of versioning, so you're left with the freedom to choose to do what you think is best. The assumptions you've made in your question are more or less exactly the way I do things:

  • Contracts are shared as a nuget package across subsystems
  • New interfaces are created when changes need to be made, interfaces are only ever extended with nullable / backwards compatible changes
  • If necessary, multiple messages are published/sent to preserve backwards compatibility
  • When no longer needed, older versions can be obsoleted/removed

It can seem like a lot of work, but if you design things to work that way from the start it's not so bad, and it really pays off.

Upvotes: 3

Alexey Zimarev
Alexey Zimarev

Reputation: 19640

Message contracts aren't different from any other kind of API contract and you treat them accordingly. Consider any public API as something that went to the world and you cannot control everyone who uses the API.

There're quite a few good guidelines about contract versioning and there's nothing specific to MassTransit there.

MassTransit, on the other hand, provides a few suggestions on how to deal with message versions in the documentation. In particular, we suggest not creating a new version if you follow the Weak Schema approach and add properties that can be empty and aren't important for the consumer. In addition, you can use interface composition, like this example from the docs:

class RemoteImageCachedEvent :
    RemoteImageCached,
    RemoteImageCachedV2
{
    Guid EventId { get; set; }
    DateTime Timestamp { get; set; }
    Guid InitiatingCommandId { get; set; }
    Uri ImageSource { get; set; }
    string LocalCacheKey { get; set; }
    Uri LocalImageAddress { get; set; }
}

so when you publish an instance of RemoteImageCachedEvent, it will be delivered to message exchanges for both interfaces.

If you completely change your API surface, would this be messages, or Grpc, or REST, you need to consider backwards compatibility and keep consuming both old and new messages for a while. Give people some time to change from one version to another and kill the old version if you need to.

Upvotes: 3

Related Questions