Download the PHP package spiral/grpc-client without Composer

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 the spiral/grpc-client package by default since version 4.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).

Standalone Usage

The GrpcClient class provides a lightweight, Guzzle-like API for making gRPC calls without any framework or DI container:

Add interceptors using the convenient createConfig() factories:

Multiple connections for failover:

ConnectionConfig for TLS:

With a factory (e.g. Spiral's container) to resolve class-string interceptors via DI:

The with* methods are immutable — each returns a new instance, so you can safely derive pre-configured clients:

[!NOTE] GrpcClient does not support per-service interceptors. If you need that, use ServiceClientProvider with the full GrpcClientConfig / ExecuteServiceInterceptors setup.

Other Frameworks

If you are using this package with another framework, you can use \Spiral\Grpc\Client\ServiceClientProvider with a GrpcClientConfig to get ready-to-use gRPC clients, or use the standalone GrpcClient described above.

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 the protoc-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.

To create a secure connection, use the TlsConfig class.

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:

1. SetTimeout(10 seconds)
2. Retry(maxAttempts: 3, interval: 2 seconds)
3. 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.