Yes. There is no way to interact with it streaming.

Chao Zhang <tok...@apache.org> 于2022年7月7日周四 19:52写道:
>
> The ngx_grpc module doesn’t support the http/2 connection multiplex, and
> it’s not interactive unless we use the subrequest.
>
> Yong Qian <nic...@apache.org>于2022年7月7日 周四17:44写道:
>
> > Hi,
> >
> > What is the difference between this new ngx-grpc-client-module and the
> > current ngx_http_grpc_module? Can't I use the current
> > ngx_http_grpc_module with some minor changes to achieve a similar effect?
> >
> > On 2022/07/07 08:08:41 Zexuan Luo wrote:
> > > 1. Background
> > >
> > > 1.1 Problem to be solved
> > >
> > > More and more cloud-native applications are adopting gRPC as their API
> > > standard, such as etcd, Dapr, and Envoy. In some cases, only the gRPC
> > > API is available. Apache APISIX currently does not support access to
> > > the API exposed by the gRPC service, and can only go through the HTTP
> > > interface or develop a separate service to act as a proxy.
> > >
> > > 1.2 The benefits of solving this problem
> > >
> > >     1. Allow user to connect with their own gRPC services.
> > >     2. Embrace the ecosystem of Envoy and Dapr
> > >     3. Show our leadership of the popular technology and provide
> > > something the rival is missing.
> > >
> > > 2. How to solve the problem
> > >
> > > We will create a new Nginx module called ngx-grpc-client-module so
> > > that we can interact with Nginx's event system. We choose to use a
> > > mature gRPC implementation and write Lua/C binding for it.
> > >
> > > Hence we study multiple gRPC clients:
> > >
> > > Language:   C++
> > > Repo:       https://github.com/grpc/grpc
> > >
> > > Pro:         1. High performance
> > >                 2. Widely used
> > >
> > > Con:        1. Require nearly 2GB dependencies
> > >                 2. Not easy to compile unless you are a C++ developer
> > >
> > > Language:   Go
> > > Repo:       https://github.com/grpc/grpc-go
> > >
> > > Pro:         1. Written in pure Go
> > >                 2. Widely used
> > >                 3. Familiar to me
> > >
> > > Con:        1. Low performance (We also study connect-go, but it has
> > > worse performance)
> > >
> > > Language:   Rust
> > > Repo:       https://github.com/hyperium/tonic
> > >
> > > Pro:         1. Written in pure Rust
> > >                 2. High performance
> > >
> > > Con:        1. Not familiar to me so I can't make sure it is mature
> > enough
> > >
> > >
> > > If APISIX is a company-inside project, I will choose to use C++.
> > > However, APISIX is an open source project, and it is important to
> > > lower the threshold for participation. People used to complain it is
> > > hard to build APISIX from source, so we can't choose C++.
> > >
> > > We can use Go first and switch to Rust in the future if the
> > > performance is critical.
> > > Changing the underneath gRPC implementation won't break the Lua API
> > > provided by this module.
> > >
> > > The process of unary request can be done in the steps below:
> > >
> > > 1. Encode the proto message and start gRPC call
> > > 2. Create task ctx, call the Go code and suspend Lua thread
> > > 3. Execute gRPC code, put the task ctx and final result to the task done
> > queue
> > > 4. Wait on the task done queue
> > > 5. Remove the data from task done queue
> > > 6. Add the task ctx to Nginx's posted event queue and re-wait on the
> > > task done queue
> > > 7. Resume Lua thread
> > > 8. Finish the gRPC call and decode proto message
> > >
> > > Step 1/8 are done in the Lua.
> > > Step 2/4/6/7 are done in the C code.
> > > Step 3/5 are done in the Go (or other gRPC implementation)
> > >
> > > Client / Server stream requests can be considered as one initial call
> > > plus several unary read/write operations.
> > >
> >
> --
> Best regards
> Chao Zhang
>
> https://github.com/tokers

Reply via email to