Foxhole [0.4.0] Ergonomic web framework

[twilit tide]

https://github.com/Kay-Conte/foxhole-rs
https://crates.io/crates/foxhole
Been working on and off on this for a bit now. I find this much easier and straightforward to grasp than frameworks like axum and actix that almost try to do too much. In doing so, macros infect their interface obscuring a lot of the code behind the scenes which can be problematic at times. I also just don't like async much :p

Note that performance benches are outdated, there are a handful of spots I acknowledge are not optimal for now. Moderate performance hit.

For performance, version stability, or developer maintenance seek elsewhere. This is a hobbyist project done with my little free time

Additionally, I am currently seeking help with implementing tls support as I have little Idea what I am doing. I have a very naive implementation but am uncertain how to test it or if it is even correct in any sense. contributors welcome. This is not my main focus right now however.

[boreal otter]

Interesting, I haven't seen web frameworks without async in Rust before.
I have a couple (probably dumb) questions:

• Does it not block when receiving/writing the tcp data to the client?
• What if I wanted to run async code such as a db query within one of my routes?

[twilit tide]

Yes it blocks in those cases though note set_timeout which allows for a more polling like interface, though those are rarely user facing. Performance impact is mostly negligible as the threads are yielding and cooperative.

Running async code would require some kind of executor. futures::block_on or the such. This lib stems from my hate of async interface pollution.

Take for example Layer from tower which has multiple complex types and requires the implementor to poll itself.

In cooperative synchronous code this can be done with much simpler types and cleaner interface. This framework is for ergonomics, performance is not the highest priority.

Note: The main branch is far ahead of crates release.

New router
websocket
Url parameter support

view the changelog on github for a full list.

[boreal otter]

I can definitely understand and agree about your frustration with async in Rust. Without async, things are absurdly more simple.

I (along with some others) built a non-async web library in Rust, but depends on a Wasm VM (built on top of Tokio) to keep the async performance but with non-async code.
https://github.com/lunatic-solutions/submillisecond

[twilit tide]

similar interface, however I don't like the router macro. just preference.

what is the performance of this in comparison to per say axum as a baseline?

[boreal otter]

Yeah it was kind of one of our only options to use a macro, because of the way lunatic works, every request is a separate "process" or actor, and so to avoid the overhead of sending the entire router to every request we use a macro to generate a function, so only a function pointer is sent

[twilit tide]

why not just pass by reference? or Arc

both very cheap or equivalent options if the Router isn't mutable at runtime

[boreal otter]

I'm well aware, but lunatic is a runtime similar to beam, where data isn't shared whatsoever, so anything passed between processes needs to be serialized/deserialized

[twilit tide]

oh? how would endpoints that require db access or mutable types from an endpoint work

Foxhole [0.4.0] Ergonomic web framework

[boreal otter]

The runtime keeps resources such as tcp connections that can be shared to processes

[twilit tide]

i am confused how these types of data can be shared but a reference or pointer to a router can not

[boreal otter]

It's a webassembly runtime

So it doesn't quite have the same rules as regular Rust