Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently the
DgraphClient
class only exposes a constructor accepting gRPC channels, which will then be used to create the gRPC clients. These channels have to be manually mantained (lifetime, etc.) which may lead to misuses (e.g. gRPC channels should not be created for each new request but rather reused, see docs).Using the gRPC client factory integration is an alternative approach to outsource the maintenance of the channel respectively the client. To use this approach, the
DgraphClient
class must accept the gRPC client directly rather than channels.The current implementation does add the client from the constructor to the list of clients which are subject to the (currently not active) dispose logic. This should not be a problem, as the logic is currently inactive, but in the future this might be an issue, as the client's lifetime management should be managed by the client factory. I personally would also remove the inactive dispose logic and leave the channel lifetime management to the caller of the
DgraphClient
.