Skip to content

v1.2.0

Latest
Latest

Choose a tag to compare

View all tags
@github-actions github-actions released this 27 Oct 13:29
v1.2.0
46912a7
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

gRPCClient v1.2.0

Diff since v1.1.2

gRPCClient.jl 1.2.0 introduces a new and improved API. Each service is now generated as a module of RPC functions called on a reusable gRPCChannel, which gives typed signatures, per-RPC docstrings, and better IDE support. It is the recommended interface for new code. The legacy API is still supported and has not changed.

The new interface was designed and implemented by @johroj (#128, #139, #134), following the discussion in #122. Thank you!

New features

  • Module-per-service API. Code generation now emits a module for each service, with one function per RPC called on a reusable gRPCChannel (now exported). All RPC kinds are supported: synchronous and asynchronous unary, client streaming, server streaming and bidirectional streaming. Asynchronous and streaming calls return handles that support put!, take!, fetch, isready, wait, close and detach, plus iterate for consuming a response stream of unknown length. Raw Vector{UInt8} requests and responses work with the new interface just as they do with the legacy one. (#128, #139, @johroj)
  • Codegen controls. grpc_register_service_codegen(; legacy = true, servicemodule = true) selects which APIs are generated. Both are on by default. For new applications legacy = false is recommended: it generates less code and gives better IDE suggestions. When both are on, the generated file contains a version guard so it still loads, using the legacy API, on older versions of gRPCClient.jl. (#128, @johroj)
  • Generated RPCs get docstrings and type-annotated signatures. (#128, @johroj)

Bug fixes

  • A request submitted to a handle that is shut down or not initialized, or a request queued for a max_streams slot when the handle shuts down, now raises UNAVAILABLE instead of FAILED_PRECONDITION. A shut-down handle is usually being reset, so the call is retryable, and UNAVAILABLE is the code grpc-java uses for calls on a shut-down channel. (#147)

This is the first of what may be several corrections to make the status codes gRPCClient.jl assigns consistent with other gRPC clients. Further corrections may ship in future minor releases but will not change within patch releases. Do not depend on specific status codes beyond whether a call succeeded (OK) or failed. See the warning on the Error Handling page of the docs. (#149)

Notes

  • The documentation has been rewritten for the new API and reorganized into a multi-page site with a landing page. (#134 by @johroj, #150)

Merged pull requests:

Contributors

csvance and johroj
Assets 2
Loading