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

Add construct_router function #447

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

RaoulHC
Copy link
Contributor

@RaoulHC RaoulHC commented Apr 8, 2024

If you want to use a single server and have matchbox signalling at a specific route it's useful to be able to get the router directly and work with that. You can't use mutate_router as that occurs before the final router construction and you'll likely end up with conflicting routes. I don't think you can expose a constructed IntoMakeServiceWithConnectInfo as that can't be merged/nested into another router, it just has to be called at the root level before use.

Open to other suggestions to how to do this, but this seems like the most straight forward and flexible way to do it.

I also loosened the traits for mutate_router which I didn't end up needing, but it is more restrictive than necessary.

@@ -66,7 +66,7 @@ where

/// Modify the router with a mutable closure. This is where one may apply middleware or other
/// layers to the Router.
pub fn mutate_router(mut self, mut alter: impl FnMut(Router) -> Router) -> Self {
pub fn mutate_router(mut self, alter: impl FnOnce(Router) -> Router) -> Self {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is FnOnce less restrictive than FnMut? Not understanding, honestly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This allows you to use closures that can only be called once, such as ones that take ownership, which won't satisfy FnMut. FnMut by definition must satisfy FnOnce, so this does allow more closures/functions.

Comment on lines 119 to 122
/// <div class="warning">
/// You must call `into_make_service_with_connect_info::<SocketAddr>()` before serving this
/// router for matchbox to work
/// </div>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a little concerning. It seems too easy to get wrong. Perhaps a flyway pattern could help us?

However, I'd rather pass the 2 routes ("/" and "/:path") as arguments to build or have some build_with(Router) method alternative.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flyway pattern?

Yeah I was hoping that there was some way of passing across the service that ensured this but couldn't find a way.
A build_with alternative sounds like a good idea though, I think it's best to have something more flexible than just passing routes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've implemented a build_with alternative, and added a test for how it can be used too.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try testing this soon. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bump for a review when you get a chance

This allows you to modify the final router while ensuring that the
connect info is still available to the signaling server.
@RaoulHC
Copy link
Contributor Author

RaoulHC commented Aug 6, 2024

I've rebased this, @simbleau could you take a look?

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

Successfully merging this pull request may close these issues.

2 participants