Comments (4)
Something like this could be really interesting. Unfortunately this is a very niche kind of thing and we likely won't have the bandwidth to work on it in the foreseeable future. If you are interested in fleshing this out and sending PRs, we can review them.
As for an implementation plan, I'd propose something like:
- Add these generic interfaces and implementations in the
experimental
package. - Have the codegen produce them only if a flag is set.
- Give some time for users to try them out. If they prove to be good, move the definitions to the
grpc
package with type aliases inexperimental
for several releases.
Not being backward compatible would be the biggest problem with changing how the codegen works. We'd either need to generate both together with different names (the non-generic implementation could even call the generic one), or we'd need a flag to decide which one to generate. If we generated both, we'd need to choose good names to be ergonomic and to avoid conflicts.
I'm not concerned about supporting versions of Go older than 1.18, as this kind of thing is necessary from time to time anyway (e.g. we will soon be making changes to the codegen that will require the most recent release of grpc-go, which doesn't support 1.18 already).
from grpc-go.
Thanks for taking the time to read! I'd be happy to contribute implementation, but of course also have a lot of other things on my plate so no guarantees.
Would you also be willing to accept an implementation plan like this:
- Add generic interfaces and implementations to the
grpc
package. Modify codegen to produce the same exact exported type names as today, but with (e.g.)GreeterReadOnly_SayHelloServer
being a type alias forgrpc.ServerStreamServer[HelloReply]
. - Add a flag to codegen to stop producing and using the type aliases, and instead use the underlying generic types directly.
- Give some time for users to try them out. If people like it, flip the default value of the flag and eventually remove it entirely.
To my mind, the big change here is in the publicly-exposed interface, and that's the thing worth protecting behind a flag. But I definitely don't have insight into all of the things the gRPC team might be concerned about (do Go generics have meaningfully different runtime performance? I don't think so, but maybe) so I'm not sure if swapping out the underlying implementation is too risky to not put in experimental
first.
Thanks for the note about go 1.18; I'll keep an eye on other compatibility stuff and just make sure any reliance on generics lands after the other changes you mentioned.
from grpc-go.
I definitely would like to put the interfaces in experimental
first, to prevent anyone from relying upon them until all of the work is done and we're sure they are going to work. The other option is to put them in the permanent location with an "experimental" tag on them in doc strings, but unfortunately, lots of our users don't heed those sorts of warnings and changing them later can be a major problem.
Does the type aliases prevent any backward compatibility breakage problems? If so, that might be the ideal final state? I really don't want to be in a situation where users have to choose between two different forms of codegen that are incompatible. Otherwise no old generated code library can ever migrate to the new style (without a v2 since it's a breaking change), and users of that generated code would be stuck implementing it that way forever.
from grpc-go.
Related Issues (20)
- Unable to Perform Server-Side Stream Initialization Checks in gRPC Client-Side Streaming RPC to return error on stream creation HOT 3
- Client waits with DNS query when no channel's available HOT 6
- Profile Guided Optimization results in high memory usage HOT 6
- Make server workers channel buffered? HOT 11
- xdsresolver uses ldsResourceName instead of using data plane authority HOT 2
- Question: PING frame HOT 7
- Call grpc.Invoke with nil "opts ...CallOption" throw a "invalid memory address or nil pointer dereference" and panics HOT 3
- Does gRPC-go URL encode `/`'s from xDS dial target HOT 1
- Stabilize `UseCompressor` and `SetSendCompressor` HOT 1
- subChannel triggerDelete lead to dead loop HOT 5
- xds: ADS stream failure triggers wildcard subscriptions on new stream HOT 11
- Context cancellation when request finishes HOT 1
- New `Compressor`: Support metadata other than `Name` for trained compression HOT 8
- Why does `/internal/transport/proxy.go` `doHTTPConnectHandshake` call `resp.Body.Close()`? HOT 1
- retry: Status should indicate more details when retries are enabled and an RPC fails HOT 6
- gRPC error ResourceExhausted should include payload size in error details HOT 2
- grpc processes connection data to start multiple Goroutines, and whether Goroutines can be merged to reduce additional overhead HOT 2
- A potential deadlock or goleak HOT 3
- Breaking Change: xds `Return no matching virtual host found` error HOT 6
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 grpc-go.