Download the PHP package spiral/grpc-client without Composer
On this page you can find all versions of the php package spiral/grpc-client. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download spiral/grpc-client
More information about spiral/grpc-client
Files in spiral/grpc-client
Package grpc-client
Short Description gRPC client
License MIT
Homepage https://spiral.dev
Informations about the package grpc-client
gRPC Client
The package provides powerful and convenient functionality for making client gRPC requests through a simple and extensible interface.
Installation
Note that the package requires gRPC extension to be installed.
Documentation
Public API
The package provides the following parts of the API:
- Integration classes for use with frameworks.
- Classes for convenient package configuration through DTOs.
- A set of basic interceptors.
- Several types of exceptions for error handling.
Integration
Spiral
[!NOTE] The
spiral/roadrunner-bridge
package includes thespiral/grpc-client
package by default since version4.0.0
and provides its integration and configuration flow.
Add the \Spiral\Grpc\Client\Bridge\GrpcClientBootloader
bootloader to the list of bootloaders
in the application configuration (usually it is Kernel.php
).
Other Frameworks
If you are using this package outside the Spiral framework,
you need to figure out how to use the \Spiral\Grpc\Client\ServiceClientProvider
provider
to get ready-to-use gRPC clients.
Configuration DTOs
Now let's consider a configuration example:
GrpcClientConfig
This class represents the configuration of the gRPC client in general. It includes a list of service configurations and a general list of interceptors that will be applied to all services.
Interceptors can be declared as class names, Spiral\Core\Container\Autowire
objects
(if custom constructor arguments need to be passed), or objects.
Note that some interceptors provide convenient methods for creating configurations.
ServiceConfig
This class represents the configuration of a specific service or a group of similar services but with different connection options.
The interfaces
parameter is a list of gRPC service interfaces that were generated by the protoc
utility
and that are implemented by the service.
[!NOTE] Currently, we support only service interfaces that are generated using the
protoc
utility with theprotoc-gen-php-grpc
plugin.
The configuration example above doesn't include the interceptors
parameter.
It's the same as in the general configuration, but it's applied only to the specified service.
This branch of interceptors is run via the ExecuteServiceInterceptors
interceptor.
So, it's important to include it if you want to use service-specific interceptors.
The connections
parameter is a list of connection configurations. You can specify multiple connections
to distribute the load between them or to provide fail-over.
Multi-connection orchestration strategy can be configured by interceptors,
for example, ConnectionsRotationInterceptor
.
ConnectionConfig
This class represents the configuration of a single connection to the gRPC service. It includes credentials and the service address. Use static methods to create connection configurations with different types of credentials.
Usage
After the integration and configuration are ready, you can get the client for the desired service interface from the container and call the service methods.
Interceptors
Important points when using interceptors in the long-running mode:
- Stateful: interceptors are recreated anew for each request, so you can safely store the state of each call.
- Scoped: interceptors are created in the same Container Scope in which the client is called. Accordingly, you can request contextual dependencies in the interceptor's constructor.
When writing your own interceptors, you will likely want to work with gRPC-specific fields
(options, metadata, input message, etc.).
Use the \Spiral\Grpc\Client\Interceptor\Helper
class to get or set the values of these context fields.
Order of Interceptors
Interceptors are executed in the order in which they are declared in the configuration. The order of the interceptors is important.
For example, if we have the following configuration:
SetTimeout(10 seconds)
Retry(maxAttempts: 3, interval: 2 seconds)
SetTimeout(3 seconds)
then we will have a 3-second timeout for each retry attempt.
We also have a 10-second timeout for all attempts in total, after which no new request attempts will be made.
This happens because the RetryInterceptor
takes into account previously configured timeouts.
Also, the placement of the ExecuteServiceInterceptors
interceptor,
which embeds the interceptors of the currently running service,
will affect the final sequence of interceptors.
All versions of grpc-client with dependencies
google/common-protos Version ^1.3 || ^2.0 || ^3.0 || ^4.0
google/protobuf Version ^3 || ^4
grpc/grpc Version ^1.57
psr/container Version ^2.0
spiral/core Version ^3.14
spiral/hmvc Version ^3.14
spiral/tokenizer Version ^3.13