# socketelx v0.2.1 - Table of Contents

> A Pusher-compatible WebSocket server for Elixir, inspired by Laravel Reverb. Run it as a Docker image or embed it in your Elixir app.

## Pages

- [Socketelx](readme.md)

- Guides
  - [Getting started](getting-started.md)
  - [Configuration](configuration.md)
  - [Embedding in your app](embedding.md)
  - [Running several servers](multi-server.md)
  - [Deployment](deployment.md)
  - [Protocol support](protocol-support.md)
  - [Load testing](load-testing.md)
  - [Troubleshooting](troubleshooting.md)
  - [Using it with Laravel](laravel.md)

- Examples
  - [Chat example](chat-example.md)

- Project
  - [Contributing](contributing.md)
  - [Security policy](security.md)
  - [Changelog](changelog.md)

## Modules

- Public API
  - [Socketelx](Socketelx.md): Embed a Pusher-protocol-compatible websocket server in your own
application's supervision tree

- Configuration
  - [Socketelx.Config](Socketelx.Config.md): Per-instance configuration.

- Backends
  - [Socketelx.Backend](Socketelx.Backend.md): The seam between "one node" and "many nodes".
  - [Socketelx.Backend.Local](Socketelx.Backend.Local.md): Single-node, in-memory backend. No external dependencies.
  - [Socketelx.Backend.Redis](Socketelx.Backend.Redis.md): Redis backend: lets several `socketelx` nodes behave as one.

- Internals
  - [Socketelx.Application](Socketelx.Application.md): OTP application callback — only relevant when this project is compiled
and released as its own standalone deployment (the Docker image). When
`socketelx` is instead pulled in as a hex dependency of another
app, this starts an empty supervisor and does nothing: the host app is
expected to add `{Socketelx, opts}` to its own supervision tree
explicitly (see Socketelx's moduledoc).
  - [Socketelx.Auth](Socketelx.Auth.md): Implements the two signature schemes the Pusher protocol uses
  - [Socketelx.Backend.Redis.Janitor](Socketelx.Backend.Redis.Janitor.md): Keeps the shared Redis state honest when a node dies without cleaning up.
  - [Socketelx.Backend.Redis.Subscriber](Socketelx.Backend.Redis.Subscriber.md): Receives other nodes' broadcasts from Redis pub/sub and delivers them
to the sockets connected to *this* node.
  - [Socketelx.Cluster](Socketelx.Cluster.md): The one place the websocket handler and HTTP router go through for
anything that may need to reach *other* nodes: broadcasting, presence,
and channel occupancy.
  - [Socketelx.HttpRouter](Socketelx.HttpRouter.md): Plug router for the Pusher REST API
  - [Socketelx.Metrics](Socketelx.Metrics.md): Counters and a Prometheus-format exporter for one instance.
  - [Socketelx.Naming](Socketelx.Naming.md): Derives unique process/registry names from an instance `name`, so
multiple named instances (e.g. two different app_ids on two different
ports, both embedded in the same host app) never collide.

  - [Socketelx.Presence](Socketelx.Presence.md): Tracks presence-channel membership for one instance. Keyed internally
by socket_id so a user with multiple tabs/connections works correctly:
`member_added` only fires for a user_id's first connection,
`member_removed` only fires when their last connection drops.
  - [Socketelx.Webhook](Socketelx.Webhook.md): Fires webhooks in the same shape Pusher sends them, so your backend can
handle them with any code written for Pusher webhooks
  - [Socketelx.WsHandler](Socketelx.WsHandler.md): Implements the client-facing side of the Pusher protocol over a raw
cowboy websocket (not Phoenix Channels — a different wire format).

