github.com/tickoalcantara12/micro/v3@v3.0.0-20221007104245-9d75b9bcbab9/docs/v2/design/framework/grpc.md (about)

     1  # GRPC Support
     2  
     3  Many people want gRPC support by default in micro. We need to identify what this means and the best way to address it.
     4  
     5  ## Overview
     6  
     7  GRPC is a generic RPC framework on top of http/2. It can be considered both a framework and a protocol. GRPC Go the framework 
     8  tightly couples the transport protocol inside its framework. This doesn't fit inline with micro where we decouple the 
     9  client/server from the transport. Finding a point of integration has been largely difficult. 
    10  
    11  The industry trend is towards gRPC for cloud-native infrastructure and backend services. We've supported gRPC as client/server 
    12  which ignores our transport but also separately with a transport with a fix RPC interface. We however do not interop with 
    13  the gRPC framework and this is something people seem to want e.g including gRPC interceptors and supporting the gRPC 
    14  server signature, protobuf code generation, etc.
    15  
    16  The expectation is that because we use proto IDL code generation, protobuf and RPC that we should interop with gRPC but 
    17  as we move away from proto this becomes less relevant. Our reasons for moving away are because we need something that 
    18  more cleanly defines our interfaces including the pubsub interface and also defines services in a better way.
    19  
    20  If this is the case our support of gRPC should be limited to a transport.
    21  
    22  ## Client/Server
    23  
    24  Our [client](https://github.com/micro/go-plugins/tree/master/client/grpc) and [server](https://github.com/micro/go-plugins/tree/master/server/grpc) 
    25  implementations can be found here respectively.
    26  
    27  The client/server leverages the gRPC-go framework beneath the covers and ignores our own transport interface. It however does not provide 
    28  the user access to gRPC framework related tooling as we still have our own interfaces. It also requires dual maintenance of our own 
    29  rpc client/server and the gRPC implementations.
    30  
    31  <img src="https://micro.dev/docs/images/go-grpc.svg" />
    32  
    33  There is some merit to saying those who want to use the gRPC framework should use it directly.
    34  
    35  ## Transport
    36  
    37  Our [transport](https://github.com/micro/go-plugins/tree/master/transport/grpc) implementation can be found here.
    38  
    39  The transport has a fixed interface:
    40  
    41  ```
    42  syntax = "proto3";
    43  
    44  package go.micro.grpc.transport;
    45  
    46  service Transport {
    47  	rpc Stream(stream Message) returns (stream Message) {}
    48  }
    49  
    50  message Message {
    51  	map<string, string> header = 1;
    52  	bytes body = 2;
    53  }
    54  ```
    55  
    56  This enables us to leverage the grpc protocol and leverage its performance but does not cater to the needs of users who appear to want 
    57  interop with other gRPC services and visibility into what their services are calling from the gRPC tooling standpoint. It is however 
    58  for all intents and purposes, a transport.
    59  
    60  ## Goals
    61  
    62  - Determine the best way to leverage the gRPC protocol
    63  - Identify the best route forward for gRPC framework interop
    64  - Find the simplest path forward for maintainence 
    65  - Decide whether we should drop our own protocol for this