SolidJS•2w ago

Run server code only once

I'm trying to run an embedded db in SolidStart, but every time a new route is visited the db initialization is re-run and the db data gets corrupted. Is there a way to only run the db code once and reuse it for all routes? I saw this issue in nitro which seems like it would solve it, but the code still runs for every route https://github.com/nitrojs/nitro/issues/711#issuecomment-1415819402 My db initialization in utils/db.ts looks like:

import { Database } from "db"

const DATA_DIR = "./.data"

let _db: Database
export const useDB = () => {
    if (!_db) {
        _db = new Database(DATA_DIR)
    }
    return _db
}

import { Database } from "db"

const DATA_DIR = "./.data"

let _db: Database
export const useDB = () => {
    if (!_db) {
        _db = new Database(DATA_DIR)
    }
    return _db
}

GitHub

Add 'provide' option to Nitro Plugins. · Issue #711 · nitrojs/nitro

Describe the feature It would be nice if you could provide objects from Nitro plugins, like you can with Nuxt plugins. In my opinion, this would make the usage of something like Prisma ORM with Nit...

2 Replies

ConeOP•2w ago

I think this issue is relevant: https://github.com/nksaraf/vinxi/issues/51

GitHub

"use server" chunks are duplicated in build · Issue #51 · nksaraf/v...

Is: If you create a file with "use server" and use it in a component/route file, the file code will be duplicated to two chunks. It will be in server/chunks/build/someRoute.mjs and also s...

peerreynders•2w ago

My information is at least 8 months old so take this with a grain of salt. 1.) To get going reference your kick off code in src/entry-server.tsx. As far as I know that module loads only once per startup. In the end though you'll likely want to use a lazy load technique where you startup the DB the first time you need it to service a request. 2.) Even if that works you're not out of the woods yet. As far as I can tell vinxi (which runs on top of nitro) runs multiple workers to serve various server functions. So for an embedded DB that means that its functionality is limited to the worker that it is started in. I documented this in https://github.com/peerreynders/server_-routes-lobotomy What I found was that actions (use server) and route requests acted like they were processed in separate workers and that route requests didn't have access to resources spun up in entry-server—which makes sense as requests run isolated in their own AsyncContext. So to access non-framework server resources from the requests in the other worker I had to use BroadcastChannel to set up communications between the request and the server worker. While this may seem massively inconvenient in your particular use case it's a non-issue for the majority case where persistent storage runs in it's own OS process and is accessed separately by the server and request worker.

GitHub

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

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

MDN Web Docs

Broadcast Channel API - Web APIs | MDN

The Broadcast Channel API allows basic communication between browsing contexts (that is, windows, tabs, frames, or iframes) and workers on the same origin.

GitHub

server_-routes-lobotomy/src/server/pub.ts at 30b0b48fd476a573bed177...

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

Gaming

Programming

Run server code only once