Comments (7)
I don't think it was a good idea to deprecate Dial
and DialContext
. They are not niche APIs. They are used by literally every grpc-go client implementation; you can't implement a gRPC client without it dialing a gRPC server. By marking them deprecated you are asking every user to evaluate every use of Dial, see how it should be updated, and submit a patch to make the change. This is not a trivial amount of work when you consider the wide use of gRPC.
There are 178,000 open source imports of grpc and countless more inside proprietary code bases and basically all of them are using Dial
, either because they provide a grpc client, or a grpc server and they have end-to-end testing. For any of those projects using standard linting tools their CI's are blowing up with deprecation warnings. My one organization's codebase has over 300 calls to Dial, mostly in test cases.
What I would rather see is continued support for Dial with perhaps a doc comment on why a user might prefer to use NewClient
instead.
from grpc-go.
What I would rather see is continued support for Dial
Dial
support isn't going away, by the way. It will stick around.
Yes, there will be a linter warning if you run a linter that complains about your use of deprecated features. You should have a way to silence linters that you disagree with. That's a tooling problem, not a problem with our decision to deprecate this API. New users need to be funneled to NewClient
instead, and Deprecated
tags are how that is done.
from grpc-go.
Could the maintainer team as least suggest some replacements for usages of Dial(WithBlock())
or Dial(WithTimeout())
? That's the main migration path that I see practically impacting most people affected by the deprecation cycle.
I'm not seeing a clear or elegant path to replacing that functionality with NewClient
without adding a lot more boilerplate beyond what previously existed with Dial
. Specifically, if a developer wants to wait for the connection state to be "Ready" and block until that is the case, what is the advisable way to achieve that with the new API patterns?
from grpc-go.
https://go.dev/wiki/Deprecated
Sometimes an API feature such as a struct field, function, type, or even a whole package becomes redundant or unnecessary. When we want to discourage new programs from using it, we mark that feature “deprecated”.
In contrast to some other systems, an API feature being deprecated does not mean it is going to be removed in the future. On the contrary, Go 1 compatibility means the feature will be preserved in its deprecated form to keep existing programs running.
This all sounds WAI.
One thing we did get wrong according to this recommendation was to release NewClient
at the same time as deprecating Dial
/DialContext
. We can un-deprecate for one release if it helps, but the decision is to call it deprecated to encourage the use of the new API.
from grpc-go.
Seems like this was only fixed in 1.63 but not in the new 1.64.0?
Was the issue that was fixed that it was undocumented, and now that it was noted in the release note the problem is solved? IMO that is not the issue, the issue is the deprecation to begin with. As #7090 (comment) notes, this will require 178,000 usages to be changed across the ecosystem.
If this issue was supposed to be scope only to "undocumented" and not "do not deprecate it" let me know and I can open a new issue or PR.
from grpc-go.
@howardjohn, the issue was only about missing docs. You should create a new one (or find an existing one) if you want to ask for "undeprecating" the deprecated API.
from grpc-go.
Have you seen https://github.com/grpc/grpc-go/blob/master/Documentation/anti-patterns.md already?
You have a couple options for what you are asking for:
- Keep using
grpc.Dial
. If yourstaticcheck
/etc is complaining about using something deprecated, disable it. - Use
grpc.NewClient
followed by pollingClientConn.State()
andWaitForStateChange()
. https://pkg.go.dev/google.golang.org/grpc#ClientConn.WaitForStateChange This is what we do internally to supportWithBlock
andWithTimeout
(made more complicated to handle other un-recommended options):
Lines 266 to 290 in 24e9024
from grpc-go.
Related Issues (20)
- xds: move functionality from `xds/internal` to `internal/xds`
- stubserver: add support to optionally pass in a `grpc.Server` or `xds.GRPCServer` HOT 2
- Github Action: Codecov action is broken and is failing silently HOT 1
- Upgrade to using math/rand/v2 to get perf enhancements HOT 2
- xds: tests shouldn't rely on the presence of an entry in the `authorities` field of the bootstrap configuration with an empty key
- Experimental API related to metadata HOT 4
- Linter rule for using context.Background() without a timeout in tests HOT 4
- gRPC is incompatible with tls.Listener HOT 2
- Closing connection takes up to 15 minutes. HOT 5
- Feature Request: expose handleRawConn or add ServeConn HOT 26
- Flaky test: TimerAndWatchStateOnErrorCallback HOT 4
- xds: bootstrap config is not emitted to logs in a human readable way
- Strongly-type request inside a Stream Server Interceptor HOT 2
- Proxy connection buffer necessary? HOT 1
- Why does grpc.NewClient silently ignore DialOptions? HOT 2
- Make transport.SetConnection public? HOT 4
- what's the default max data size
- If a priority contains multiple localities with pick_first, load is reported incorrectly HOT 4
- NewClient doesn't work with WithContextDialer HOT 2
- xds: make the bootstrap configuration a singleton
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.