search

herecydev / Rush

Messaging library for .NET
MIT License
2 stars 0 forks source link

Is the `Azure` provider termed too broadly? #10

Open smudge202 opened 8 years ago

smudge202 commented 8 years ago

For one reason or another, there are multiple Service Bus' available on Azure. The full blown Service Bus, and the one that serves as an extension of the storage API.

Event Hubs might too be useful, and any number of future technologies could make good candidates.

As such, is the Azure term being used too broadly in the features/azure branch?

herecydev commented 8 years ago

I think there are 3 candidates, Queues, Topics and Event hubs. My plan was to get the infrastructure in a place such that the majority of concepts (observables, serialization, error handling, logging) can be reused and it's just the client that will be swapped out depending on type of message. So I fully expect to implement more azure technologies, it's definitely going to happen.

smudge202 commented 8 years ago

I think the "Queues" candidate you've specified is actually duplicated in Azure.

See these links:

These two are completely independent services, namespaces, and NuGet packages.

herecydev commented 8 years ago

Yer, I've seen these before. I'm not sure how many people use the storage queue, I always found the lack of deadlettering and push based messaging a nonstarter for the services I build. With that said, I'm keen to see if people want it and should easily be able to support it.

Perhaps changing the Azure into AzureServiceBus will clarify things?

smudge202 commented 8 years ago

The naming change would work for me.

You may find more people than you realise using the Storage variant, because the NuGet packages for it were best at keeping up with dnx. Not checked since netcore.

herecydev commented 8 years ago

Yep it support NETStandard 1.6, the API is reasonably similar. Just need to implement the message pump for the observers and deal with some deadletter logic.