3 ms·

Show HN: Plane – spawn and connect to a remote process from your web app

10 points by paulgb 4y ago

paulgb 4y ago
Hi HN! While working on data-intensive applications, we wanted a way for each client to spin up its own dedicated remote process and open a long-lived connection to it. This follows the approach used by VS Code and Jupyter. For data-intensive apps, the desire was to have a place close to the data to run stateful compute that may exceed the limitations (memory, CPU, network) of browsers. Plane (formerly called Spawner) is our generalized, MIT-licensed, Rust-based implementation of this architecture. In addition to powering data-intensive apps[1], it’s been used (via our hosted version, Jamsocket) to: - Pixel-stream X11 applications to the browser over WebRTC[2] - Run IDEs and notebooks - Power Figma-style realtime collaboration backends (including https://rayon.design https://rayon.design). The way it works is that your backend sends a request to Plane (as JSON over NATS) requesting a new instance of a specified container image. Plane spins up the container and responds with a unique hostname assigned to it. Plane routes traffic to it via DNS and a reverse proxy, and takes care of TLS termination and certificate rotation. Once all inbound connections to a container are dropped (i.e. the app user has closed the tab), Plane shuts it down. A tidbit that HN might appreciate: we wanted to reduce the friction to trying out Plane as much as possible, which is tough because a production install requires configuring DNS nameservers and obtaining real certificates. To make it easy to run locally, we ship it with a Docker Compose that includes a containerized instance of Firefox, bundled with a tiny DNS server (dnsmasq) that selectively forwards to Plane, a self-signed CA cert, and an Apache Guacamole server with web client. The result is that you can start a Plane instance, and then open the embedded Firefox from inside your own browser to simulate production network settings locally. [1] https://twitter.com/drifting_corp/status/1554488135832276996 https://twitter.com/drifting_corp/status/1554488135832276996 [2] https://twitter.com/drifting_corp/status/1552773567649091584 https://twitter.com/drifting_corp/status/1552773567649091584

10 points by paulgb 4y ago

Hi HN! While working on data-intensive applications, we wanted a way for each client to spin up its own dedicated remote process and open a long-lived connection to it. This follows the approach used by VS Code and Jupyter. For data-intensive apps, the desire was to have a place close to the data to run stateful compute that may exceed the limitations (memory, CPU, network) of browsers. Plane (formerly called Spawner) is our generalized, MIT-licensed, Rust-based implementation of this architecture. In addition to powering data-intensive apps[1], it’s been used (via our hosted version, Jamsocket) to: - Pixel-stream X11 applications to the browser over WebRTC[2] - Run IDEs and notebooks - Power Figma-style realtime collaboration backends (including https://rayon.design https://rayon.design). The way it works is that your backend sends a request to Plane (as JSON over NATS) requesting a new instance of a specified container image. Plane spins up the container and responds with a unique hostname assigned to it. Plane routes traffic to it via DNS and a reverse proxy, and takes care of TLS termination and certificate rotation. Once all inbound connections to a container are dropped (i.e. the app user has closed the tab), Plane shuts it down. A tidbit that HN might appreciate: we wanted to reduce the friction to trying out Plane as much as possible, which is tough because a production install requires configuring DNS nameservers and obtaining real certificates. To make it easy to run locally, we ship it with a Docker Compose that includes a containerized instance of Firefox, bundled with a tiny DNS server (dnsmasq) that selectively forwards to Plane, a self-signed CA cert, and an Apache Guacamole server with web client. The result is that you can start a Plane instance, and then open the embedded Firefox from inside your own browser to simulate production network settings locally. [1] https://twitter.com/drifting_corp/status/1554488135832276996 https://twitter.com/drifting_corp/status/1554488135832276996 [2] https://twitter.com/drifting_corp/status/1552773567649091584 https://twitter.com/drifting_corp/status/1552773567649091584