Decorators for Command Handlers and Authorizers

[samhatoum]

The @Handler decorator

Today we have command handlers, which use the @Handles(Command) decorator to become handlers of a given command. In these command handler function there are 2 repeating patterns of code that do the following

1. Create OR load an aggregate root.
2. Call a method on the aggregate root that usually matches the command name, passing it the parameters from the command.
3. Then we either save the events and return an Ack, or return a Nack with the error.

Given that the above formula is typical for the majority of cases, we can omit a lot of boiler plate using annotations on the command itself. Something like this:

@Handler(FooAggregate, Strategy.LOAD)
class DoSomethingCommand() {
  //...
}

This would create a command handler behind the scenes that would look like this:

  @Handles(DoSomethingCommand)
  async doSomething(command: DoSomethingCommand): Promise<Error | void> {
    const aggregate = await this.repository.getById(command.aggregatId);
    if (!aggregate) return Errors.NotFound(FooAggregate);
    if (!aggregate.doSomething(command.aggregatId)) return aggregate.getError();
    await this.repository.save(aggregate);
  }

Should you want to do something more specific, you can always write your own handler and use the @Handles decorator as normal.

The @Authorize decorator

Similarly, an @Authorize decorators can be used on commands directly, here are some of the different scenarios that should cover most – if not all the cases.

Basic Authorization

We could have a simple decorator that ensures only authenticated users can trigger certain commands.

@Authorize
@Handler(FooAggregate, Strategy.CREATE)
class DoSomethingCommand {
  //...
}

Role-Based Authorization

Extending the decorator to accept roles could help in ensuring that only users with certain roles can execute specific commands.

@Authorize(['admin', 'superadmin'])
@Handler(FooAggregate, Strategy.CREATE)
class DoSomethingCommand {
  //...
}

Configurable Authorization Rules

By utilizing decorator factories, we can create customizable authorization decorators. This would provide a flexible way to enforce complex authorization rules based on various criteria.

@Authorize({roles: ['admin'], permissions: ['delete']})
@Handler(FooAggregate, Strategy.CREATE)
class DoSomethingCommand {
  //...
}

Function-Based Authorization

We could enable passing of authorization-checking functions to the decorator, allowing for complex, logic-based authorization checks.

@Authorize(isUserAdmin)
@Handler(FooAggregate, Strategy.CREATE)
class DoSomethingCommand {
  //...
}

These decorators would work hand in hand with the @Handler decorator setup, making authorization checks more declarative and reducing boilerplate.

[rami-xspecs]

I am happy with the proposed @Hanlder implementation as it will simplify and get rid of a lot of boiler plate code.

My thoughts on the the @authorize decorator: The proposed implementation for basic and Role based handlers is very good. For configurable Authorization rules, I would prefer to introduce Claims and Policy based Authorization where a developer can register any Authorization policy and claims for any custom requirement. Example: [Authorize(Policy:['delete']] where the developer registered policy for 'delete' would kick in. Or suppose database roles are used instead of token based roles, a developer can register an Authorization policy for [Authorize(Policy:['admin']]