Comments (7)
@DerArkeN Thanks for raising this question! JSON representation has advantage over the struct/protobuf representation, which is that it is possible to encode configurations for LB policies that are not known to gRPC. In protobuf form, the loadBalancingConfig field contains a oneof supporting only the built-in LB policies. However, in JSON form, the field inside the oneof is encoded as a string that indicates the LB policy name. In JSON form, that string can be any arbitrary value, not just one of the supported policies inside of the oneof, so third-party policies can be selected. For more info, please check this out.
Hope this answers your question.
from grpc-go.
@aranjans Thank you for your answer! This definitely makes sense, I am aware of the issues with oneof using protobuf as well. Though I think it would be helpful to provide a struct which represents the JSON tags for the method config since they are not arbitrary (at least I think so). When implementing my retryPolicy I spend a lot of time looking up the field names and making sure the passed values are in the correct format.
If there was a struct in the std library providing correct datatypes, documentation and their corresponding JSON tags, implementing a serviceConfig would be way easier.
The LB policies could still be passed as a JSON string like following:
type ServiceConfig struct {
MethodConfig []*MethodConfig `json:"methodConfig"`
LoadBalancingConfigJSON []string `json:"loadBalancingConfig"`
}
type MethodConfig struct {
Name []*Name `json:"name"`
WaitForReady bool `json:"waitForReady"`
RetryPolicy *RetryPolicy `json:"retryPolicy"`
}
type Name struct {
// the service name from the proto file (package.service)
Service string `json:"service"`
Method string `json:"method"`
}
type RetryPolicy struct {
MaxAttempts int `json:"MaxAttempts"`
InitialBackoff string `json:"InitialBackoff"`
MaxBackoff string `json:"MaxBackoff"`
...
This is just my personal preference though and I don't know how much sense It would make to imlement this in practice since I don't know enough about this topic...
Thank you for your time!
from grpc-go.
Could you please shed some more light on how (and why) you are specifying the retry configuration on the client, and not getting it from the name resolver? Thanks.
from grpc-go.
Hello, I looked at this example .
from grpc-go.
Hmm ... we probably have to revisit that example.
Did you get a chance to look at https://github.com/grpc/grpc/blob/master/doc/service_config.md, where in the first line it says: The service config is a mechanism that allows service owners to publish parameters to be automatically used by all clients of their service.
Is pushing the service config through the name resolver not an option for you?
from grpc-go.
I had a discussion about service configs with the extended gRPC team and based on that, here are some thoughts/ideas:
- The most common and expected way for gRPC clients to receive service config is to have the name resolver distribute the service config.
- But there are cases where that's not feasible, such as if you don't have any centralized way to distribute the service configs -- e.g., let's say that you are using some bespoke name resolution mechanism that doesn't have a way to distribute service configs, or you don't trust DNS TXT records.
- There are also cases where it may be desirable to set a default service config on the client side to be used only if the resolver does not return a service config.
Also, with regards to changing the API to support accepting service config as a struct (with json tags), our preference is to accept service config as JSON in our API, since that helps to keep our API as simple as it can be. While we are not totally opposed to the idea of supporting other means of accepting service config through our APIs, it is not a priority for us, and unless it is something that multiple users would want, we are happy with what we have currently.
Hope this helps.
from grpc-go.
Hello once again, thank you for the detailed answer and the effort you put into it, it helped a lot!
I will close the question now, have a great day.
from grpc-go.
Related Issues (20)
- design tradeoffs about not including ctx in method argument for generated stream handler HOT 3
- google.protobuf.Empty as response serializes to not empty response depending on request headers HOT 2
- How to make server-stream run in a non-blocking state and handle other requests HOT 10
- Improve Logger Performance When Disabled HOT 5
- Flaky Test: RingHash_ReattemptWhenGoingFromTransientFailureToIdle
- xdsclient: reduce the number of ADS requests
- grpctest: minor improvements to the test logger implementation
- xdsclient: support environment variable protection for fallback
- Incorporate `mem` package into custom HTTP/2 Framer
- Examples using the `experimental` stats package HOT 2
- about grpc.NewClient,It will not check the validity of the target ? HOT 1
- Minor typos HOT 7
- clientconn: Subconn state may transition from CONNECTING directly to IDLE HOT 1
- Flaky Test: Balancer_TwoAddresses_WeightExpiration HOT 1
- Add a test for scenarios touched in 7505
- RetryPolicy backoff value being randomized makes no sense compared to C++ reference client HOT 2
- pickfirst: Don't use internal.ShuffleAddressListForTesting directly HOT 1
- grpc usage on unix sockets: strange grpc registry behaviour
- Question about option experimental.WithRecvBufferPool
- Flake: Test/BlockingPickSCNotReady
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.