Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix grpc channel options #8365

Merged
merged 5 commits into from Nov 8, 2021

Conversation

sjkummer
Copy link
Contributor

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Other... Please describe:

What is the current vs. new behavior?

The GrpcOptions attribute "channelOptions" was not used anymore (never read in the code). Therefore, declaring those ChannelOptions had no effect anymore and there was no way to configure specific gRPC settings & limits.

I fixed that and also extended ChannelOptions with grpc-node.max_session_memory which is required when sending big messages (see grpc/grpc-node#1666).

Ensured backward compatibility by including size limits like grpc.max_send_message_length to the ChannelOptions

Does this PR introduce a breaking change?

  • Yes
  • No

…r read in the code). Therefore, declaring those ChannelOptions had no effect anymore and there was no way to configure specific gRPC settings & limits.

Also extended ChannelOptions with grpc-node.max_session_memory which is required when sending big messages (see grpc/grpc-node#1666).

Ensured backward compatibility by including size limits like grpc.max_send_message_length to the ChannelOptions
Removed GRPC_DEFAULT_MAX_RECEIVE_MESSAGE_LENGTH and GRPC_DEFAULT_MAX_SEND_MESSAGE_LENGTH constants. This default values are already the same in the underlying gRPC library. If the gRPC team decides to change that values in the future, nestjs should adopt the new values automatically.
@@ -14,6 +12,7 @@ import { InvalidProtoDefinitionException } from '../errors/invalid-proto-definit
import { ClientGrpc, GrpcOptions } from '../interfaces';
import { ClientProxy } from './client-proxy';
import { GRPC_CANCELLED } from './constants';
import {ChannelOptions} from "../external/grpc-options.interface";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please run prettier npm run format.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

export const GRPC_DEFAULT_MAX_RECEIVE_MESSAGE_LENGTH = 4 * 1024 * 1024;
export const GRPC_DEFAULT_MAX_SEND_MESSAGE_LENGTH = 4 * 1024 * 1024;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is worth returning these default values and using them when the developer didn't provide them explicitly in the options.

Copy link
Contributor Author

@sjkummer sjkummer Oct 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4 MB is the current gRPC default, therefore nothing changes for developers who did not set a value. Why redeclare? And if the gRPC default changes (for reasons) in the futurore, why would nestJS want to stick to outdated default values?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha then yep it makes sense to remove these options.

@Ayzrian
Copy link
Contributor

Ayzrian commented Oct 27, 2021

Also, commit messages don't follow project conventions, please read the guideline https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md

@sjkummer
Copy link
Contributor Author

How crucial ist the commit message format for you guys? It's a bit nasty to change them afterwards.

However, this issue made us downgrade to nestjs 7, and I believe anyone else who uses nestjs with gRPC in production needs to do so as well.

My problem with the current situation is:

  • Since nestjs uses one repo for multiple npm packages we cannot easily switch to a fork, because using the git: URL scheme will not work for nestjs in package.json (this would require a separate repo for each nestjs npm module with a package.json in the root folder).
  • Adding the nestjs repo as submodule and using the file: URL scheme for subdirectories/packages did not work either ... probably due to lack of documentation how nestjs should be build. Can you give some advice?
  • For the reasons above, we (and proboably anyone else who uses nestjs in production) is somehow dependent from the nestjs core to merge & release crusial fixes quickly. Publishing forked nestjs-packages on npm is probably something that nobody wants (neither the nestjs team nor the developers who use nestjs).

Can you give some advice how that dependency can be decoupled?

@kamilmysliwiec
Copy link
Member

How crucial ist the commit message format for you guys? It's a bit nasty to change them afterwards.

Not a big deal, feel free to ignore it.

I'll look into this PR as soon as I can.

@kamilmysliwiec kamilmysliwiec merged commit 4bf2fd4 into nestjs:master Nov 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants