#[update] snowboard πŸ‚: simple library for fast HTTP[s] servers

71 messages Β· Page 1 of 1 (latest)

quick fog
#

so a while ago i made a smol library for web servers without hyper and posted it here, but since then a lot of changes have been made (including new features and reaching 1.0.0)
repo: https://github.com/Brian3647/snowboard
any feedback / stars / recommendation would be appreciated since it's the first time i build an actually useful library for rust ferristhumbsup

GitHub
GitHub - Brian3647/snowboard: Extremely simple http rust servers :s...

Extremely simple http rust servers :snowboarder:. Contribute to Brian3647/snowboard development by creating an account on GitHub.

echo copper
quick fog
#

it is simpler imo which is something i like

#

and avoids too much layers of abstraction like hyper

#

50Β΅s is an absurdly small amount of time

echo copper
quick fog
quick fog
echo copper
#

Also I love simplicity as well but are there any other like strong reason like you would suggest which might not be there in other projects or something that makes it truely unique to your project like for example a strong focus on security, any other thing strong reason ? Would love to hear πŸ™‚

quick fog
#

Actix offers easier body & query parsing whereas snowboard offers less abstraction for more freedom of use

#

Not saying you can't do things on actix but it's clearly designed to be way more easy to use

#

Snowboard is simplicity

#

Also, I think snowboard can be faster than actix with some changes

#

Currently it's using std::net::TcpStream but I think that if I switch to a non-blocking alternative like async_stds the performance would be way better

#

Also the request parsing could be slightly faster, even tho it's already extremely fast

echo copper
#

So basically your project would be like the core which you can call it snowboard-core then there could crates like snowboard-serde, snowboard-rate-limit, etc. That's my idea. What do you think?

quick fog
# echo copper Ok I see, maybe I think now I have a suggestion maybe you could make the project...

Something I do like about snowboard is that I made ResponseLike, which is an extremely useful trait. For example:

async fn handler(request: Request) -> Result<Response, Response> {
    let example = middleware(request)?; // automatically returns on failure
    ...
}

fn middleware(req: Request) -> Result<(), Response> {
    if request.method == Method::DELETE {
        return Err(response!(method_not_allowed));
    }

    Ok(())
}
#

I've been testing and the use of Result<Response, Response> implementing ResponseLike makes middleware 0-config

#

Rust has a p good way to handle ? so it works wonders

echo copper
quick fog
#

It does actually
You can freely implement ResponseLike for anything you want

#

In the readme iirc I wrote an example

#

I'm on mobile rn so I'm just guessing links lol I hope that one works

echo copper
quick fog
#

why? The project isn't even that big

#

and responselike is literally a single-file thing

echo copper
# quick fog why? The project isn't even that big

I think it will give more freedom to the user like they can implement their own 'ResponseLike` trait from scratch which can also allow for more diverse implementation to also exists as well. What do you think?

#

In terms of maintainability this will reduce the lines of code from the main project which can also prove beneficial for maintaining the project too.

quick fog
#

The issue with that is that if every single implementation of responselike is in a library it will have 2 problems:

  1. That library will have 18272728282 dependencies and it will probably become a feature mess
  2. People will still find things that aren't implemented
#

For niche specific cases I think it's just best to let the user implement it themselves

#

For example, markup implements different "ResponseLikes" of other libraries and that other libraries don't necessarily include markup

#

that's the code for responselike

echo copper
quick fog
#

I don't want to depend on Tokio i'd rather use async_std but yeah we can take a look at it

#

Tho that would mean removing the async feature since async will have to be used anyways

#

Please open an issue and we'll put some important info there if you want to

echo copper
quick fog
#

ty

#

I probably won't work on it truly until at least Thursday bc Christmas

quick fog
echo copper
#

I think this thread is getting too and off-topic so instead I have Dm-ed I hope it is fine for you? πŸ™‚

green compass
quick fog
#

its 0.00005 seconds

green compass
#

rather slow in my opinion

#

your 50ΞΌs slower

#

i could be spending those microseconds being useful

quick fog
#

my bad my bad

#

i forgot you can get a college degree in 50ΞΌs

ember sundial
#

How are you benchmarking?

ember sundial
quick fog
# ember sundial Why?

Bad wording, I meant to say it already uses async_std with the async feature and I already have worked with it so I don't want to change everything

quick fog
#

I'll do proper benchmarking, I also want to properly test request parsing times for requests and urls

#

If this gets a bit bigger I might consider adding it to techempower's benchmarks to compare it properly

quick fog
#

Note that I forgot to say before: the benchmarks are with the async feature on, with it off it's way slower

tardy vector
quick fog
tardy vector
#

I see myself using it, it quite has node http server vibe πŸ˜‚

quick fog
#

cool, any feedback is appreciated

tardy vector
quick fog
quick fog
quick fog
#

[update] snowboard πŸ‚: simple library for fast HTTP[s] servers

#

After giving up on this 2 years ago, i've managed to solve the underlying issue that kept me from progressing (blocking io) thanks to smol and async closures :3

#

It's been fixed with update 0.8.0

#

i'll be working some more on this