-
Notifications
You must be signed in to change notification settings - Fork 2.8k
[router] Implement HTTP Dependency Injection Pattern for Router System #8714
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
Conversation
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.
Summary of Changes
Hello @slin1237, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
I've refactored the router system to implement a proper HTTP Dependency Injection pattern. The primary goal was to address verbosity, redundancy, and scalability issues caused by passing the HTTP client through every RouterTrait
method. This change introduces an AppContext
to centralize dependencies, streamlines router construction, and simplifies method signatures across the router system, resulting in cleaner, more maintainable, and extensible code without impacting performance or accuracy.
Highlights
- Centralized Dependency Management: I've introduced an
AppContext
struct that acts as a central container for shared dependencies like the HTTP client, router configuration, and concurrency limiter. This simplifies dependency management across the application. - Updated Router Factory: The
RouterFactory
now acceptsAppContext
to create router instances, ensuring that all necessary dependencies are properly injected into the router constructors. - Improved Router Constructors: Both
Router
andPDRouter
constructors have been updated to directly receive thereqwest::Client
as a parameter, storing it internally. This eliminates redundant client creation and ensures consistent client usage. - Simplified RouterTrait Interface: I've significantly simplified the
RouterTrait
interface by removing theclient: &Client
parameter from all its methods. This makes method signatures cleaner and more focused on their core responsibilities. - Consistent Client Usage: All router methods and background tasks now use the internally stored
self.client
instead of receiving it as a parameter, leading to more consistent and maintainable code. - Cleaner Server Route Handlers: Server route handlers have been cleaned up; they no longer explicitly pass the HTTP client to router method calls, accessing it through the
state.context.client
where needed. - Comprehensive Test Updates: All test helpers and test files have been updated to align with the new
AppContext
and dependency injection patterns, ensuring full test coverage and functionality are maintained.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
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.
Code Review
This pull request introduces a dependency injection pattern using an AppContext
to manage shared dependencies like the HTTP client. This is a great architectural improvement that cleans up the RouterTrait
interface by removing the client
parameter from its methods, making the code more maintainable and scalable. The changes are consistently applied across the router implementations, server handlers, and tests. My main feedback is to extend the refactoring to some of the inherent helper methods within the router implementations to fully adopt the new pattern.
d39172d
to
d923e4f
Compare
d923e4f
to
d94ce7d
Compare
@@ -22,29 +22,34 @@ use tokio::spawn; | |||
use tracing::{error, info, warn, Level}; | |||
|
|||
#[derive(Clone)] | |||
pub struct AppState { | |||
pub router: Arc<dyn RouterTrait>, | |||
pub struct AppContext { |
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.
What is the reason of this change?
Motivation
The current router system passes the HTTP client as a parameter through every RouterTrait method, leading to:
This PR refactors the router system to use proper dependency injection through an AppContext pattern, making the code cleaner, more maintainable, and easier to extend.
Modifications
1. Introduced AppContext Pattern
AppContext
struct to serve as a dependency container holding the HTTP client, router configuration, and concurrency limiterAppState
to contain both the router and the shared context2. Updated RouterFactory
create_router
signature to accept&Arc<AppContext>
instead of&RouterConfig
3. Improved Router Constructors
client: reqwest::Client
parameter and field to store the injected clientclient: reqwest::Client
parameter, renamed internalhttp_client
toclient
for consistency4. Simplified RouterTrait Interface
client: &Client
parameter from all 10 RouterTrait methods5. Updated Implementations
self.client
instead of receiving it as a parameter6. Cleaned Up Server Route Handlers
state.context.client
7. Fixed All Tests
Accuracy Test
This PR only affects the router infrastructure and dependency injection pattern. It does not modify any model-side code, kernels, or model architecture. No accuracy testing is required.
Benchmark & Profiling
This refactoring is performance-neutral as it:
The change is purely architectural and should not impact throughput or latency.
Checklist