Add websocket support to Kino.Proxy?

[elepedus]

Kino.Proxy currently doesn't support websockets. This makes it harder to use LiveView in cloud-hosted notebooks, by requiring a new HTTP server to be started on a different port e.g. using PhoenixPlayground. However, since most servers will only expose ports 443 & 80 to the internet, those newly opened ports can't be accessed.

I managed to work around this by manually opening additional ports on my Livebook server machine, but that's not really an option for other users who don't also control the underlying infrastructure. If I wanted to enable other users of the Livebook instance to experiment with Liveview, I would have to pre-emptively open a lot of ports, and hope users keep trying until they find an unused one they can map to. This gets even worse when considering deployments to Teams App Servers, since there's no real way to manage port allocations and prevent clashes.

The ideal solution would be for us to be able to use Liveview inside our notebooks over the existing HTTP(s) port via the Kino Proxy. This could work either by proxying websocket traffic to the existing Phoenix Endpoint, perhaps with some identifying information, or by starting a separate endpoint on a random port on the same host, and proxying traffic to that.

In principle, this doesn't need to be too hard (we wrote a websocket proxy in Go last year), but I don't know if there are specific blockers or complications with doing it inside Livebook?

Either way, for your amusement, I've included a snippet from my fly.toml, where I now expose an additional range of ports from 10000 to 10100:

[[services]]
processes = ["app"]
protocol = "tcp"
internal_port = 10097

[[services.ports]]
port = 10097
handlers = ["tls", "http"]

[[services]]
processes = ["app"]
protocol = "tcp"
internal_port = 10098

[[services.ports]]
port = 10098
handlers = ["tls", "http"]

[[services]]
processes = ["app"]
protocol = "tcp"
internal_port = 10099

[[services.ports]]
port = 10099
handlers = ["tls", "http"]

[jonatanklosko]

If the target use case is using the proxy with LV, then for an initial version it could probably use longpoll as the socket transport.

[jonatanklosko]

For single-session apps you can use a URL without session id:

Mix.install([
  {:kino, "~> 0.14.2"},
  {:phoenix_live_view, "~> 1.0"},
  {:jason, "~> 1.4"}
])

Application.put_env(:proxy_live_view, ProxyEndpoint,
  server: false,
  adapter: Bandit.PhoenixAdapter,
  live_view: [signing_salt: "aasdffas"],
  secret_key_base: String.duplicate("a", 64),
  pubsub_server: ProxyLiveview.PubSub,
  # change this to your proxy url
  url: [path: "/proxy/apps/{slug}"]
)

Or maybe Kino.Proxy could define a base_path/0 function? I suppose that's tricky because the config is done before Kino is available?

Using Application.put_env as above means we could technically call Kino APIs (it also does means the Mix.install/1 is cached regardless the config). Kino.Proxy.base_path/0 is something were actually considering, but it turned out it wasn't necessary for the use case that started the discussion. It would return /proxy/sessions/:id when running in a regular session and /proxy/apps/:slug and /proxy/apps/:slug/sessions/:session_id for single and multi session app sessions respectively.

[elepedus]

That's a neat trick -- thank you!

The challenge I'm trying to navigate is the change in path between running in a regular "development" session, then deploying to preview/teams app server.

Right now, I think I have to set the path to my notebook session while developing, then deploy my app, wait for it to fail, go to debug mode and alter the path to the correct value for that specific deployment. It's not the end of the world, but it becomes untenable if I want to deploy every minute or two, or if I want to allow users to deploy to a server to which they don't have dashboard access.

A way to query the right value would be much nicer :)

[jonatanklosko]

then deploy my app, wait for it to fail, go to debug mode and alter the path to the correct value for that specific deployment.

I would imagine you set it to /proxy/apps/{slug}, then both deploy and preview should work just fine.

But yeah, Kino.Proxy.base_path/0 would be useful in this case.

[elepedus]

I've put together a little package to make it easier to replicate this in the future: https://hex.pm/packages/kino_phoenix_live_view

It's now just KinoPhoenixLiveview.new(path: "/proxy/apps/{slug}") :)

[jonatanklosko]

Sweet!