Is your feature request related to a problem? Please describe.
This is some example generated code I'm working around:
func NewCheckServiceHandler(svc CheckServiceHandler, opts ...connect.HandlerOption) (string, http.Handler) {
checkServiceMethods := v1alpha2.File_ory_keto_relation_tuples_v1alpha2_check_service_proto.Services().ByName("CheckService").Methods()
checkServiceCheckHandler := connect.NewUnaryHandler(
CheckServiceCheckProcedure,
svc.Check,
connect.WithSchema(checkServiceMethods.ByName("Check")),
connect.WithHandlerOptions(opts...),
)
checkServiceBatchCheckHandler := connect.NewUnaryHandler(
CheckServiceBatchCheckProcedure,
svc.BatchCheck,
connect.WithSchema(checkServiceMethods.ByName("BatchCheck")),
connect.WithHandlerOptions(opts...),
)
return "/ory.keto.relation_tuples.v1alpha2.CheckService/", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
switch r.URL.Path {
case CheckServiceCheckProcedure:
checkServiceCheckHandler.ServeHTTP(w, r)
case CheckServiceBatchCheckProcedure:
checkServiceBatchCheckHandler.ServeHTTP(w, r)
default:
http.NotFound(w, r)
}
})
}
There are multiple problems I currently run into:
- I have a middleware for collecting prometheus metrics which uses
req.Pattern as a label. I register the handler in the recommended way: r.Handle(relationtuplesconnect.NewCheckServiceHandler(h)). However, this means that the req.Pattern will only be the service name excluding the procedure name, therefore it is missing some of the information I need later.
Note that while the request path could be used for connect endpoints, there is no good way to know if the request will be handled by a connect handler or another one on servers with other handler types.
- The not-found handler is hard-coded to
http.NotFound, but that is not compatible with my already existing clients.
Describe the solution you'd like
Ideally there would be a way to easily register the *connect.Handlers for each procedure directly on the mux, without a separate routing level in the generated code.
Describe alternatives you've considered
The obvious alternative is to duplicate the generated code and directly registering the handlers, or fork the generator to produce my own variant of the server setup boilerplate.
Additional context
Is your feature request related to a problem? Please describe.
This is some example generated code I'm working around:
There are multiple problems I currently run into:
req.Patternas a label. I register the handler in the recommended way:r.Handle(relationtuplesconnect.NewCheckServiceHandler(h)). However, this means that thereq.Patternwill only be the service name excluding the procedure name, therefore it is missing some of the information I need later.Note that while the request path could be used for connect endpoints, there is no good way to know if the request will be handled by a connect handler or another one on servers with other handler types.
http.NotFound, but that is not compatible with my already existing clients.Describe the solution you'd like
Ideally there would be a way to easily register the
*connect.Handlers for each procedure directly on the mux, without a separate routing level in the generated code.Describe alternatives you've considered
The obvious alternative is to duplicate the generated code and directly registering the handlers, or fork the generator to produce my own variant of the server setup boilerplate.
Additional context