Alanxtl commented on PR #688:
URL: https://github.com/apache/dubbo-go-pixiu/pull/688#issuecomment-3016348939
> > 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:
>
> ```
> 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.
so you want to move `dgp.filter.network.dubboconnectionmanager` and your
`dgp.filter.network.grpcproxy` out of `pkg/filter/` and make them into a proxy
level, instead of filtermanager level?
Is my understanding correct? If so, I think the future request processing
path would be like this
```mermaid
graph TD
A[Client] --> B[GrpcListener];
subgraph p [pixiu]
B --> C[new proxy level];
C --> D_sub[old grpcconnectionmanager];
end
subgraph D_sub [old grpcconnectionmanager]
D(dgp.filter.grpc.proxy)-->E(other filter)
end
E --> G[Backend Service];
```
don't you think the new proxy level and old grpcconnectionmanager have some
duplication? and what's the meaning of extract a proxy level are there any
functions that cannot be realized now?
--
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
