An implementation of the Datastar SDK for Zig 0.16-dev latest
Write reactive multi-player web apps, entirely driven from the backend
No JS, no npm, no build step (other than zig build)
Includes bundled/optional HTTP server using latest std.http and std.Io
Includes bundled/optional PubSub message broker for doing event sourcing / multiplayer
Includes several non-trival example apps to demonstrate the full SDK
It is 0.16-dev, so its all bleeding edge, and will break often as things change.
Might be useful if you are getting into 0.16, and want to play with HTTP servers, new IO, etc.
The stable Zig 0.15.2 Datastar SDK for http.zig based servers exists in a separate repo, and is available for those who dont want to live on the bleeding edge.
Just took a look at the examples, and I notice you’re using init.arena as the primary allocator whereas prior to updating to use juicy main you were using DebugAllocator. I think it might be better to use init.gpa as your main allocator because you also appear to be wrapping your init.arena in another ArenaAllocator for every request, which means that when concurrent requests occur you’re also very likely going to leak memory over the lifetime of the server program.
Also, one very important thing, you are ignoring the result of io.concurrent which means leaking potentially large amounts of memory. You should use Io.Group.concurrent there. And also you need to close the connection if concurrent fails.
The arena allocator is a problem because it’s bump allocator, pretty much only ever growing.
Useful feedback re using init.gpa and Io.group for concurrency - thanks. Will apply those improvements asap.
Yeah, I can see now how basing off init.arena at the top level is a footgun in this case. The example apps behave OK under load, but yeah that’s a possible footgun leaving it like that. Thanks for pointing that out.
Will definitely add some more robust bench and memory consumption work before sticking a release tag on anything here. As you know, Io is very much a moving target still, so I’m expecting a few passes of little rewrites here and there along the way. Especially interested in seeing Io.Evented land.
What I’m hoping for in the longer term is we end up with some good interface patterns for web dev, and a healthy ecosystem of compatible and modular components that can be swapped in and out with relative ease (including routers, middleware, custom Io implementations, etc)