In the GPRC Concept document
http://www.grpc.io/docs/guides/concepts.html
The gRPC programming surface concept is mentioned without a definition. Anyone knows exactly what is gRPC programming surface?
Quoting their documentation:
Starting from a service definition in a .proto file, gRPC provides protocol buffer compiler plugins that generate client- and server-side code. gRPC users typically call these APIs on the client side and implement the corresponding API on the server side.
On the server side, the server implements the methods declared by the service and runs a gRPC server to handle client calls. The gRPC infrastructure decodes incoming requests, executes service methods, and encodes service responses.
On the client side, the client has a local object known as stub (for some languages, the preferred term is client) that implements the same methods as the service. The client can then just call those methods on the local object, wrapping the parameters for the call in the appropriate protocol buffer message type - gRPC looks after sending the request(s) to the server and returning the server’s protocol buffer response(s).
In short, the surface is the contract between the client and the service and its realization as the clientside layer (the stub) and the serverside implementation.
Related
I am using grpc for client/server communication since it supports bidirectional streaming. I have read some doc relates to that: https://grpc.io/docs/what-is-grpc/introduction/
It supports:
A simple RPC where the client request to server to receive a response
A server-side streaming RPC where the client sends a request to the server and gets a stream to read a sequence of messages back.
A client-side streaming RPC where the client writes a sequence of messages and sends them to the server, again using a provided stream
I have a case that to let server to send a query request to client to receive a response. The bi-directional is only used in streaming case not request-response case.
I couldn't find any way to support that pattern. Is this supported by grpc?
The initiator of a request is by definition the client.
To address your need:
the code currently functioning only as a gRPC server must also implement a gRPC client; and
the code currently functioning only as a gRPC client must also implement a gRPC server.
When I use WCF's NETTCP binding endpoint address looks like: net.tcp://localhost:51111/MyService/.
When I use Websockets endpoint address looks like: ws://localhost:port/Esv/ocp and for secure connection wss://localhost:port/Esv/ocp.
Is there any common prefix for gRPC services? Or only 192.168.1.1:51111 is OK since called method is binded to GRPC server by:
ServerServiceDefinition.CreateBuilder().AddMethod(_myCommunicationMethodName, CallProcessingMehtod).Build();
In a grpc service, the URL of the underlying HTTP2 request is determined by the name of the of the service and the method name (as found in the .proto definition). Besides that, there is no "prefix" and using one would be against the recommendations in the gRPC wire protocol spec (more on that in github.com/grpc/grpc-dotnet/issues/110).
Note that under normal circumstances, you don't need to know the exact URL used by a gRPC method call as this is something that's encapsulated by the gRPC client and server logic.
I had read this answer: https://stackoverflow.com/a/56943771/6463558, it says that there is no way to run gRPC server and HTTP server at same address and port using grpc-node package.
But I can create gRPC server and HTTP server at same address and port(e.g. both using localhost:3000) using grpc-go package. Here is an example: https://github.com/mrdulin/grpc-go-cnode/blob/master/cmd/server/main.go#L79
So, why grpc-node and grpc-go behave inconsistently. Does this make sense?
The result I expect is that no matter what language is implemented in grpc, the behavior should be consistent. So the grpc server should be able to share the same port with the server created by Node's standard library http in same system process.
It is all about implementation. Each language has its own implementation for gRPC. There are many differences from each language implementation, some due to language capability but also due to the maintainers. Each project is a different project.
In this case, we can not really say that gRPC and HTTP servers are sharing the same address. There is only the HTTP server running. However, Golang implementation for gRPC server has an option to serv the gRPC through HTTP.
Calling
server.ServeHTTP()
instead of
server.Serve()
That is possible because, under the hood, gRPC server is built on top HTTP2
This snippet from the link you shared make what I said clear
if request.ProtoMajor != 2 {
mux.ServeHTTP(writer, request)
return
}
if strings.Contains(request.Header.Get("Content-Type"), "application/grpc") {
grpcServer.ServeHTTP(writer, request)
return
}
If you want to do the same in Node, you need to check in the grpc-node implementation if there is such a thing available
Your example uses http.NewServeMux(), which is provided by the Go standard library. The Node standard library does not provide an equivalent feature, so you can't share the port that way.
What is special about a remote procedure call?
From what I have seen so far, they seem to have similar functionalities as a HTTP API or TCP API. Why not just use a http/tcp api?
As a developer that wishes to open up an API, why would I choose to use JSON RPC over a HTTP or TCP API (with a JSON encoded payload)
RPC is a different type of architecture that predates REST - it is more focused on procedures while REST focuses on exposing resources with a consistent API.
RPCs are most often found in legacy code and in cases where REST may not be appropriate.
RPC protocol uses TCP as an underlying protocol and HTTP again uses TCP as an underlying protocol. So why is HTTP is widely accepted?
Why does SOAP use HTTP as an underlying protocol - why not RPC?
Remote Procedure Calls (RPC) is not a protocol, it's a principle that is also used in SOAP.
SOAP is an application protocol that uses HTTP for transport (so it won't have to think about encoding, message boundaries and so on). One of the reasons to use SOAP over HTTP is that for HTTP you usually don't need firewall rules and that the HTTP infrastructure is mature and commonly rolled out.
RPC does not require HTTP. Basically, RPC describes any mechanism that is suitable to invoke some piece of code remotely. The transport mechanism used to perform the RPC could be SOAP over HTTP. It could also be a REST call returning some JSON data over HTTP.
SOAP can also be used via Mails, and AFAIK (not sure here) the BizTalk Server should support this scenario. But even something exotical like trying SOAP over Avian Carriers can also be considered an RPC, although the latency of the latter may not be sufficient for real-world applications.
Think of an RPC as sending somehow some kind of message to a destination, in order to initiate a specific action and (optionally) getting some information back after the action has been completed. What prticular technology you choose to transmit these messages does not really matter.