Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RouteHandlerMiddleware unwieldy for endpoint-specific handling #359

Open
jamesross3 opened this issue Dec 4, 2021 · 0 comments
Open

RouteHandlerMiddleware unwieldy for endpoint-specific handling #359

jamesross3 opened this issue Dec 4, 2021 · 0 comments

Comments

@jamesross3
Copy link
Contributor

Existing method signature:

type RouteHandlerMiddleware func(rw http.ResponseWriter, r *http.Request, reqVals RequestVals, next RouteRequestHandler)

When adding RouteHandlerMiddleware, the RouteSpec within RequestVals is difficult to use safely given the path template of a RouteSpec is a construction of:

  • the server's configured context path
  • other subrouter paths
  • the path of the endpoint of interest

Upon my first attempt at writing a RouteHandlerMiddleware, ensuring I matched a specific endpoint proved challenging - I had to choose between either taking an implicit assumption on witchcraft-go-server's usage of the context-path configuration point (I guess this is a pretty safe assumption) or just matching the path using strings.HasSuffix. I am unsure if there's something a little more ergonomic to provide users here.

Separate issue: when used in conjunction with conjure-go generated server code, an additional snag is having to copy the string literal for the route from the generated server code. Perhaps a separate ergonomics improvement there is defining those string literal paths as exported constants in conjure-go-generated code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant