Discuss Migrate to Pure PHP - Retiring node-pty and Node WebSockets

[LEstradioto]

Objective: Remove Node.js as a dependency by retiring node-pty and Node WebSockets, transitioning to a pure PHP solution for Coolify.

While the impact on Coolify's performance is uncertain, this could be a valuable contribution to the PHP community. It may also lead to the development of a reusable library solving similar stuff.

1. A long-running PTY process on the server that persists between request cycles.
2. Real-time communication capabilities similar to WebSockets, implemented in pure PHP or using low-level alternatives.

Topics of interest:

1. Evaluate websocket-php as a WebSocket alternative.
2. Explore porting uWebSockets (currently C++ with Node.js bindings) to PHP, possibly using C or Rust. Soketi, which is the current websocket is based on uWebSockets, shows promising performance in benchmarks.
3. As I was coding the current Terminal, @jerch, who appears to be an xterm.js contributor, expressed interest in assisting with the C-level part.

Im starting this topic searching for technical insights, analysis, and suggestions from the community. At first it looked a crazy idea, but I could not solve this with current Libraries out there, so, maybe its a good idea. 😄

[jerch]

A few throughts from my side...

A long-running PTY process on the server that persists between request cycles.

To me it seems that the only viable solution would be to create something like a separate terminal server, that can host multiple PTYs in its process(es)*. This component could expose an API to create/read/write/resize/destroy terminals. As a goodie on top it also could provide a control plane for dedicated admin access (kinda a must have for bigger/clustered setups).

---

[*] Internally mainly 3 resource structuring models would work:

1. a single process, IO handled by kernel events (poll/kevent etc) - slim
2. a single process, IO handled in dedicated terminal threads - middle ground (thats kinda what node-pty implements)
3. multiple processes, each handling IO for one terminal - fat

Imho 1. is the best candidate for the PTY task for several reasons (Pros):

• Terminals are primarily meant for user interaction idling often. On an action it should be as fast possible not putting too much latency between action-response. Thats the strong domain of kernel-event-based solutions. 2./3. are much more heavy in this regard.
• No messing around with mutexes (2.).
• No waiting for processes to be available (3.).

Ofc 1. also has a big Con - the theoretical max throughput is bound to the single process and all IO gets serialized through the event dispatcher in that single process. No fancy kernel scheduler can be used, scheduling/priority would have to be done "manually" at that event dispatcher. This may lower the saturation throughput with many PTYs pumping tons of data, if lousy implemented (a threaded model simply moves that responsibility into kernel realms). But again, terminals are often idle and still IO bound, so this is more of an unlikely edge case. Also a PTY itself is a quite heavy resource for the OS (by default limited to 4096 on linux). So it is not very likely either, that someone would want to serve 10k+ PTY via one process. And last but not least - if the single process approach really narrows throughput too much, one could simply spawn another terminal server process serving the next batch of PTYs.