Proposal to provide config based deactivation of QueueGroups for Service

[davedotdev]

Proposal to provide config based deactivation of QueueGroups for Service

Not every service is required to be in a QueueGroup. Some services require direct address and the code changes presented here are for discussion.

Is this an acceptable way to turn off QueueGroups? It works in my testing, but was wondering if there are better suggestions?

Naturally, these changes have dependencies. The Schema entry for the services info_response will need changing, to allow for the tokensied naming with a period.

This definition https://nats.io/schemas/micro/v1/info_response.json specifically requires basic_name to allow the period and it is proposed to create a micro_name definition that includes the period.

Just to be clear, I appreciate that this might not be the solution, but as we do more with Service, this has come up and needs to be addressed. I'm happy to make the various PRs to extend this, but wanted to seek opinion and counsel before blindly going after a PR!

If you're curious, you can export the env var NOVALIDATE="nope" for the nats CLI client and stand up some period tokenised services and get info using this PR.

	group := srv.AddGroup("test") // the subject token pattern here is "test.get.1234"
	err = group.AddEndpoint("get.1234", micro.HandlerFunc(getHandler), micro.WithDisableQueueGroup(true))

Cheers,
Dave

[ripienaar]

Can you elaborate a bit more on the use case here? We'll either end up with multiple instances all getting the request or each instance being entirely unique - in which case having a queue group is a noop really.

[davedotdev]

Sure. It's not a switch of design, but a configurable option to add more design options. This is for service use cases that don't require NATS to load balance them, pushing the act of steering request distribution elsewhere for service like sentinel nodes, workflow style routers and other systems. Users get the benefit of the service abstraction and CLI tooling, but with extra controls for different service styles.

If the queue group stays turned on (default), then it's as before. If however QGs are turned off for an endpoint, then the service can be unique. That means something else can distribute requests to it. Also, subject names can be more complex, enabling different patterns. A service in theory could require QG, vanilla pub/sub or direct request/reply.

Use cases include: Fleet management; IoT etc could need both QG and non-QG approaches; signalling to end-points to download an over the air update; taking control of a building management system that's online as service; rolling IoT/fleet coordinated reboots etc. In the network world, being able to manage a fleet of network operating systems, with direct communication capabilities is key. It's a convenience extension. In highly connected systems, NATS can be the central pillar of observability, communication, data and control, without requiring on other service abstractions.

That help? In short, multiple use cases, but summarised within extra design options, fleet and IoT.

Assuming the above satisfies your query, is there anything in the codified approach which could be done better? I figure it's a minimal surface area, non-breaking proposal and I tried to keep this initial stab within the patterns and structure of the code.

[ripienaar]

Idea seems fine, think we need a more concise problem statement.

changes to micro affects all languages and so we start with a ADR update and go from there into all languages

[davedotdev]

I'll look at the ADR. Cheers.