SolidJS•9mo ago

Is it possible for all requests and actions to share a server side (singleton) module in memory?

In the process of updating my Chat with SSE using SolidStart example from 0.2.26 to 1.0.0-rc.0 I've hit a snag. All the responses (subscriptions) from the SSE endpoint (api/messages) share one copy of the server's pub-sub module, while all the send-message actions go to a separate copy of that module (which of course doesn't have any subscriptions registered). I've tried routing the imports through src/entry-server.ts in case that might coerce the use of one common instantiation (it didn't), and doubled down by using unjs/hookable (perhaps improperly) there, again without success. At this point I'll probably start looking at BroadcastChannel based workarounds or even re-imagining the server side pub-sub solution around it. Is there some simple solution I'm overlooking that would allow the (server) actions and streaming responses to easily gain function call access to the same in-memory pub-sub management instance? Thank You for your time!

GitHub

GitHub - peerreynders/solid-start-sse-chat at restart

Basic Chat demonstration with server-sent events (SSE) - GitHub - peerreynders/solid-start-sse-chat at restart

GitHub

GitHub - unjs/hookable: 🪝 Awaitable Hooks

🪝 Awaitable Hooks. Contribute to unjs/hookable development by creating an account on GitHub.

MDN Web Docs

BroadcastChannel - Web APIs | MDN

The BroadcastChannel interface represents a named channel that any browsing context of a given origin can subscribe to. It allows communication between different documents (in different windows, tabs, frames or iframes) of the same origin. Messages are broadcasted via a message event fired at all BroadcastChannel objects listening to the channel...

4 Replies

Paul Armstrong•9mo ago

It's a little hacky, but you can assign things to global. I usually use a symbol to avoid any sort of global variable clash:

const sym = Symbol.for('CLIENT');

function myMiddlware() {
  let client = global[sym];
  if (!client) {
    client = createClient();
    global[sym] = client;
  }
  // ... use the client
}

const sym = Symbol.for('CLIENT');

function myMiddlware() {
  let client = global[sym];
  if (!client) {
    client = createClient();
    global[sym] = client;
  }
  // ... use the client
}

peerreyndersOP•9mo ago

Interesting, thank you. So far my results with BroadcastChannel suggest that server actions and route endpoints run on different threads, i.e isolates. I'm at a loss to understand how that approach would be able to get around that.

Paul Armstrong•9mo ago

Do you have a minimal repro?

peerreyndersOP•9mo ago

https://github.com/peerreynders/server_-routes-lobotomy Unfortunately StackBlitz gave me grief about the BroadcastChannel so I couldn't get it to work there.

GitHub

GitHub - peerreynders/server_-routes-lobotomy: Demonstration of bri...

Demonstration of bridging communication between the isolated server and routes processing - peerreynders/server-routes-lobotomy

Gaming

Programming

Is it possible for all requests and actions to share a server side (singleton) module in memory?

Did you find this page helpful?