implement query and mutation actions

[Baumgaer]

Because we want to use DDD while development we should implement a mechanism which forces the developer to definitely use this architecture. To enforce this we have to implement two new decorators:

• [x] @Mutation() This changes or creates the corresponding model by returning the fields with the values as an object. To avoid raceconditions between fields which are dependant to each other (e.g. startTime, endTime and duration). This will be done at first locally and afterwards on the server if exists.
• [x] @Query() This queries data from the local database (at first) with taking care about conditional filters (standard where clause), paging, attributes and so on. If this was successfull we query the server if exists.

Each of this decorators should enforce to define access rights, an atomic action name (e.g. lock, unlock, getBooks, setBook and so on). The name could be determined by the transformer loke the transformer does it already for the fields. It also should take care about the return type.

To enforce type savety for the parameters given to the function decorated with this decorators. we should use another decorator:

• [x] @Arg() This determines the type of the argument at runtime with the transformer. The Type can be independant from the corresponding field because the decorated method can cast it to the right type.

• [x] Add access rights check to server and client

• [x] Extend transformer to inject at least the name of the action and the parameter into the decorator

  • [x] Write schemas for arguments and actions
    • [x] passed matedata has to be passed into an corresponding schema

• [x] Extend transformer to inject the name of the parameter

• [x] Extend transformer to inject the type of the parameter to be able to check the type on server side

• [ ] https://github.com/Baumgaer/boilerplate/issues/37#issuecomment-1300667095

[Baumgaer]

This hase to take care about #15

[Baumgaer]

We should care about type-graphql to be able to switch fast to it in case this idea her isn't that good.

[Baumgaer]

After testing a little bit I came up with the following solution:

@Mutation({ name: "changeName", accessRight: () => true })
public changeName(@Arg() name: string) {
    this.name = name;
    return this.save();
}

@Query({ name: "queryDeletedNames", accessRight: () => /*some other magic here*/ true })
public queryDeletedNames(@Arg() conditionalDate: Date) {
    return (this.constructor as typeof Example).find({ select: ["name"], where: { deletedAt: conditionalDate } });
}

As we can see the name of the action corresponds to the methods name most times. So the name should be optional in case it's really different from the methods name. We can pass the name of the action during transformation.

Every action should perform its own procedure locally and NOT call a server. this will be done in the model class by getting the arguments decorated with the @Arg() and will build the corresponding query or mutation.

[Baumgaer]

The decorators are already implemented but we have to:

• [x] refactor
• [ ] fully implement the ApiClient
• [ ] Attributes have to be mirrored to the other model in case they are relations
• [ ] mutation is reverted in case of error
• [ ] write tests

to be able to use it completely.