New web api framework called darpi

Hi folks,

I am trying to create a web framework that is focused around safety and performance.
While there are great frameworks out there, Actix and Rocket, to name a few.
I think, there is room for another point of view.
My goal is to design a framework that absolutely every (possible) error will be a compilation error and refer to macros, rather than storing dynamic collections.
This framework is in it's absolute infancy and i would appreciate some feedback so i can improve it and eventually make it a viable alternative to the status quo.

As Linus said, talk is cheap, show me the code.
Here it is.

Middleware and handlers are defined as simple functions.
Those are linked by macros. The majority should be normal code and macros are part of my design
only when there is absolutely no alternatives.

#[derive(Eq, PartialEq, Ord, PartialOrd)]
enum UserRole {
    Regular,
    Admin,
}

#[middleware(Request)]
async fn access_control(
    user_role_extractor: Arc<dyn UserExtractor>,
    p: &RequestParts,
    expected_role: Expect<UserRole>,
) -> Result<(), Error> {
    let actual_role = user_role_extractor.extract(p).await?;

    if expected_role > actual_role {
        return Err(Error::AccessDenied);
    }
    Ok(())
}

#[handler(Container, [access_control(Admin)])]
async fn do_something(p: Path<Name>, payload: Json<Name>, logger: Arc<dyn Logger>) -> String {
    let response = format!("{} sends hello to {}", p.name, payload.name);
    logger.log(&response);
    response
}

The access_control(Admin) reference to the middleware, inside the handler, is what links this middleware to the handler and injects the Expect<T> middleware argument.
This provides a simple, type safe and convenient way of passing values around from the handler to the middleware. You can very easily create another handler with different access requirements and define it as access_control(Regular).

1 Like

Speaking as someone who knows nothing about web frameworks, what's an example of a condition that would be a run-time error in Actix/Rocket/etc. but is caught at compile time by darpi?

Well, there are many things but to name a few,
You can register more than one handler for the same route, which you should not be able to do. You can have a path type in your handler's argument, which should extract variables from the path. If you don't define your route with path variables but you have a path in your handler, it will be a runtime thing. They are also heavily utilising the Any type.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.