Patterns

Each page here solves one shape of problem: state that has to cross connections, a caller that has to be authenticated, a program that must run once or keep running, data that has to reach your script, and an endpoint you want to drive before any client exists. Reach for one when you know what you want to build and need to know how the one-process-per-connection model lets you build it.

• Share state across connections — Put the shared part outside the per-connection processes: a message bus, a shared file, or one long-lived backend that every connection's script bridges to.
• Add authentication — websocketd authenticates nobody, so put the check in a reverse proxy in front of it, or validate a token inside the wrapped script.
• Run a program once, or keep it running — Enforce a single instance with a lock-file wrapper, or keep a long-running program alive across a connection by handling SIGINT and SIGTERM.
• Pass data into your script — The query string carries per-connection data from the client with no flag; --passenv forwards named variables from websocketd's own environment to every connection.
• Debug a script before writing a client — Start websocketd with --devconsole, drive the endpoint from a browser, and read the frames your script actually sends.