Skip to content

Releases: JamesRandall/AzureFromTheTrenches.Commanding

Custom HTTP Dispatch Error Handling

31 May 17:16
Compare
Choose a tag to compare

The HTTP dispatcher can now be associated with a error handling delegate on a per command basis so that HttpStatusCode errors can be translated into meaningful exceptions.

NuGet Package Bumps

07 Mar 16:15
Compare
Choose a tag to compare
  • NuGet package updates and Core 2.2 targetting
  • Added remove capabilites to command registry

REST API, Service Bus, Cleaner Extension API

18 Apr 07:23
Compare
Choose a tag to compare

Although this is a major version bump for most users it is likely to be zero impact. I have obsoleted some methods but they won't be removed until the next major version. Updates include:

  • ASP.Net Core REST API Commanding - configuration based zero code controllers for accepting commands as REST calls
  • Service Bus Extensions - dispatch commands to and process from the Azure Service Bus queues, topics and subscriptions
  • Event Hub Extensions - added dispatch support
  • Registration supported through Type objects as well as generics (thanks to @cjrpriest )
  • Syntax for adding to the IServiceCollection is no in line with Microsoft guidelines Add rather than Use (in my defence I had adopted this convention ahead of Microsoft setting theirs!)
  • Cleaner syntax for common use case of extensions (dispatch to queue for example) through extension methods and static factories negating the need for interface resolution.
  • Command / handler discovery (see Discover on ICommandRegistry)
  • New documentation site at https://commanding.azurefromthetrenches.com

It's worth also noting that the REST API and Service Bus extensions are at v1.0.0. The framework set is large enough that it no longer makes sense to version things as a group and I'll be splitting these things out into their own repos shortly.

Queue improvements and bug fix

03 Mar 10:44
Compare
Choose a tag to compare
  • Queue extensions now support logging via the supply of Action<>'s dependency registration
  • Commands with no result now log with the correct command type.

Thanks to cjrpriest for the contribution of the logging fix - great to receive my first community contribution for this framework!

Minor improvements and fixes

26 Feb 07:42
Compare
Choose a tag to compare
  • When registering the cache sub-system you can now opt to have the caching command dispatcher replace the standard dispatcher
  • When registering the HTTP dispatch sub-system you can supply a HttpClient instance of your own or instead the commanding runtime will create a single shared instance for its own use
  • FIX: removed HttpClient creation issue

Dispatch fixes

21 Feb 14:04
Compare
Choose a tag to compare
  • Fixes for dispatching commands which have no result via custom dispatchers
  • Acceptance tests to cover this

This release contains a potentially breaking API change for registration - it's one of the lesser used variants but hence the major version bump.

HTTP bug fix

21 Feb 08:26
Compare
Choose a tag to compare
  • Fixed an issue with GET requests over the HTTP dispatcher where query parameters were being missed (and added unit tests around this)

Minor improvements

19 Feb 18:22
Compare
Choose a tag to compare
  • The commanding framework can now be be configured on a per thread basis (which has the by-product of supporting parallel running of full end to end acceptance tests in a single process space)
  • 15% performance improvement
  • A missing command handler now generates a MissingCommandHandlerRegistrationException exception. Thanks to @cjrpriest for reporting this

I've also begun to introduce full end to end acceptance tests.

Bug fix

14 Feb 13:42
Compare
Choose a tag to compare

Fixed an issue that caused the dispatch of commands with no expected to response to fail.

Performance Improvements

03 Feb 13:31
Compare
Choose a tag to compare

Performance of the framework has been improved 10x in this release (see blog for details).

Additional minor improvements are available through the addition of two new configuration options:

  • Metric collection is now disabled by default but can be enabled by setting the MetricCollectionEnabled property to true.
  • When the framework is only used with in memory scenarios UseLocallyUniqueCorrelationIds can be set to true to generate cheaper correlation IDs (incrementing long's as opposed to GUIDs).