Similarityoung commented on PR #688: URL: https://github.com/apache/dubbo-go-pixiu/pull/688#issuecomment-3016324990
> what's the difference between old `dgp.filter.grpcconnectionmanager` and your `dgp.filter.network.grpcproxy`? It seems the same You've raised a very insightful point. From a purely functional standpoint, extending the existing `dgp.filter.grpcconnectionmanager` is certainly feasible. My decision to create a new `dgp.filter.network.grpcproxy` was primarily driven by the goal of maintaining strict architectural consistency with the existing `dgp.filter.network.dubboproxy` module. As you can see, dubboproxy establishes a clear, network-level proxy pattern that includes a manager and a core filter: ```text dubboproxy/ ├── filter/ │ └── proxy/ │ └── dubbo_proxy_filter.go (Core proxy logic implementation) ├── dubbofiltermanager.go (Dubbo filter manager) ├── manager.go (Dubbo connection manager & filter chain invocation) └── plugin.go (Plugin entry point for the Dubbo proxy network filter) ``` My `grpcproxy` implementation deliberately mirrors this structure to reduce cognitive load and unify the maintenance patterns for both proxy types. However, I completely agree with your implicit assessment: placing specific business proxy implementations like `dubboproxy` and `grpcproxy` within the `pkg/filter/network/` directory is not an ideal long-term design. A clearer refactoring approach that aligns better with the overall project architecture would be to move these reusable proxy capabilities into `pkg/common`. Our generic filter abstractions are already correctly located in `pkg/common/extension/filter`, which shows us the way forward. Therefore, a future evolution path could be: 1. Migrate the `dubboproxy` and `grpcproxy` modules entirely into the `pkg/common/` directory to serve as common proxy implementations. 2. Let `pkg/common/extension/filter` continue to serve as the unified abstraction and management center for all filters. 3. The top-level `pkg/filter/` directory could then be used more purely to orchestrate and apply the different protocol-specific filter chains (like HttpFilter, DubboFilter, GrpcFilter) that are built from the core capabilities in `common`. This would result in a much cleaner project layering: `pkg/common` provides reusable core capabilities, while `pkg/filter `handles the business-level orchestration. Thank you for your input; it has significantly clarified the path for future refactoring. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org For additional commands, e-mail: notifications-h...@dubbo.apache.org
