Conversation
|
|
| * Author(s): Keith Adler (Talador12) | ||
| * Approver: a11r | ||
| * Status: Draft --- {Draft, In Review, Ready for Implementation, Implemented} | ||
| * Implemented in: Core (C++), Java, Python, and Go. |
There was a problem hiding this comment.
There are two big chunks to this feature: codegen and the runtime HTTP/1 server. Codegen is definitely language-specific, but the runtime aspect doesn't have to be. If possible, the runtime aspect should be implemented entirely in Core, so that it won't have to be reimplemented for Python, Ruby, PHP, and C#.
Is there any particular reason why you called Python out as the only wrapped language here?
I don't think it's an absolute must that this feature be implemented in all languages from the get-go, but I think we should design it in such a way that adding support to additional languages in the future is as easy as possible.
There was a problem hiding this comment.
I agree on Core first. I called out Python first because I am working primarily in python projects/libraries and think it is a decent option.
I don't think it's an absolute must that this feature be implemented in all languages from the get-go, but I think we should design it in such a way that adding support to additional languages in the future is as easy as possible.
Agreed. Better to do this the right way than a rush job.
I'll add more detail about those 2 facets.
A35-grpc-gateway.md
Outdated
|
|
||
| ## Proposal | ||
|
|
||
| Add a [grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) like component that is a separate binary/process from the gRPC server. It can be deployed alongside a server of any language. This should be in-library support, and not a `grpc-ecosystem` project. That way, you wouldn't have to orchestrate a separate gateway process. To implement this, it is necessary to ensure that support is added across the language matrix, which will entail four different implementations: Core (C++), Java, Python, and Go. |
There was a problem hiding this comment.
Is it actually necessary that this be implemented as a subprocess? I think the real value is in translating from JSON+REST to gRPC, regardless of how it happens under the hood.
There was a problem hiding this comment.
I'll clarify, the value of JSON+REST to gRPC is the goal
A35-grpc-gateway.md
Outdated
| grpc-gateway is a separate binary/process from your server. It can be deployed alongside a server of any language, which (I assume) is what's happening in the gist you linked above. We have talked about in-library support for this sort of thing in the past. That way, you wouldn't have to orchestrate a separate gateway process. But that would be a pretty substantial effort. | ||
| ``` | ||
|
|
||
| As gRPC has grown in popularity and usage, an option to run in-library support would be a huge win for many teams. Instead of a sidecar, this gateway could be run alongside the gRPC server instance itself. As it would be a substantial effort, the background section will detail out the complexity of implementing across all languages and the steps required to start this process. |
There was a problem hiding this comment.
Can you add a little more detail to this? I'm interested in your perspective on the usage of grpc-gateway out in the wild.
|
^^ Updated approver on the proposal |
|
CC @ejona86 @dfawley @markdroth as tech leads for Java, Go, and C++ respectively. I'm still concerned that this still reads more as a feature request than a proposal, but they can hopefully help guide things more in that direction. |
|
I think @wenbozhu is the right person to evaluate this gRFC and see if this is the right direction and features to have in gRPC. |
|
@wenbozhu Did you get a chance to review this proposal? |
|
Sorry I missed this. Will take a look asap. Thanks. |
|
|
||
| ## Rationale | ||
|
|
||
| Using the `grpc-gateway` as a separate project is not always an option based on library usage. Projects that build on top of `grpc` often want the capability to offer HTTP1 traffic to clients, but do not have the ability to use in library solutions. Currently, most simply do not offer HTTP1 traffic. This excludes usage by several projects and companies. |
There was a problem hiding this comment.
Could you elaborate on this? Ignoring the overhead of grpc-gateway as a separate proxy/process, why is it impossible to deploy grpc-gateway for solutions that expose grpc endpoints?
|
|
||
| ## Proposal | ||
|
|
||
| Add a [grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) like component that able to REST+JSON towards the gRPC server. It can be deployed alongside a server of any language. This should be in-library support, and not a `grpc-ecosystem` project. To implement this, it is necessary to ensure that support is added across the language matrix, which will entail four different implementations: Core (C++), Java, Python, and Go. Core should come first so that as much as possible is language agnostic. |
There was a problem hiding this comment.
(I assume this gRFC only concerns server-side implementations.)
The benefits of grpc-gateway are that it's very extensible and it uses a grpc client to address "combability" concerns.
For in-library support, we still have to decide if we are talking about in-process proxying, or a new transport for gRPC runtime, or maybe something in-between.
Another alternative is to create a list of language-specific server-side interceptors to support REST endpoints alike; and use the http/1.1 stack provided by the language-platform.
There was a problem hiding this comment.
I may be wrong about the interceptor part (for servers). I vaguely remembered that it was proposed to support non-standard transports, as a lightweight solution. @gnossen
4 participants
See A35 proposal included in PR 😎