HareDu 2

Although it has the same name, HareDu 2 is an almost complete overhaul of the previously released API. There was a great deal of though that went into the latest API. First and foremost, a decision had to be made on whether to continue building on top of HareDu1.x or start over from scratch. Ultimately, it was decided to start from scratch to ensure that the API evolves gracefully. This decision was not taken lightly. There are several factors that went into the decision to rewrite and introduce breaking changes. In particular,

  1. Support for non-Windows environments

  2. Strategic evolution of the API

  3. Increase developer adoption

  4. Rise of cloud computing

  5. New .NET Framework features

Support for non-Windows environments

Although HareDu 1.x is a very compelling API for managing and monitoring RabbitMQ, we felt that it was missing some fundamental functionality that would make it even more of an asset to a developer's toolbox. One of the major missing functionalities is also the most obvious, that is, support for non-Windows environments. This seems a bit ironic considering RabbitMQ itself runs on multiple operating systems. Back when HareDu 1.0 shipped in 2013, there were two camps when it came to .NET development. On one end of the spectrum was its inventor, Microsoft, and at the other end was Ximian's (later Xamarin) Mono.

Although great efforts were made along the way to ensure API parity and binary compatibility with Microsoft's .NET Framework, the fact of the matter is, that, it was a bit challenging for independent application developers to target multiple runtimes/environments. However, fast forward a few years and a lot has changed in the .NET landscape, the most important of which is that Microsot now owns Xamarin and Mono. From the beginning, Mono was designed to run on multiple operating systems so it made sense for Microsoft to formalize this with the recent introduction of .NET Standard and .NET Core. This alone was not enough for developers to turn in their MacBook Pro's and Linux machines for Windows.

While the .NET Framework and Mono had, for the most part, achieved parity, the tooling was light years behind what Visual Studio offered. So, those that wanted to develop in .NET on non-Windows machines had a couple options, either install Windows on a Virtual Machine or purchase a Windows PC/laptop. Conversely, this was not the case for Java developers, as the tooling in all environments running the JVM was pretty much on par. Since then, however, non-Windows .NET tooling has gotten much better, making it easy to develop natively on macOS and Linux. In fact, HareDu 2 was written primarily on macOS using Jetbrains Rider. This perfect storm of tooling and a melding of minds around the future of .NET was one of the primary factors that led to the decision to rethink HareDu and, subsequently, target non-Windows environments.

Strategic evolution of the API

From a design perspective, a major concern was around how easily would it be to evolve the API with as little rework as possible. Looking through different eyes, it became very apparent that the API was too verbose and that it was not easy to take advantage of new language and/or runtime features. That said, there a few immediate decisions made to streamline the developer experience, in particular:

Verbose and useless functionality was deprecate

There is quite a lot of verbosity in the HareDu 1.x API when it comes to its closeness to the RabbitMQ REST API. In HareDu 2, however, a great amount of effort was made toward understanding the data returned from the RabbitMQ REST API. This understanding greatly informed how the new API was designed. A good example of this would be how HareDue resources (e.g. Virtual Host, Queue, etc.) have multiple Get methods. Instead of continuing down this path, HareDu 2 has only a single Get method that returns a result set that can be later filtered via a number of extension methods that hang off the result set. The thinking here is that data filtering decisions should be in the hands of those who know best, that is, developers. It also reduces the need for multiple REST calls to the RabbitMQ server to get information.

Public facing resource methods all return a common immutable object

This allows the API to evolve with as little impedance as possible to developers. The API can now be evolved without breaking public interfaces. The other major aspect of this common return object is the fact that it is immutable, which means it cannot be changed. Unfortunately, HareDu 1.x returned objects are not immutable and therefore can be changed. This is design changed to encourage good design practices that extend beyond HareDu, into the application code that uses the API. Returning immutable objects means that no side affects can happen due to application code. The simple principle here is that, developers do not get to change data coming from the server, purposely or accidentally.

Increase developer adoption

Support for non-Windows environments is on the rise and we felt that now was the perfect time to expand HareDu beyond its roots of running on Windows. The intent is to give developers more options. To that end, we have done the following:

  • Targeted .NET Framework 4.5.2 for maximum adoption
  • Refrained from introducing functionality that would be difficult to later port to other non-.NET languages (e.g. Java)
  • Targeted multiple environments (i.e. Windows, macOS, Linux, etc.)
  • Introduced richer developer documentation

results matching ""

    No results matching ""