mirror of
https://github.com/jetzig-framework/jetzig.git
synced 2025-07-01 05:26:07 +00:00
6ea210259d
Andrew overhauled std.http to avoid allocations and put control of
connection + stream into hands of users. For now, do a barebones
implementation to restore compatibility, later we can do keepalive and
pipelining. For now, still getting decent enough performance the "slow"
way.
Relevant commit: 6395ba852a
Commit message copied here for posterity:
> Author: Andrew Kelley <andrew@ziglang.org>
> Date: Tue Feb 20 03:30:51 2024 -0700
> std.http.Server: rework the API entirely
> Mainly, this removes the poorly named `wait`, `send`, `finish`
> functions, which all operated on the same "Response" object, which was
> actually being used as the request.
>
> Now, it looks like this:
> 1. std.net.Server.accept() gives you a std.net.Server.Connection
> 2. std.http.Server.init() with the connection
> 3. Server.receiveHead() gives you a Request
> 4. Request.reader() gives you a body reader
> 5. Request.respond() is a one-shot, or Request.respondStreaming() creates
> a Response
> 6. Response.writer() gives you a body writer
> 7. Response.end() finishes the response; Response.endChunked() allows
> passing response trailers.
>
> In other words, the type system now guides the API user down the correct
> path.
>
> receiveHead allows extra bytes to be read into the read buffer, and then
> will reuse those bytes for the body or the next request upon connection
> reuse.
>
> respond(), the one-shot function, will send the entire response in one
> syscall.
>
> Streaming response bodies no longer wastefully wraps every call to write
> with a chunk header and trailer; instead it only sends the HTTP chunk
> wrapper when flushing. This means the user can still control when it
> happens but it also does not add unnecessary chunks.
>
> Empirically, in my example project that uses this API, the usage code is
> significantly less noisy, it has less error handling while handling
> errors more correctly, it's more obvious what is happening, and it is
> syscall-optimal.
>
> Additionally:
> * Uncouple std.http.HeadParser from protocol.zig
> * Delete std.Server.Connection; use std.net.Server.Connection instead.
> - The API user supplies the read buffer when initializing the
> http.Server, and it is used for the HTTP head as well as a buffer
> for reading the body into.
> * Replace and document the State enum. No longer is there both "start"
> and "first".
Jetzig is a web framework written in 100% pure Zig 🦎 for Linux, OS X, Windows, and any OS that can compile Zig code.
The framework is under active development and is currently in an alpha state.
Official website: jetzig.dev
Jetzig aims to provide a rich set of user-friendly tools for building modern web applications quickly. See the checklist below.
Join us on Discord ! https://discord.gg/eufqssz7X6.
If you are interested in Jetzig you will probably find these tools interesting too:
Checklist
- ✅ File system-based routing with [slug] matching.
- ✅ HTML and JSON response (inferred from extension and/or
Acceptheader). - ✅ JSON-compatible response data builder.
- ✅ HTML templating (see Zmpl).
- ✅ Per-request arena allocator.
- ✅ Sessions.
- ✅ Cookies.
- ✅ Error handling.
- ✅ Static content from /public directory.
- ✅ Request/response headers.
- ✅ Stack trace output on error.
- ✅ Static content generation.
- ✅ Param/JSON payload parsing/abstracting.
- ✅ Static content parameter definitions.
- ✅ Middleware interface.
- ✅ MIME type inference.
- ❌ Environment configurations (develompent/production/etc.)
- ❌ Email delivery.
- ❌ Custom/non-conventional routes.
- ❌ General-purpose cache.
- ❌ Background jobs.
- ❌ Testing helpers for testing HTTP requests/responses.
- ❌ Development server auto-reload.
- ❌ Database integration.
- ❌ Email receipt (via SendGrid/AWS SES/etc.)