ADR-32: Adds a way to make queuegroup-less endpoints

adr/ADR-32.md

@@ -1,20 +1,21 @@
 # Service API
 
-| Metadata | Value             |
-| -------- | ----------------- |
-| Date     | 2022-11-23        |
-| Author   | @aricart          |
-| Status   | Implemented       |
-| Tags     | client, spec      |
+| Metadata | Value        |
+|----------|--------------|
+| Date     | 2022-11-23   |
+| Author   | @aricart     |
+| Status   | Implemented  |
+| Tags     | client, spec |
 
 ## Release History
 
-| Revision | Date       | Description              |
-| -------- | ---------- | ------------------------ |
-| 1        | 2022-11-23 | Initial release          |
-| 2        | 2023-09-12 | Configurable queue group |
-| 3        | 2023-10-07 | Add version regex info   |
-| 4        | 2023-11-10 | Explicit naming          |
+| Revision | Date       | Description                               |
+|----------|------------|-------------------------------------------|
+| 1        | 2022-11-23 | Initial release                           |
+| 2        | 2023-09-12 | Configurable queue group                  |
+| 3        | 2023-10-07 | Add version regex info                    |
+| 4        | 2023-11-10 | Explicit naming                           |
+| 5        | 2024-08-08 | Optional queue groups, immutable metadata |
 
 ## Context and Problem Statement
 
@@ -38,7 +39,7 @@ Service configuration relies on the following:
 - `description` - a human-readable description about the service (optional)
 - `metadata` - (optional) an object of strings holding free form metadata about
   the deployed instance implemented consistently with
-  [Metadata for Stream and Consumer ADR-33](ADR-33.md).
+  [Metadata for Stream and Consumer ADR-33](ADR-33.md). Must be immutable once set.
 - `statsHandler` - an optional function that returns unknown data that can be
   serialized as JSON. The handler will be provided the endpoint for which it is
   building a `EndpointStats`
@@ -291,15 +292,18 @@ Each service endpoint consists of the following fields:
   Multiple endpoints can have the same names.
 - `handler` - request handler - see [Request Handling](#Request-Handling)
 - `metadata` - an optional `Record<string,string>` providing additional
-  information about the endpoint
+  information about the endpoint. Must be immutable once set.
 - `subject` - an optional NATS subject on which the endpoint will be registered.
   A subject is created by concatenating the subject provided by the user with
   group prefix (if applicable). If subject is not provided, use `name` instead.
 - `queueGroup` - optional override for a service and group `queueGroup`.
 
-Enpoints can be created either on the service directly (`Service.addEndpoint()`)
+Endpoints can be created either on the service directly (`Service.addEndpoint()`)
 or on a group (`Group.addEndpoint`).
 
+Clients should provide an idiomatic way to set no `queueGroup` when unset the subscription
+for the endpoint will be a normal subscribe instead of a queue subscribe.
+
 ## Error Handling
 
 Services may communicate request errors back to the client as they see fit, but
@@ -337,7 +341,8 @@ in order to scale up or down all the user needs to do is add or stop services.
 Its possible to send request to multiple services, for example to minimize response time by using
 the quickest responder. To achieve that, it requires running some service instances with different `queueGroup`.
 
-For each configured endpoint, a queue subscription should be created.
+For each configured endpoint, a queue subscription should be created. Unless the option to create
+a normal enqueued subscription is activated.
 
 > Note: Handler subject does not contain the `$SRV` prefix. This prefix is
 > reserved for internal handlers.