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
Remove usage of utils/restendpointhelper.go in favor of the new router #3712
Comments
There's the easy way of just calling Making a new middleware like pagination won't work with There's a better way to just use the |
Sounds like the pagination is a different topic. I haven't looked into that. I'll file a new issue. |
Bit of a misunderstanding. To clarify, its more to do with design than anything being broken or non-functional. Pagination works but the middleware directly queries the params from the request object instead of taking the arguments set in the handler, for example: Line 78 in ae76abb
The owncast/handler/integrations.go Line 22 in ae76abb
The generated router already surfaces this once, seems wasteful to do it again, but wouldn't exactly break anything. The problem is more the incompatibility of chaining stuff like:
with this: owncast/router/middleware/auth.go Line 15 in ae76abb
They work as their own ends of a chain, but if they need to be chained (like a hypothetical path parameter handler that is wrapped around the externalAPIUser auth middleware), it won't be clean. One would have to know about the other since the controller function would need to surface the other's params to be called. They can't wrap each other since neither can accept a standard They're more "end"-wares than middle, is my problem.
won't work since the Access expects a or
which also won't work since the pagination expects a We could ignore it for this case, but what happens if there's ever an endpoint that needs both pagination and and external API access? The controller would look like: Using contexts, we can simply use that to pass values around instead, and middlewares don't need to create these custom types to deal with specific arguments and can all just take and return just the writer and request objects. |
I see what you're saying. We could remove the pagination middleware, as it is there primarily for convenience, and just export a similar version as a utility function that can be used in handlers that require pagination. The result would be the same, the logic for pulling out those values would just be done in a different place. |
Share your bug report, feature request, or comment.
Once #3653 is in, we can refactor out all the use of the endpoint helper and use the native functionality built into the router to support dynamic path components as arguments.
The text was updated successfully, but these errors were encountered: