Yar PHP RPC: installation, concurrent calls, and operational limits

Yar's native extension model for internal PHP services

Yar addresses communication between PHP applications that need an RPC interface without adding a userland framework or a separate proxy process. The primary implementation is a native PHP extension written largely in C, with a PHP stub and supporting modules for requests, responses, transports, packaging, protocol handling, and exceptions. Based on the repository layout, these responsibilities remain in the extension rather than in Composer-managed application code.

The intended users are teams operating internal services or microservices within one infrastructure. The README also points to separate implementations for C, Java, and Lua, so the protocol is not limited to a PHP-only deployment. That interoperability is distinct from a general public API ecosystem. The README says to use REST or gRPC with Protobuf for public APIs, arbitrary third-party clients, service discovery, load balancing, or streaming.

This design reduces the amount of application-level RPC machinery, but it also places protocol compatibility between the extension and its peers. A deployment must use a compatible Yar implementation and a packager understood by both sides. There is no claim in the README that Yar generates client stubs from schemas or coordinates service placement. Those missing layers are design boundaries, not features hidden behind configuration.

How Yar frames calls and waits for concurrent responses

The README describes Yar's wire format as a compact binary protocol made from `yar_header_t` followed by a packager payload. That separation is central to the design. The header carries protocol-level information, while the selected packager represents the call body and response data. Yar includes `php`, `json`, and optionally `msgpack` as data packagers. The transport layer separately carries the framed exchange over HTTP, HTTPS, or TCP.

Concurrent calls are the reason to consider Yar when several independent remote operations would otherwise block one another. `Yar_Concurrent_Client` appears in the epoll discussion, and the client API documentation lists options for packagers, persistent connections, timeouts, headers, proxies, resolution, providers, and tokens. The README excerpt does not show the complete concurrent-client call syntax, so this review does not invent an invocation or callback sequence.

The implementation separates client, server, request, response, protocol, packager, and transport components. That separation maps directly to the exception hierarchy. A client can distinguish `Yar_Client_Transport_Exception`, `Yar_Client_Protocol_Exception`, and `Yar_Client_Packager_Exception`, allowing failure handling to identify the layer involved. One documentation defect is worth noting: `Yar_Client_Exception::getType()` returns the class name string `Yar_Exception_Client`, not one of the numeric error constants. Code that needs the actual client failure category must catch the specific subclass rather than infer it from the base method.

Installing Yar through PECL and from source

The simplest documented installation path is PECL. This installs the native extension into the PHP environment, so the extension must also be enabled through the PHP installation's normal extension configuration. The README does not include the `php.ini` directive for enabling it, so there is no justified directive to add here.

For systems where the packaged release is unsuitable, the documented source build uses `phpize`, `configure`, `make`, and `make install`:

$ pecl install yar

PECL should report completion for the `yar` package. After that, confirm that the extension appears in the target PHP installation and that `YAR_VERSION` is available.

The source path is:

$ /path/to/phpize
$ ./configure --with-php-config=/path/to/php-config/
$ make && make install

Replace neither path with an assumption about the reader's system. The command configures the extension against the selected PHP installation and builds it. The README does not document restarting PHP or rebuilding an SAPI service after `make install`, although the extension must be loaded by the intended runtime for its classes and constants to become available.

The documented configure choices include:

--with-curl=DIR
--enable-msgpack / --disable-msgpack
--enable-epoll / --disable-epoll

`--enable-epoll` replaces the default `select()`-based multiplexing on Linux and affects `Yar_Concurrent_Client`. It has no effect on other platforms. This option is documented as requiring Yar 2.1.2 or later.

A first Yar HTTP service and its visibility boundary

The README's first concrete service example registers a PHP object with `Yar_Server` and lets the server handle an incoming request:

<?php
class API
{
    public function some_method($parameter, $option = "foo")
    {
    }

    protected function client_can_not_see()
    {
    }
}

$service = new Yar_Server(new API());
$service->handle();

Place this code in an endpoint reachable through the web server used by the Yar client. The README does not give a router command or deployment recipe, so it does not establish whether the file should be run through PHP's built-in server, Apache, nginx, or another SAPI. Usual RPC calls arrive as HTTP POST requests, according to the README.

The class comment in the example says that `@params` and `@return` are used to generate service information. The protected `client_can_not_see()` method provides the visibility example, but the README does not explain every visibility rule or show an actual remote call. The empty method body also gives no business response to inspect. As a result, this is the documented service registration point, not a complete end-to-end request example.

GET requests are a separate concern. With `yar.expose_info` set to `On` by default, the server can output an API information page. For internal deployments where service metadata should not be exposed, that setting can be disabled. The README does not document authentication for ordinary RPC calls, although `YAR_OPT_TOKEN` exists as a client option and forbidden errors cover authentication failure or a disabled info page.

Packagers, timeouts, TLS verification, and diagnostic settings

