BAbanashark·Mar 4, 2024
Dotnet and java usually have similar libraries for most things, but sometimes it comes down to how different they are or what they support.
Let's look at general distributed messaging abstractions.
The most modern-featureful one for dotnet I know of is MassTransit: https://masstransit.io/documentation/concepts. You can see it supports a handful of queues and some interesting patterns.
Compare this to the list of features in Apache Camel: https://camel.apache.org/components/4.4.x/eips/enterprise-in...
Additionally, the _support_ of the libraries for common open-source (and closed-source infra) is usually vastly different:
- https://pulsar.apache.org/client-feature-matrix/
- Small features being first party like https://github.com/awslabs/amazon-sqs-java-extended-client-l... vs https://github.com/raol/amazon-sqs-net-extended-client-lib
- Mi
Read the rest
ssing features or those that lag behind: https://github.com/confluentinc/confluent-kafka-dotnet/issue...
- Usually manually wired and configured vs the spring boot "starter" pattern of having libraries that automatically do some of the manual setup work for you: https://github.com/spring-projects/spring-boot/blob/main/spr...
I wish more client library sets had the feature-matrix that the pulsar one does, because in practice most end up being the same: Java supports everything because it's either built in the same codebase or is the most used client and gets the most support, while the dotnet client codebase has many feature-requests or performance improvement issues, often leading to a "third-party client" being created.