Socket Client Laravel Package

Technical Evaluation

Verdict up front: do not adopt. react/socket-client is explicitly marked [Legacy] by its maintainers. The functionality was merged into react/socket (the React\Socket\Connector class), and this repository exists for backward compatibility only. Last release was 2017-04-02, with zero dependents on Packagist and a low opportunity score — both signals that the ecosystem has already moved on and nobody is validating this code path in production.

Architecture fit. Poor. The package is a low-level, event-loop-driven TCP/TLS connection factory providing connect() returning a promise. Laravel is a synchronous, share-nothing, request-per-process framework; there is no ambient event loop in a standard FPM/nginx deployment. Consuming this package requires also pulling in react/event-loop and running inside a long-lived process (a custom Artisan worker, or alongside Octane). That is an architectural commitment far larger than "add a TCP client," and it should be a deliberate platform decision, not a package-level one.

Integration feasibility. Mechanically trivial (composer require), operationally awkward. The realistic uses in a Laravel context are outbound connections to a legacy plaintext/TLS line-protocol service, or building a small async proxy/relay worker. If the requirement is "talk to a third-party TCP endpoint a few times per request," stream_socket_client() with a configured timeout covers it with zero dependencies. If the requirement is genuinely high-concurrency outbound I/O, the correct artifact is react/socket ^1.x, not this legacy shim.

Technical risk — high.

• Abandoned codebase. No releases in ~8 years; no security response process. Any CVE in the TLS/stream handling will not be patched by the maintainers. You would be forking to fix it.
• PHP 8.x compatibility is unverified. The 2017 release predates PHP 8's stricter type and deprecation behavior; relying on it means owning that surface yourself.
• TLS correctness. Certificate verification, SNI, and default context options were the source of historical bugs in this component. A misconfigured Connector that silently disables peer verification is a realistic and serious failure mode.
• Single-threaded event loop. One blocking call (DNS resolution, a stray sleep, a synchronous Eloquent query inside a promise callback) starves the entire loop. This is a subtle, high-severity class of bug that code review catches poorly.
• Zero dependents means no canary population. You will find the bugs.

Key questions to resolve before any build decision.

1. What is the actual requirement — an outbound TCP/TLS client, an inbound listener, or a persistent worker?
2. What is the concurrency target? If it is under ~50 connections, a synchronous client is simpler and safer.
3. Where does this run — FPM request lifecycle, an Artisan daemon under Supervisor, or Octane? (Octane's default servers are Swoole/RoadRunner/FrankenPHP; ReactPHP is not the runtime, so you would be running a second loop alongside it.)
4. Is there a compliant alternative at the protocol layer — an HTTP wrapper, a queue, or a managed connector?
5. Who owns the fork if a CVE lands?

Integration Approach

Stack fit. ReactPHP is a coherent ecosystem, but it is a parallel runtime, not a Laravel extension. Adopting it means adopting an execution model: bootstrapping Loop::get(), keeping the process alive, and never blocking. Laravel's HTTP kernel, Eloquent, and most first-party packages assume the opposite. Fit is therefore conditional — acceptable only in a dedicated worker process, unacceptable inside web requests.

Recommended path. Do not install react/socket-client. If async outbound TCP/TLS is confirmed as a real requirement, install react/socket ^1.x (which ships React\Socket\Connector plus TcpConnector, TlsConnector, DnsConnector, TimeoutConnector — the composable set this legacy package predates) and react/event-loop.

Migration path for anyone already on it.

1. composer remove react/socket-client
2. composer require react/socket:^1.0
3. Replace React\SocketClient\Connector construction with new React\Socket\Connector([...]); the connect($uri) promise contract is preserved.
4. Re-run the TLS test suite against a real endpoint with verify_peer => true.

Compatibility notes. react/socket 1.x requires PHP 7.1+ and is actively maintained with PHP 8.x support. This is the single strongest argument for the swap: you inherit ongoing security maintenance instead of a 2017 snapshot.

Sequencing.

1. Spike (1–2 days): prove the requirement against a synchronous stream_socket_client baseline. Measure the concurrency needed. If synchronous suffices, stop here — this is the outcome in most cases.
2. Dependency audit: if async is mandated, run a Composer audit and a license/abandonment check on react/socket and react/event-loop.
3. Isolation: wrap the client behind an internal interface (TcpClientContract::send(string $payload): string) so the implementation is swappable and the async boundary is confined to one adapter. Application code must never see a promise.
4. Worker scaffolding: a dedicated php artisan tcp:worker command under Supervisor/systemd, with graceful shutdown on SIGTERM and loop-level error handling.
5. Observability: structured logging on connect/close/error, connection-duration metrics, and an explicit timeout budget per operation.
6. Rollout: feature-flagged, shadow traffic against the legacy path before cutover.

Operational Impact

Maintenance. Owning this package means owning an unmaintained dependency. Expect to pin the version indefinitely and to fork if a fix is needed. Budget for a quarterly review of whether the async need still exists — requirements that justify an event loop tend to erode once a queue or a managed connector becomes available.

Support. Community-only, and thin: 105 stars and no recent activity means issues and Stack Overflow answers will be sparse. Internal expertise must be built, not hired. Contrast with react/socket, which has an active maintainer and a documented connector API.

Scaling. The event loop is single-threaded; vertical scaling is the only lever within a process. Horizontal scale means multiple worker processes behind Supervisor, each holding its own loop and connection pool. This is workable but requires explicit connection-count budgets per worker — an easy thing to get wrong and discover as remote-side rate limiting or file-descriptor exhaustion. Note the asymmetry: this library manages outbound connections, so the scaling concern is your worker count and the remote endpoint's tolerance, not inbound capacity.

Failure modes to instrument.

• Connect timeout — no default; must be set via TimeoutConnector or equivalent, or the worker hangs.
• DNS resolution — synchronous by default unless DnsConnector is composed in; a slow resolver blocks the loop.
• TLS handshake failures — distinguish certificate verification errors from protocol errors in logs; do not "fix" them by disabling verification.
• Loop starvation — any blocking call inside a callback silently degrades every other connection. Detect via latency histograms per connection.
• Memory growth in long-running workers — promise chains and buffers retained on error paths. Sample RSS over time and restart workers on a schedule as a backstop.
• Half-open sockets — no application-level heartbeat unless you build one; idle connections may be silently reaped by an intermediate firewall.

Ramp-up. The real cost is team fluency in ReactPHP's promise/loop model: non-blocking discipline, error propagation through rejected promises, and debugging async stacks. Estimate 2–3 weeks before a mid-level Laravel developer is productive and safe in this code, versus hours for a synchronous stream client. That ramp-up cost should be weighed against the entire value of the feature.

Bottom line for the roadmap: treat react/socket-client as a hard no. If the underlying need is genuine async TCP/TLS, the decision to adopt react/socket + a dedicated worker process is a platform-level commitment that deserves its own ADR; otherwise, a synchronous client or an HTTP-based integration is the lower-risk answer, and this package never enters the dependency graph.