gRPC proto-loader options are global to the server rather than per-package #12560
Open
3 of 15 tasks
Labels
needs triage
This issue has not been looked into
Is there an existing issue for this?
Current behavior
We currently use a global
GrpcOptions
object to create a gRPC server which includes proto-loader configuration in theGrpcOptions.options.loader
field. This is a departure from howgrpc-js
works in which you would normally:PackageDefinition
from the proto files by loading it viaproto-loader
PackageDefinition
into aProtoDescriptor
usinggrpc-js
and add that into the serverBy attaching the proto-loader configuration to the server instead of the package definition we lose some flexibility in how people configure their implementation logic. Particularly, this becomes an issue when attempting to use shared modules for common logic (eg. grpc-health-check, reflection-api)
Because the common logic is being loaded into someone else's configuration it has no control over settings which may be important to the implementation. Specifically: defaults for missing fields can be different based on that configuration, while the
keepCase
option can change entire field namesMinimum reproduction code
https://gitlab.com/jtimmons/nestjs-grpc-reflection-module/-/commits/temp/remove-req-res-conversion
Steps to reproduce
The linked reproduction is to a library that I maintain (nestjs-grpc-reflection-module) where I've had to work around this behavior. The linked branch disables that workaround behavior so that you can demonstrate it in the repo's sample server.
To reproduce:
npm i && npm run start:dev
keepCase
on/off in the sample server's grpc-client optionskeepCase
is set totrue
The reflection module code is written to expect the default
keepCase
option offalse
and so, with the workaround logic disabled, will break whenkeepCase
is set totrue
. This is because it will receive messages with field names such aslist_services
when the code itself is trying to access that field as the camel-cased name oflistServices
Expected behavior
I would expect that we would be able to control the proto-loader configuration per module somehow
Package
@nestjs/common
@nestjs/core
@nestjs/microservices
@nestjs/platform-express
@nestjs/platform-fastify
@nestjs/platform-socket.io
@nestjs/platform-ws
@nestjs/testing
@nestjs/websockets
Other package
No response
NestJS version
10.2.6
Packages versions
Node.js version
v20.8.0
In which operating systems have you tested?
Other
PR #10530 doesn't directly fix this but may offer a good path forward? If a module could add a full
PackageDefinition
to the list of services to add to a gRPC server then it could solve the problem somewhatThe text was updated successfully, but these errors were encountered: