Hacker News new | ask | show | jobs
by oaiey 1831 days ago
The team quite systematically ignores messaging (as in RabbitMQ and friends). HTTP is covered in all aspects but messaging really lacks behind.
3 comments

What's lacking? I'm sorry, I last fooled around with message queues like over ten years ago (and it was MSMQ and IBM MQ), but was recently working on a hobby Rpi project where I came close to dinking around with RabbitMQ via Python. It looks like RabbitMQ has a library for .Net. Or are you talking about how the native library System.Messaging is not generic enough to go outside the bounds of MSMQ still? Truly not challenging anything you're saying, just curious to know what you'd prefer to see.
HTTP has a huge infrastructure for translating http request into endpoints. With all the bells and whistles. Nothing is there for messaging. You can get a library for everything but there is no focused stack for processing messages.
SignalR can be used for some applications, but “messaging” is a pretty broad category of different solutions, and I’m not sure what you’d want baked into ASP.NET to accommodate that. HTTP is standardized enough that basically everybody is doing it in very similar ways, but many pieces of a web application are better left for libraries to support.

Is there another mainstream platform with better messaging support without needing libraries that you can name as an example?

Agree with what you said. It is a complicated problem.

I do not look into other platforms. I look into my solutions: http i can write my business logic and that is mostly it. On messaging i have to think about threading, acknowledging, dead / poison letters, decoding, trace contexts, etc. And these is all non trivial code especially when done right.

I mean, HTTP is a protocol with huge footprint/mindshare/utility to put it mildly. Messaging has.. who can name it? AMQP. I think it would be brilliant if System.Messaging was reoriented to AMQP, especially since MSMQ is not coming back. It's a bit lame that the namespace is locked into to a proprietary and EOL product, for sure.
I’m not sure I follow; why would/should Microsoft make libraries for projects they don’t own?
Because there are two kinds of microservices... HTTP ones and messaging ones. There is a gap.
Could you explain the difference between the two, for nonweb devs?
It is mainly about non functional needs. A message queue you would use when you have no need in synchronous results, peeks in traffic or want a higher reliability.

If you are ab embedded dev, imagine you want to hand of sensor value to a central service without required immediate response.

If you are a game dev, imagine a play turn result hand off to a central leadership board.

Queues and related Message processing are a tool everywhere not just web development.

MassTransit, NServiceBus, ReBus - you have plenty of options.