# Build.zig webserver?

**URL:** <https://ziggit.dev/t/build-zig-webserver/7078>\
**Category:** Brainstorming\
**Tags:** build-system\
**Created:** [November 29, 2024, 9:24pm UTC](https://ziggit.dev/t/build-zig-webserver/7078 "2024-11-29T21:24:37Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![andrewrk](https://ziggit.dev/user_avatar/ziggit.dev/andrewrk/32/7011_2.png) [@andrewrk](https://ziggit.dev/u/andrewrk)\
**Post date:** [December 2, 2024, 8:32pm UTC](https://ziggit.dev/t/build-zig-webserver/7078/4 "2024-12-02T20:32:29Z")

</div>

In the future you should be able to use the `--watch` flag (to `zig build`) for this. I believe there is still a component missing that would enable this which is a way for a process spawned by the build runner to hook into the watch system and receive events.

However, that mechanism isn’t really needed for HTTP servers because there’s a simpler way - make that package support serving the files from disk rather than memory (or make an alternative package that does that), in which case `--watch` already works as-is.

Still, the build system event mechanism is a general-purpose solution to arbitrary build graphs, and so it could be made to work for HTTP servers that serve from in-memory as well, at least as a proof-of-concept. You could imagine a more complicated scenario where it needs to perform some application-specific logic in order to maintain data invariants that go beyond serving files from disk.

Edit: ah looks like I already filed an issue for this:

> <https://github.com/ziglang/zig/issues/20604>
>
> Extracted from #20580.
> 
> When the build system spawns a child process via a \`Ru…n\` step, unless opted out, give it an environment variable that communicates a file descriptor which is a pipe. For example, \`ZIG\_BUILD=4\`. This file descriptor is an open pipe so that the application can speak the zig build system protocol, which will be available in the Zig standard library for convenience.
> 
> This will enable the following use cases:
> \* The application could learn when has been rebuilt, and restart gracefully.
> \* The application could learn when a hot code swap (#68) is available, and then request it at an opportune moment, such as between game frames or web server requests.
> \* The application could be notified that certain assets have been freshly built, and reload them. For example, perhaps the application is a web server, and the static html file asset changes. It could send a message to connected clients telling them to reload the page. This makes \`--watch\` extend into arbitrary environments, with a little bit of cooperation from application developers.
> 
> Of course, applications are free to simply ignore this open pipe as well, just like they can ignore stdin, stdout, or stderr.

---

_[View the full topic](https://ziggit.dev/t/build-zig-webserver/7078)._