[ADDED] Support for multi-endpoint services

[piotrpio]

No description provided.

[ripienaar]

Whats the benefit of having this be configurable rather than RootSubject.EndpointName? We should specify valid end point names matching kv bucket rules so they are always safe to use by concatenation.

We could make this a optional but I think it would need to have significant benefit in being setable (and can always later be added, but not removed)

[piotrpio]

I'm all for it, using endpoint name as subject may be a better option, especially since calling the field Subject here is a bit misleading (it's not the actual subject, just the part after root).

One thing I'm not sure about is validating the endpoints the same way as kv bucket names. From what I remember, bucket names cannot contain subject delimiters, whereas for endpoints I would imagine users wanting to have logical hierarchy, similarly to REST urls, e.g. foo.users.create and foo.users.delete, where foo is the root subject`.

[ripienaar]

Yeah good question. My first instinct is to say it doesn’t matter since the endpoint names will often map to like functions in clients so c.Add(1, 2) and languages just don’t do dots and things in function names

so that forced things to be flat on the endpoint name and the subject is a hidden detail.

If people want to do like a mux of their own then that’s a single endpoint service (what we have now) and that would be the only case I think we want to support like wildcard subjects.

[ripienaar]

@aricart curious about your thoughts here

[Jarema]

I think that endpoint subject == endpoint name.
The Endpoint subject should be ... a valid subject, so we don't care if users wants to have endpoints with . or not.
As we enocurage users to put some queryable tokens in subjects, removing that possibility from services does not seem right.

We might in future consider different approach to build service subjects hierarchy though...

HTTP framerowsk often allow grouping:

r := http.Router()
v1 := r.Group("/v1")
products := v1.Group("products")
products.Endpoint("add", handler)

Which is useful for structuring and adding group specific logic/middleware etc.

We could easily achive that with NATS subject tokens.

[aricart]

@aricart curious about your thoughts here

I think that if we take the api that @Jarema is pointing above, the need for the root subject etc goes away - the group becomes a root subject for that set of endpoints. In otherwords, I think both should be supported - easy should be trivial, and grouped should be easy.

[ripienaar]

should document what are valid endpoint names and enforce

[Jarema]

just realized - shouldn't we have schema per endpoint?

[aricart]

@Jarema I discussed this with Roland, and the schema would be in a single option. If the schema maps the endpoint name to the operations...

[piotrpio]

@aricart agreed, one thing I am wondering about is whether in that case we should have the schema as:

	Schema struct {
		Request  string `json:"request"`
		Response string `json:"response"`
	}

with separation of Request and Response.

Instead, we can have a single schema string with each endpoint containing 2 entries - one for request and one for response (similarly to how it's done in openAPI).

[aricart]

@Jarema @ripienaar had a discussion with @piotrpio and I believe we need to take a stance now on how this is presented for multiple endpoints. @piotrpio is making the ADR changes based on what we discussed

[aricart]

LGTM save for a little nit