Comments (7)
Yes, adaptation to stream middleware is rudimentary because the current interface model does not have a good abstraction
from kratos.
Would there be interest in proposals around this? We haven't looked super closely at it, but it seems like there would be a few options:
- Could approach it the way gRPC does with separate interfaces and implementations for unary and streaming endpoints. This is what we've done for now- reimplementing the middleware we need as gRPC stream interceptors and injecting them: https://github.com/project-kessel/relations-api/pull/105/files#diff-85d6db9d4d33f7064a02bbe45907ffdaca1cd1382bbfdb5ab8c4a7e77841cea5R25
- Or, if there's a desire to unify unary and streaming middleware under one interface, that should be possible if the interface is streaming-first, since a unary request could be thought of as a streaming request with one incoming and one outgoing messages. I could work up something more concrete around this if there's interest.
from kratos.
@wscalf OK
from kratos.
But we need to think about how to do it better
from kratos.
FWIW, I did some poking around at what it would take to have a unified middleware interface for unary and streaming endpoints. It does look possible, and there's some precedent for doing so: go-grpc-middleware defines a Reportable interface and interceptor wrappers that allows for the same implementations to be used with both kinds of endpoints. It's only used for logging, though it seems like something similar could apply generally.
I think it would be a breaking change to the middleware interface to be able to observe and react to multiple incoming or outgoing messages, but existing middleware could still be called from the UnaryServerInterceptor and accessed by the HTTP transport as they are today, alongside the unified middleware, so a piece-by-piece migration should be possible without breaking current functionality or end-user authored middleware.
Maybe something like: type Handler func(ctx context.Context, receiveMsg, sendMsg func(msg any) error, info CallInfo) error
, which would allow implementations to keep more or less the natural flow they have now while being compatible with streaming.
This would allow for implementations like:
func Validator() middleware.Middleware {
return func(handler middleware.Handler) middleware.Handler {
return func(ctx context.Context, receiveMsg, sendMsg func(msg any) error, info CallInfo) error {
recv := func (req any) error {
if v, ok := req.(validator); ok {
if err := v.Validate(); err != nil {
return errors.BadRequest("VALIDATOR", err.Error()).WithCause(err)
}
}
return nil
}
return handler(ctx, recv, func(any) error {return nil}, info)
}
}
}
Or if a middleware wanted the flexibility to treat streaming endpoints differently (ex: if logging middleware didn't want to log streamed inputs), that would still be possible by observing properties on CallInfo (which atm is intended to indicate whether the requests and/or responses are streaming, which would be a passthrough of grpc.StreamServerInfo for streaming gRPC requests and false/false for unary and HTTP requests.)
Thoughts/feedback? I've been mostly exploring so far but could put a draft PR together to provide something more concrete if there's interest, or pivot if this seems totally off the mark.
from kratos.
@go-kratos/contributor
@shenqidebaozi
from kratos.
I've been quite busy lately, let me take a look now
from kratos.
Related Issues (20)
- [Question] DDD的最佳实践方式?包括CQRS、Clean Architecture、六边形结构 HOT 5
- [Question]请教下kratos如何定义支持上传文件接口? HOT 2
- metrics statistics and usage issues [Question] HOT 5
- `stream` response in proto failed to generate http client HOT 6
- [Feature] Add kratos errors to buf remote plugin HOT 1
- [Question] I modified it based on examples/helloworld and found that client/main.go reported an error when executing. I am not sure if it is a BUG. HOT 1
- HTTPClient proto: syntax error (line 1:1): unexpected token 404 HOT 3
- [Question] how to set response content-type as xml for one method HOT 2
- [Question] HTTP Server. extra add route do not pass middleware. HOT 2
- I a new release due soon ? HOT 4
- [Question] Can I custom project layouts by using kratos to generate HOT 1
- [Question]Excuse me, what is the error when compiling? HOT 2
- t
- [Question] About the current p2c algorithm HOT 1
- bug in Quick Start HOT 1
- [Question]how can i catch issue when i use config hot reload with a mismatch type
- 使用北极星作为服务发现时,在注册多个grpc client时,启动报错:concurrent map iteration and map write HOT 4
- [Question]how to get all router HOT 1
- GRPC MaxSendMsgSize MaxRecvMsgSize setting HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kratos.