How to use as just a Websocket server (for browser/mobile client)?

[lefnire]

So I realize this project is intended for RPC between servers, wrapping fastapi_websocket_rpc. I do see some hints at browser

easily accessible and scalable over the web and across your cloud in realtime

And it seems like this project could really streamline FastAPI WebSocket endpoints even just for that use-case (browser/mobile clients). In particular, the auto-handling of broadcaster while still exposing on_connect|disconnect, marshaling request/response via Pydantic, etc. Things I'm struggling with using FastAPI WebSockets "raw" + broadcaster (discussion).

Anyway, that said I'm not clear on how to have the server both subscribe & publish. Eg, what I'm looking for in pseudo-code would be:

sockets = []

app.on_connect(websocket):
  sockets.append(websocket)

app.subscribe(topic, data):
  if topic == 'chat':
    save_to_db(data)
    for s in sockets:
      if s.hasPermission(topic):
        endpoint.publish('new-message', data)

That is, it's using both subscribe and publish. On the README there's separate setups for pub vs sub (ie: PubSubEndpoint vs PubSubClient). It strikes me they can both be used together on the FastAPI server, but I'm not sure how. The PubSubClient takes a server_uri, which in this scenario should just be "self" (or, PubSubClient should be available directly from PubSubEndpoint?). And the client_example loops main() in asyncio.run; which in the above scenario wouldn't be compatible with FastAPI's main loop (right)? Looking through the code, it strikes me that maybe I want to instantiate a custom EventNotifier and pass that to PubSubEndpoint, so I can both broadcast & listen - but I'm not sure I'm barking up the right tree.

TL;DR: how, just on the FastAPI server, can I both subscribe to messages from the browser, and publish things back?

---

BTW, it may sound like I'm fitting circle to square peg, but I actually want to use this project anyway for server->server RPC (separate); so if it can streamline both scenarios, this would be a very valuable project indeed.

[orweis]

Hey @lefnire - I'm super happy you see the value in this package.
And yes this can definitely work well for mobile, web, and even edge / IoT- the network layout and protocol are designed for scale out cases. - We're even thinking of creating JS clients in the future (though no immediate plans yet).

To the specific question:

"how, just on the FastAPI server, can I both subscribe to messages from the browser, and publish things back?"

You're pseudo-code is not far off, just need to add a callback ;-)

You have two options to add subscribing logic at the backend:

• Subscribing directly to the event notifier (you can already do it via endpoint.notifier.subscribe(id, topics, callback) but I just released a new version adding the method to the endpoint directly (i.e. endpoint.notifier.subscribe(topics, callback)) to make it even easier. I've added a test as an example - showing how you can even trigger another event from the handling of the first.
  key part:

    app =  FastAPI()
    # PubSub websocket endpoint
    endpoint = PubSubEndpoint()
    endpoint.register_route(app, "/pubsub")

    # receive an event and publish another (this time for the client)
    async def event_callback(subscription:Subscription, data):
        logger.info(f"Got topic {subscription.topic} - re-publishing as {CLIENT_TOPIC}")
        asyncio.create_task(endpoint.publish([CLIENT_TOPIC], data))

    @app.on_event("startup")
    async def startup():
        # subscribe to our own events
        await endpoint.subscribe([SERVER_TOPIC], event_callback)
    
    # Regular REST endpoint - that publishes to PubSub
    setup_server_rest_route(app, endpoint)
    uvicorn.run(app, port=PORT)

• Spinning off a client at the backend connecting to itself (via the loopback adapter) , as another asyncio task, or as a sub process.
  This is ideal if you'd like to breakdown your app into microservices, and create better separation of duties in general.
  In general I'd recommend this approach for more robust solutions.

Hope this helps, feel free to follow up with more questions.

[Faridalim]

Awesome project. I hope for JS client so we can start using it in the browser.

[orweis]

Thanks @Faridalim :)
I agree that adding a JS version makes a ton of sense; I unfortunately won't be able to get to it soon.
If you or others want to take up the challenge - I'd be happy to guide you on how to go about it.

[lefnire]

This is fantastic, thanks so much for the very thorough follow-up! Very cool project