Using without the server — is there a use-case of hocuspocus frontend components, without a server?

[floer32]

I have a browser extension use case that's not collaborative editing (at first), but rather, supporting a single user with multiple tabs in one browser. Got curious if hocuspocus would be of use here — and if so, would it only be client-side usage? (Can synchronization features work with just broadcastchannel/etc, and no server? For a single user in various tabs.)

So I was reviewing the source, and thinking about if/how hocuspocus could be used in a browser extension. A hocuspocus provider could use the browser API to exchange messages with the background-page (or in mv3, calling service worker), rather than a server. Provider would communicate with a browser extension background process, via browser API - messages &/or alarms).

Anybody have a sense of feasibility?

Update a while later:

• Yes Yjs could make sense in a browser extension
• YMMV re: using hocuspocus without collaboration features needing a server. It might just be an impedance mismatch, since hocuspocus is designed for collaboration.

[floer32]

Maybe this is misguided. If it seems misguided, let me know? 😅 @tommoor

[hanspagel]

I don't know how we can help here. Using Y.js really depends on your use case and we can’t give a recommendation there, but I don’t see how this is related to the Node.js backend hocuspocus at all. 🤔

[floer32]

Yeah I figured, it's a novel use case and I'm probably trying the wrong abstractions. (For posterity: currently I'm trying out using broadcast-channel (+ nanostores), and plan to use hocuspocus later for true collaborative editing features)

[meatflavourdev]

Head over to https://discuss.yjs.dev/ -- that's the appropriate place for a question like this.

But since we're here... I’m considering using Yjs for browser extension… the browser extension background.js has listeners set for messages from content tabs and from the chrome APIs. It writes them in an event store append-only array which is broken up semi-regularly into subdocuments, so the entire history only has to be loaded into local memory as necessary or to the last state snapshot (using event sourcing for this particular project)

The NodeJS server, hocuspocus, in this case, take these events and passes them to a service broker which takes care of the transport to the message broker and to the persistence service, analytics, whatever. The hocuspocus/gateway service is a producer in this case. It is also a consumer of some aggregation services or whatever is needed and this is automatically passed back down from the service broker’s reception, into a subdocument corresponding to the particular service to which we are subscribed. Handy eh?

I’ve essentially replaced a APIful gateway service with an API-less Yjs streaming service that sucks up my events and hands me back down aggregates or additional event log entries (as updates) as needed. I don’t have to do anything but push up events and react to the changes in state. I think this is a good idea. Haven’t tested it yet.

(Obv, reception of new events would trigger an update to the state which is only a projection of the event log-- notably, the state is not sent to the backend, only projection snapshots of state corresponding to a particular master event IDs are received from the snapshot service as a sanity check. When we make or receive a new snapshot, we end the event log at that ID and start a new subdocument such that each snapshot is corresponds with each eventlog subdocument)

I wonder if YJjs would be a good fit for an entire microservices backend? I mean… why stop at the frontend? 🤔 I cannot say, as I am most certainly not planning on implementing it. 😜 Perhaps it’d be some kind of distributed stateful orchestration microservices type deal, like https://cloudstate.io/(?)