Support naming a virtual channel#491
Merged
sleipnir merged 4 commits intoelixir-grpc:masterfrom Jan 28, 2026
Merged
Conversation
sleipnir
reviewed
Jan 23, 2026
Collaborator
There was a problem hiding this comment.
Overall, I thinik this is cool.
But if we're going to do this (expose named channels), maybe it would be better to use a Registry and allow managing multiple channels.
WDYT @polvalente ?
Contributor
Author
I have no strong opinions on an implementation as you are much closer to the the project than I am. This PR was more to exemplify the desired feature. |
polvalente
reviewed
Jan 25, 2026
polvalente
reviewed
Jan 25, 2026
e0c7bd1 to
31967e7
Compare
polvalente
reviewed
Jan 28, 2026
polvalente
approved these changes
Jan 28, 2026
Allow a GRPC.Channel to be created with a name. This removes the need for developers to store the `Channel` that's returned from `GRPC.Client.Connection.connect`.
Co-authored-by: Paulo Valente <16843419+polvalente@users.noreply.github.com>
c238490 to
282555c
Compare
sleipnir
approved these changes
Jan 28, 2026
Collaborator
|
Thank you @mrmicahcooper! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Allow a GRPC.Channel to be created with a name.
This removes the need for developers to store the
Channelthat's returned fromGRPC.Client.Connection.connect.This is one attempt to solve the feedback I previously mentioned in a separate issue:
#464 (comment)
I'll explain how I do things now and what this PR is attempting to do:
Current
I have an elixir app that talks to a GRPC endpoint.
So I say
{:ok, channel} = GRPC.Stub.connect("https://grpc.endpoint.com")Now, I need to hold on to this channel somewhere so I can use it later so I create a GenServer with this channel in its state.
Now I call the GenServer which uses the channel in its state to forward the request to the GRPC stub.
Something like
HelloWorld.Stub.say_hello(channel, "hello")This works and has the ability to ensure the GRPC.Client.Supervisor is started before we start this GenServer starts.
The downside is now I have to have an entire process just to store a virtual channel.
Proposed
Use a module attribute to store the name of the channel I want.
@endpoint_channel :my_service_channelNow create a channel with that name and ignore the response:
{:ok, _channel} = GRPC.Client.Connection.connect("https://grpc.endpoint.com", name: @enpdoint_channel)When I want to use that channel, I use the predetermined name:
Something like
HelloWorld.Stub.say_hello(%Channel{ref: @endpoint_channel}), "hello")Now I don't need to store that channel anywhere.
This PR implements the "proposed" and ignores the fact that you'd have to manually create this connection somewhere in your app after the
GRPC.Client.Supervisoris started.Something that might be cool is the ability to create these named channels in
config.But this PR seems like a really low risk way add this feature.
I'd love any feedback or thoughts about a different approach.
Thanks!