I'm using fjall v2 in the Rust event streaming store, cross.stream (`xs`) https://github.com/cablehead/xs

`xs` is for personal scale so fjall is fairly overkill performance-wise. marvin_j97's benchmark work and deep dives into different database systems is incredible though. Looking forward to updating to v3.

Fjall

https://github.com/fjall-rs/fjall

If you like lo-fi ways to attach cli commands to http end-points, you may also like:

- https://github.com/cablehead/http-nu or for POSIX - https://github.com/cablehead/http-sh

astroturf campaign?

ngmi

My understanding is Turbo is more aligned with htmx. Common practice in Turbo are generally patterns of last resort in Datastar.

e.g. Datastar prescribes a single long lived SSE endpoint that owns the state for the currently connected user's view of the world / app, while common practice in Turbo is to have many small endpoints that return a fragment of html when requested by the client.

The preferred pattern addresses your concern about scattered logic: a single long-lived SSE endpoint that "owns" the user's view of the app. That endpoint updates their field of view as appropriate - very much inspired by game dev's immediate mode rendering.

I've a tutorial that demonstrates this with Nushell as the backend: https://datastar-todomvc.cross.stream

An interesting characteristic of Datastar: it's very opinionated about the shape of your backend but extremely unopinionated about how you implement that shape.

I maintain a Rust-based CLI HTTP server that embeds Nushell. It’s a handy little Swiss-army knife that’s replaced Nginx and Caddy for my personal projects.

You can serve a folder of static assets like this:

http-nu :3021 '{|req| .static "www" $req.path}'

https://github.com/cablehead/http-nu

I was looking to try something like this (without the nushell...), but I find that I always have caddy installed anyway, and for the really local cases I use php -S.

I'm curious, what do you think is missing from Caddy that has you looking for something new?

The approach you describe requires host to have an open ssh port you can access. quic + nat hole punching works around this.

The friction Dave describes where changing one param effects all the other params in an animation brought to mind this section of an old Bret Victor talk: https://www.youtube.com/watch?v=a-OyoVcbwWE&t=716s

Iroh is intriguing. Dumbpipe is magical, and its implementation is easy to understand. I use dumbpipe daily to expose cross-stream (https://github.com/cablehead/xs) stores I run on different servers to my local laptop's `xs` client.

A bit off topic I guess, but what’s your usage for xs? I read the website, I think that I understand it and find it intriguing, but I’m not sure what one would use it for.

A basic use case, to tie it back to the topic :)

When I'm working on a remote machine, it's nice to be able to easily pass things back and forth between it and my local laptop. I start a stream on the remote server and use `dumbpipe` to make the stream available on my local laptop.

```

# remote

xs serve ./store --expose :3001 ; dumbpipe listen-tcp --host 127.0.0.1:3001

# local

dumbpipe connect-tcp --addr 127.0.0.1:3001 <ticket>

$env.XS_ADDR ":3001" ; .cat

```

I can then do things like:

```

# local

cat local.file | .append local.file

# remote

.head local.file | .cas

```

Or register a local handler for the topic "pasteboard" that puts the contents on my local clipboard. Then, from the remote machine, I can run: `"foo" | .append pasteboard`