Use decorators/classes instead of handlers

[Bartozzz]

Our current system is quite nice when in comes to define default handlers and populate loaded files with initializer's instance:

app.addHandler("Router", function routeHandler(resource) { /* … */ });
app.addHandler("Middleware", function middlewareHandler(resource) { /* … */ });

app.addHandler("default", function defaultHandler(resource) {
  resource(app);
});

It has a few limitations:

1. Imported class and functions' names must respect a given naming convention. Right now, handlers can recognize imported files based on their suffixes only.

2. Sometimes, the default handler is not enough. E.g. it cannot handle both classes and functions, so we need two separate handlers for each case. In order to define a new resource type, we must define it's own handler directly in the bootstrap section.

3. Some (native) handlers use and modify app internals. Those handlers should not be overridden by any user-defined handler – right now it is possible by simply passing another function to .addHandler.

4. This is kinda an anti-pattern. Each file should be as much independent from the rest of the application as possible. Right now, each class in strongly coupled with inra-project-server and there's no easy way to migrate to another framework because of how handlers are implemented.

Proposal 1: decorators

@controller("/foo", …)
class FooRouter {
  @get("/", …)
  async read(ctx, next) {
    // …
  }
}

In this case @controller is a simple function which, once loaded, handles FooRouter and populates it with app.

Pros:

• Easy to implement and test;
• Populates the resource with app instance;
• Makes the resource more independent from the rest;

Cons:

• ~we have to define a new decorator for each resource type;~

Proposal 2: extending

This is a standard solution in languages such as PHP where there's no decorators.

class FooRouter extends Controller {
  @get("/", …)
  async read(ctx, next) {
    // …
  }
}

Pros:

• Standard way to go in other languages such as PHP;

Cons:

• Hard to populate resource with app instance?
• Have to use super() in each constructor – can lead to errors;