The wire format separates the `yar_header_t` header from a serialized payload, which makes the packager a deployment decision rather than merely a coding preference. The default is `php`; `json` is also built in, while `msgpack` requires a build with msgpack support. Enabling it has an additional dependency path:

$ pecl install msgpack

Then configure Yar with msgpack enabled:

$ /path/to/phpize
$ ./configure --with-php-config=/path/to/php-config/ --enable-msgpack
$ make && make install

Readers can check whether the build supports it through `YAR_HAS_MSGPACK`, documented as `1` when compiled with `--enable-msgpack` and `0` otherwise.

Two timeout settings control different stages. `yar.timeout` defaults to 5000 milliseconds, and `yar.connect_timeout` defaults to 1000 milliseconds. Versions before 1.2.1 measured the connection timeout in seconds, so copied configuration from an old deployment can behave differently.

Security-sensitive configuration deserves attention. Since 2.4.0, `yar.ssl_verify` controls certificate verification. It defaults to `Off` for backward compatibility. When enabled, the curl transport sets both `CURLOPT_SSL_VERIFYPEER` and `CURLOPT_SSL_VERIFYHOST`, and invalid certificates cause requests to fail. That default is a concrete adoption risk for HTTPS service calls because an unverified TLS connection is not equivalent to certificate validation.

`yar.debug` defaults to `Off`. Enabling it causes Yar to emit `E_WARNING` messages with timestamped request and response details prefixed by `[Debug Yar_Server]` or `[Debug Yar_Client]`. That visibility may help during integration, but warning emission can also make logs noisy and expose operational details.

Yar versus gRPC, REST, and conventional PHP extension work

Yar is most different from a conventional Composer library because it is compiled into PHP. There are no Composer packages, framework bootstrap steps, or separate proxy processes in the described deployment model. The tradeoff is environmental: installation depends on the native extension toolchain or PECL, and behavior depends on how the target PHP runtime loads the compiled module.

Compared with gRPC using Protobuf, Yar offers a compact custom protocol, HTTP and TCP transport choices, and concurrent calls without schema-driven code generation in the documented setup. gRPC is the README's alternative when requirements include streaming or built-in service discovery and load balancing. The README does not claim that gRPC lacks schema-driven code generation, only that Yar is not the preferred choice when schema-driven generation matters.

Compared with REST, Yar sends binary encoded RPC calls to registered object methods rather than designing a public HTTP resource interface for arbitrary clients. REST remains the README's recommendation for public-facing APIs. Yar also differs from JSON APIs through its `yar_header_t` framing and pluggable packagers, even though it can carry JSON payloads.

Yar should not be treated as a complete service platform. The feature list does not include service discovery, load balancing, or streaming. It also does not document rolling protocol upgrades across heterogeneous peer implementations. Those boundaries may be acceptable inside a controlled PHP estate, but they shift coordination work to the adopter.

Maintenance signals, custom licensing, and upgrade checks

The repository is not archived, and the last push was on 2026-09-23. The latest listed release is `yar-2.4.0`, dated 2026-08-06. Those are the maintenance facts recorded for the repository. This review does not infer release cadence, compatibility coverage, or issue response quality from counts or badges.

Upgrade work has several project-specific dimensions. First, the default branch requires PHP 7.0 or later, while a separate `php5` branch covers PHP 5.2 and later. Second, changing `yar.packager` to `msgpack` affects both runtime configuration and build requirements. Third, timeout units must be checked when adopting configuration written for releases before 1.2.1. Fourth, `yar.ssl_verify` is available since 2.4.0, so it cannot be assumed to exist in older deployments.

The repository identifies its license as a custom license that GitHub cannot classify. The README does not summarize the permissions, conditions, redistribution rules, or patent clauses in the `LICENSE` file. Consequently, no conclusion can be drawn here about whether a particular commercial deployment, modification, or redistribution is permitted. License compatibility with other Yar implementations must also be checked separately, since this PHP repository's classification does not establish the terms of the linked C, Java, or Lua projects.

The repository includes `package.xml`, native platform files, tests, and separate packager and transport directories. That layout supports source builds across systems, but it does not prove deployment readiness on every PHP or operating-system combination. The documented Linux and Windows workflow links indicate build paths exist, while the explicit epoll caveat keeps the performance-related option Linux-specific.

Editorial conclusion

Adopt Yar when the calling and serving applications can agree on its binary protocol and when concurrent internal calls matter more than generated interfaces or built-in traffic management. Do not choose it as a replacement for REST, Protobuf-based gRPC, or platforms whose requirements include streaming and built-in load balancing. Before adoption, verify the custom LICENSE permissions, confirm that the selected packager is available in the build, and test timeout and TLS behavior against the deployment network.

Frequently asked questions

Official sources

1. Issues
2. laruence/yar on GitHub
3. Project website
4. README
5. Releases