Document updated on Mar 18, 2024
gRPC Server
The gRPC server integration allows you to expose an additional gRPC service under the same HTTP port. The gRPC service can consume data from mixed upstream services, whether they are also gRPC, HTTP, Lambdas, queues, or any other supported type.
Due to its nature, when you access the gateway through gRPC, you cannot use HTTP components in the user request (but you can work with the HTTP layer when connecting to your services). With this in mind, HTTP-specific components like CORS or HTTP Security aren’t loaded in this context.
gRPC server configuration
To configure a gRPC server, you must define the services available and which methods you want to offer. The services and methods are defined in the catalog definition, and in the services section, you decide which ones to expose and where to connect them.
Each method is connected to one or more backends, which do not need to be gRPC.
The example below reads Protobuff definitions from the local folder ./grpc/definitions and decides to expose the method FindFlight service that belongs to the flight_finder.Flights service:
{
"version": 3,
"grpc": {
"catalog": [
"./grpc/definitions"
],
"server": {
"services": [
{
"name": "flight_finder.Flights",
"methods": [
{
"name": "FindFlight",
"input_headers": [
"*"
],
"payload_params": {
"page.cursor": "cursor"
},
"backend": [
{
"host": [
"example.com:4242"
],
"url_pattern": "/flight_finder.Flights/FindFlight",
"extra_config": {
"backend/grpc": {
"use_request_body": true
}
}
},
{
"method": "GET",
"host": [
"http://example.com:8000"
],
"url_pattern": "/articles.json?q={cursor}"
}
]
}
]
}
]
}
}
}
As you can see in the example above, this gRPC server fetches content from one HTTP service and one gRPC service (the flight finder). The upstream gRPC service uses a gRPC Client configuration.
The accepted parameters are as follows:
Fields of gRPC integration
catalog* array- The paths to the different
.pbfiles you want to load, or the paths to directories containing.pbfiles. All content is scanned in the order of the list, and after fetching all files it resolves the dependencies of their imports. The order you use here is not important to resolve imports, but it matters when there are conflicts (different files using the same namespace and package type).Examples:"./grpc/flights.pb","./grpc/definitions","/etc/krakend/grpc" serverobject- Defines the gRPC server properties.
opentelemetryobject- Overrides OpenTelemetry settings for the gRPC server.
disable_metricsboolean- Whether you want to disable all metrics happening in the gRPC server.Defaults to
false disable_tracesboolean- Whether you want to disable all traces happening in the gRPC server.Defaults to
false
servicesarray- Defines one object per available gRPC service.Each item is an object with the following properties:
methodsarray- The gRPC methods available for this service (this is not related with HTTP methods despite using the same name).Each item is an object with the following properties:
backendarray- An array with all the backend objects mapped to this method
input_headersarray- Defines the list of all client headers that you can use as gRPC metadata.
By default, KrakenD won’t pass any header from the client to the backend. This list is case-insensitive. You can declare headers in lowercase, uppercase, or mixed.
An entry["X-Something"]forwards a singleX-Somethingheader to the backend, ignoring everything else. A single star element["*"]as value forwards everything to the backend (it’s safer to avoid this option).Examples:"X-Custom-Trace","*"Defaults to[] namestring- The name of the published gRPC method.Example:
"FindFlight" payload_paramsobject- Maps a property of the gRPC incoming payload to a
{parameter}that you can inject and reuse in aurl_pattern. It supports dot nation to access nested objects.Example:{"some.grpc.object":"param1"}
namestring- The name of the published gRPC service.Example:
"flight_finder.Flights"
