Socket Laravel Package

Getting Started

Treat this as a read-the-source package, not a plug-and-play one. Last release 2018-09-19, zero stars, zero dependents, no maintainer activity — so the first step is a viability check before it ever touches composer.json.

1. Check constraints first. Open composer.json on the default branch and compare php and illuminate/* requirements against your stack. A 2018 Laravel package will typically pin ^5.5|^5.6 and PHP ^7.0. On Laravel 10/11 + PHP 8.2 you will almost certainly need --ignore-platform-reqs or a fork.
2. Install into a scratch app, not production.

   composer require rxnet/socket
   

   If it is Laravel 5.5+ era, the service provider should be auto-discovered via extra.laravel.providers. Otherwise register it manually in config/app.php.
3. Publish and read the config. php artisan vendor:publish --provider="Rxnet\Socket\...ServiceProvider" — the config file is the fastest map of what the package thinks it can do (host, port, adapter/loop, handler paths).
4. Orient in src/. Look for, in this order: the service provider (what it binds into the container), any Console/Commands/* (how you actually run the server), and the handler/listener directory (how you register behaviour). Those three files tell you the whole architecture.
5. First use case. Start the socket server as a foreground artisan command, connect with a trivial client (websocat, wscat, or a browser new WebSocket(...)), send one message, and confirm you can see it in the handler. Do not integrate broadcasting or auth until that round-trip works.

Realistic expectation: this package is a thin wrapper around a ReactPHP/Ratchet-style event loop. You are adopting the idea, and likely vendoring the code.

Implementation Patterns

Run the server as a supervised daemon, never under php artisan serve. Whatever command starts the listener is a blocking, long-running process. Put it under Supervisor/systemd, or a dedicated container in docker-compose sharing the app codebase and .env.

Handler registration is the primary extension point. The idiomatic shape for packages of this vintage is a config-driven map of event name → handler class, resolved out of the container. Keep handlers small and stateless-ish: resolve dependencies via constructor injection, do work, emit a response. Because the process is long-lived, anything you cache in a handler persists across connections — which is either your best feature or your worst bug.

Bridge Laravel events to socket clients. The cleanest integration is one-directional: your HTTP app dispatches normal Laravel events, and a listener forwards the payload to the socket server over an internal channel (Redis pub/sub, a local TCP port, or an HTTP call to a small control endpoint). This keeps the HTTP and socket processes decoupled and lets you scale them independently.

Authenticate at the handshake, not at the first message. Since the socket process is outside the HTTP request lifecycle, Auth::user() is not populated. Pass the session cookie or a signed token in the connection query string and validate it in the connect handler; stash the resolved user ID on the connection object for the session's lifetime.

Frontend pattern. Pair with socket.io-client or a raw WebSocket depending on what the transport actually speaks — verify by reading the handshake code rather than the README. Keep a single reconnecting client instance per tab and re-authenticate on reconnect.

Test the protocol, not the loop. Unit-test handler classes directly by instantiating them with mocked connections; leave the loop alone. For the full path, a shell script with wscat in CI is far more reliable than trying to bootstrap the event loop inside PHPUnit.

Gotchas and Tips

• It is effectively abandonware. No security fixes, no PHP 8 compatibility work, no issue triage. Audit the code once, fork it to app/Packages/, and vendor it. Budget a day for PHP 8 fixes (removed each(), curly-brace string offsets, ReflectionType differences, nullable parameter ordering).
• Stale config after deploy. Long-running processes do not pick up .env or config/*.php changes. Every deploy must restart the socket workers — add that to your release script, or you will debug a "config change did nothing" ghost for an hour.
• Memory leaks are cumulative. A leak of 100KB per connection is invisible in dev and fatal at 10k connections. Add a periodic graceful restart (Supervisor max_requests-style, or a self-restart after N connections) from day one. Check for handlers that append to arrays on the server object.
• Reverse proxy is the usual failure point. Nginx needs proxy_set_header Upgrade $http_upgrade; and Connection "upgrade", plus proxy_read_timeout bumped past 60s. If the connection drops every ~60 seconds, it is the proxy, not the package. Terminate TLS at the proxy and connect internally over plain ws://.
• Port binding failures are silent-ish. EADDRINUSE surfaces as a crash or a hung process depending on error handling. Always start in the foreground with verbose output before writing the Supervisor unit.
• Config quirks. Expect hardcoded defaults from 2018 (e.g. a fixed 0.0.0.0 bind, or a loop adapter chosen by class name string). Verify that the config you published is actually the key path the code reads — misnamed keys falling back to defaults is the classic symptom.
• Extension points worth checking: whether the loop/adapter is behind a container binding (swappable for a different ReactPHP loop), whether the connection object is injectable into handlers (that is where you hang per-user state), and whether middleware-style pre-handshake hooks exist — if not, wrap the connect handler yourself.
• Opportunity score ~26 / overall 0.09 means: build vs. buy is not close. For anything customer-facing, a maintained alternative (Laravel Reverb, Soketi, or a plain Ratchet implementation you own) is lower total cost. Use this repo as a compact reference implementation of the pattern, and take the ideas rather than the dependency.