|
|
Handling = business logic
|
|
|
Handling in WS:
|
|
|
+ per client – does not hang others
|
|
|
- hard to argue about? – very async
|
|
|
- race prone? ((partly?) avoided by having state elsewhere = PubSub
|
|
|
- NOTE: inherently racy anyway, as the order of commands arriving and being process is not guaranteed. (it might be possible to add arbitrary serialisation, but too much work ig)
|
|
|
|
|
|
Handling in PubSub:
|
|
|
- blocking?
|
|
|
+ at one place – if state is elsewhere, we do not need to forward a lot
|
|
|
* We believe in one pubsub per netzpevnik instance
|
|
|
* We expect ~few connections and ~low-pace of events, so perf should not be an issue
|
|
|
+ Most requests still have to go through PubSub, bc they need state or influence other clients
|
|
|
* The PubSub has to do map/list traversals and calls anyway.
|
|
|
+ We expect most logic be reducible to ops on top of the state kept/ref'd by PubSub
|
|
|
+ We could probably tolerate having some preprocessing in WS handler and PubSub “only” doing the shared stuff.
|
|
|
=> This feels reasonable.
|
|
|
|
|
|
|
|
|
Handling elsewhere:
|
|
|
* if it is per client, it does have the benefits and disadvantages of ws worker and vice versa?
|
|
|
+ we could have the logic separated in another part of code for clarity.
|
|
|
The code organisation does not influence the process model much, though
|
|
|
|
|
|
Random alternative: WS handler dispatching Tasks that do stuff – in a sense, WS behaves as a compiler and PS/independent ad-hoc process executes it
|
|
|
- Probably has no advantages as long as the load is managable by PubSub.
|
|
|
- And even then splitting the PubSub into multiple low-load servers seems like a better idea.
|
|
|
(is that possible, though?)
|
|
|
|
|
|
-----
|
|
|
URLS:
|
|
|
netzpevnik.local — statically served SPA
|
|
|
netzpevnik.local/instance
|
|
|
netzpevnik.local/new/instance → create → temp redirect to /instance (possibly auth'd)
|
|
|
instance = [a-zA-Z0-9][a-zA-Z0-9.-_]*
|
|
|
netzpevnik.local/api/instances → JSON array of currently existing (public) instances?
|
|
|
Expose from SPA for easy discovery; also allow creating from SPA ig
|