A derive-able enum API with permissions support.

[ecton]

I've been thinking about how to make permission handling as automatic as possible for consumers of PliantDb. Here's an idea of how to implement a derive-driven API with the permissions model:

/// Each "type" must implement Handler and have a "new()" method with exactly the same "parameters" the enum in question contains.
#[derive(Api)]
#[api(output = ResponseType, error = ErrorType)]
enum Api {
    #[handler = type]
    FunctionOne,
    #[api(handler = type)]
    FunctionTwo(String),
    #[api]
    FunctionThree{ param: String },
}

#[async_trait]
pub trait Handler {
    type Error;
    type Output;

    fn is_allowed(&self, permissions: &Permissions) -> bool;

    async fn execute(self) -> Result<Self::Output, Self::Error>;
}

pub trait ActionHandler {
    type Error;
    type Output;

    fn resource_name(&self) -> ResourceName;
    fn action_name(&self) -> ActionName;
}

impl<T> Handler for T
where T: ActionHandler {
    type Error = T::Error;
    type Output = T::Output;

    fn is_allowed(&self, permissions: &Permissions) -> bool {
        permissions.allowed_to(&self.resource_name(), &self.action_name())
    }

    async fn execute(self) -> Result<Self::Output, Self::Error> {
        self.execute().await
    }
}

struct FunctionThree {
    param: String,
}

impl FunctionThree {
    pub fn new(param: String) -> Self {
        Self { param }
    }
}

impl ActionHandler for FunctionThree {
    type Error = anyhow::Error;
    type Output = ResponseType;

    fn resource_name(&self) -> ResourceName {
        ResourceName::named(&self.param)
    }

    fn action_name(&self) -> ActionName {
        ActionName::from(MyActionsEnum::SomeAction)
    }

    async fn execute(self) -> Result<Self::Output, Self::Error> {
        todo!("Do something")
    }
}

In this example, the derive enum would generate an API implementation that takes an Api and a &Permissions. It would generate a match statement, and using the customizations noted, it would generate the glue code to initialize the handler, execute is_allowed, and if true, invoke execute.

I like this approach enough that I think I can dogfood the internal PliantDb Api itself off of this.

Any thoughts on this overall approach? This was written in a notepad, so the traits themselves may have some issues I didn't catch, but the general idea should be understandable.

[ecton]

For error handling, I think there should be an exported PermissionDenied error, and the Api-level Error type would need to implement From<PermissionDenied>.

[ecton]

One challenge in this approach is that these enums are meant to be defined in a shared crate that is included from both the client and server -- think of Cosmic Verge or PliantDb, both have a crate that defines the network types that the clients and servers include. The derive in this case would have to live inside of the shared crate, but that doesn't feel right. Feature flags might be able to make it workable, however.

I'm trying to figure out a way to allow the match statement and handler code all to live in the server crate and the enum in another crate, but without introducing a new enum that lives in the server crate, I'm not sure how to pull that off. Any ideas?

[ecton]

One slightly crazy idea is to have the derive trait in the shared crate generate traits that the server crate can implement. Then, cfg_attr could be used to disable the macro in the shared code when it's included from the client, and the server can have the traits to implement and the dispatcher generated when enabling the proper feature flag.