Refactoring service classes to improve cross service usability.

[JustSamuel]

In this pull request I also refactored the service class, since it was long over due.

However, given that I wrote quite a lot of the current service classes they mostly have the same issues. Service files / classes should only consider database entities, it is up to the controller to turn this entity into a response.

This prevents the issue I had where you go from service -> response -> back to an entity. Wasting database queries and muddling up the code.

A following issue that I found is that there is a sneaky form of code duplication. Namely that we use User.find() in quite a lot of places, and do not use the UserService. Which is fine, however, lets say we want to implement account expiry we would have to refactor a lot of places just to add something along the lines of expired: false to the find options.

Another code smell this solves is the .records being used because most service functions return a paginated response, meaning we are wasting computing power on creating pagination just to throw it away.

To solve this I propose the following:

• Service classes should never return Response, but entities instead.
• Each entity should have a service class with a getOptions function handles creating the TypeOrm FindManyOptions for this entity. (This would solve the User issue by turning the User.find() into a User.find(UserService.getOptions()) , which would contain defaults regarding delation, expiry etc.)
• Controllers are responsible for turning entities into responses.

[Yoronex]

Another code smell this solves is the .records being used because most service functions return a paginated response, meaning we are wasting computing power on creating pagination just to throw it away.

This is not true, because when you do not give any pagination parameters, pagination is not actually applied.

[JustSamuel]

This is not true, because when you do not give any pagination parameters, pagination is not actually applied.

I am still of the opinion that .records is smelly, .records[0] is also super ugly.

[Yoronex]

Then maybe as a middleground, we can implement a response like TypeORM does with .findAndCount(). I think that looks quite neat.

[JustSamuel]

Note that this refactor per service should also include moving to a class "manager" and away from the global TypeORM manager.