General 'worker template'?

[stijnmoreels]

Currently, we have separate Azure Service Bus topic/queue worker project templates, with similar functionality. Almost the only thing different is the queue/topic in those templates.
Once we start adding a worker project template for Azure EventHubs, the content of the project template would also be very similar.

Is it an idea to combine these messaging worker implementations in a single project template and let the user decide from which messaging system the messages should come from?

> dotnet new --install Arcus.Templates.Messaging.Worker
> dotnet new arcus-messaging-worker --name MyProject --messaging ServiceBusQueue

Or is this too complex? It's also how new Azure Functions projects are created, for example.
Thoughts? @pim-simons @fgheysels @gverstraete @meersschautarnaud @MassimoC

[pim-simons]

If the templates would be very similar I think it makes sense to combine them into 1 template.

> dotnet new --install Arcus.Templates.Messaging.Worker
> dotnet new arcus-messaging-worker --name MyProject --messaging ServiceBusQueue

Or is this too complex?

I don't think so, seems like very easy commands to me. As long as we update the docs accordingly this shouldn't be an issue.

[gverstraete]

What do you do with dependencies? Based on the "messaging" type, you can have different dependencies? Can you configure that?
I think if you want to have many different bindings, it is best to have different worker templates. Just for the sake of simplicity in your code & straight forwardness for the user.

[stijnmoreels]

Currently, we only have a single --exclude-serilog project option which is also available for both worker templates, and will be available for EventHubs, too. Otherwise, the ServiceBus / EventHubs dependency will be different indeed, but only the bare minimum packages are provided.
You imagine that we could have problems if these templates grow and we need very different project options for different messaging systems?

I think those options, too, would be able to be configured based on the messaging type conditions, as these are also available for Azure Functions.

[gverstraete]

I'm not an expert in this, but I see a lot of If's coming when we extend this..