-
Notifications
You must be signed in to change notification settings - Fork 192
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 boxed method to service builder #1840
Conversation
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
/// Applies [`Route::new`](#{SmithyHttpServer}::routing::Route::new) to all routes. | ||
/// | ||
/// This has the effect of erasing all types accumulated via [`layer`]. | ||
pub fn boxed<B>(self) -> $serviceName<#{SmithyHttpServer}::routing::Route<B>> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't this method go in an extension trait in a runtime crate?
Bringing this up because I feel that less generated code is usually better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually believe the opposite.. generated code is easier to manage and release than runtime code.. the more we codegenerate, the easier is for customers to consume as it is not tied to crates releases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this was a standalone function I think it might fit better in the rust-runtime
crates but given that this is a small method on a generated struct I think it makes sense to leave it here for now. If we did this via extension trait the customer would have to import the trait to use the method which may be confusing.
It is possible though: we'd need to add a base trait with the layer
method on it, impl that onto PokemonService
via codegen, and then include this boxed
method extension to that trait.
Maybe we should draft out a heuristic to help in this kind of decision making?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we should figure out guidelines to decide whether to put stuff in runtime vs codegen!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case I'd lean towards putting this method in the code generated struct
. It's a better developer experience than having to import a single-use extension trait just to call it.
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
Motivation and Context
As a result of the Service Parameterized Routers change, the
{ServiceName::layer}
modifies the type of the service. This has the benefit of avoiding the heap but means that types can build up with several applications oflayer
.For users who wish to erase the types via
Route::new
(Box::new
in disguise), we provide aboxed
method. This can be seen as an opt-in reversal to the Service Parameterized Routers change.Description
boxed
method to the service builder.S
to the service builder.