Enterprise Documentation
gRPC Server
Document updated on Mar 18, 2024
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 server
| The paths to the different .pb files you want to load, or the paths to directories containing .pb files. 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" | ||||||||||||||||||||||||
| Defines the gRPC server properties.
|
gRPC server authorization
If your gRPC server requires authenticated users using JWT, then you need to add the information to the gRPC server under the extra_config of the method, exactly as you do for JWT validation in endpoints.
Here is an example, notide the placement of the auth/validator namespace:
{
"version": 3,
"grpc": {
"catalog": [
"./grpc/definitions"
],
"server": {
"services": [
{
"name": "flight_finder.Flights",
"methods": [
{
"name": "FindFlight",
"input_headers": [
"*"
],
"extra_config": {
"auth/validator": {
"alg": "RS256",
"audience": [
"http://api.example.com"
],
"roles_key": "http://api.example.com/custom/roles",
"roles": [
"user",
"admin"
],
"jwk_url": "https://identity.example.com/.well-known/jwks.json",
"cache": true
}
},
"payload_params": {
"page.cursor": "cursor"
},
"backend": [
{
"host": [
"example.com:4242"
],
"url_pattern": "/flight_finder.Flights/FindFlight",
"extra_config": {
"backend/grpc": {
"use_request_body": true
}
}
}
]
}
]
}
]
}
}
}
