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

Add a synchronous grpc client #647

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

leonardgerardatomicmachinescom
Copy link

@leonardgerardatomicmachinescom leonardgerardatomicmachinescom commented Nov 21, 2024

Summary

I find that often, we want a non async grpc client. This PR adds a *SyncStub generated class using only the standard synchronous grpc library. It is pretty much exactly the same as the *Stub one except it is synchronous.

I have not tested it extensively yet, but the code is pretty straightforward.

Let me know what you think and I can tweak/test more. Also you might not want something like this or would want it to be an option/extra instead of always generating it.

Checklist

  • If code changes were made then they have been tested.
    • I have updated the documentation to reflect the changes.
  • This PR fixes an issue.
  • This PR adds something new (e.g. new method or parameters).
    • This change has an associated test.
  • This PR is a breaking change (e.g. methods or parameters removed/renamed)
  • This PR is not a code change (e.g. documentation, README, ...)

@@ -160,9 +227,9 @@ class {{ service.py_name }}Base(ServiceBase):
, {{ method.py_input_message_param }}: "{{ method.py_input_message_type }}"
{%- else -%}
{# Client streaming: need a request iterator instead #}
, {{ method.py_input_message_param }}_iterator: {{ output_file.typing_compiler.async_iterator(method.py_input_message_type) }}
, {{ method.py_input_message_param }}_iterator: "{{ output_file.typing_compiler.async_iterator(method.py_input_message_type) }}"

Choose a reason for hiding this comment

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

This and the next diff are in fact fixes for the existing stub generation. If wanted I could split it into a separate PR.

we are going to mock the channel and simply test the client.

If we wanted to test without mocking we would need to use all the machinery here:
https://github.com/grpc/grpc/blob/master/src/python/grpcio_tests/tests/testing/_client_test.py

Choose a reason for hiding this comment

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

Or I could spawn an actual server. I would think that's the best testing, but it is not done so in the rest of the code (which uses the nice grpclib ChannelFor)

DoThingResponse,
GetThingRequest,
GetThingResponse,
TestSyncStub as ThingServiceClient,

Choose a reason for hiding this comment

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

This is the new synchronous stub.

@AdrienVannson
Copy link
Contributor

Hello, and thank you for the work! I agree that it would be a great idea to support this. However, I wouldn't merge the PR as it is now: indeed, I would say that adding an option to allow the user to choose between sync and async right at the beginning would be better. Plus, it should be possible to avoid duplicating all the template code.

Then, this should be integrated in the github action so that these implementations are tested too... So it is not a small change.

However, before starting working on that, I would like first to simplify the current implementation, since it will have an impact on the template file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants