(Optional) Common Repository Abstraction

[Khongchai]

In the future, we might be getting the trees data from multiple sources. Having a common repository abstraction makes it easy for both the API users and the API creators. Having a fixed guideline for how 3rd-party databases helps maintain interface consistency and developers do not have to spend time nit-picking about the optimal API design.

This will need to be well-documented.

/**
 * TODO (big maybe, this might not be necessary at all, because we have the trpc router doing a bit of abstraction already.)
 *
 * When we connect to other open data repositories, having a common abstraction helps us switch between two
 * repositories at runtime and/or migrate to a new database repositorie. An ideal interface would be the common repository pattern.
 *
 * We might in the future have something akin to
 *
 * ```ts
 * class CommoRepository<T> {
 *      getAll(): Promise<T[]>;
 *      get(): Promise<T>;
 *      remove(): Promise<boolean | void>;
 *      ...
 * }
 * ```
 *
 * Then all repositories can extend this.
 *
 * ```ts
 * class SecondaryDatabaseService extends CommoRepository<T> {...}
 * class VallarisRepository extends CommoRepository<T> {...}
 * ```
 *
 * Then switching repositories is simply changing the name of the instance:
 *
 * ```ts
 * // from
 * const trees =vallarisRepository.getTrees();
 * // to
 * const trees = secondaryRepository.getTrees();
 * ```
 *
 */
const vallarisRepository = {
    baseURL: process.env.VALLARIS_ENDPOINT,
    collectionId: "6444e234b4b978478bef26f1",
    getTrees: async function (
        request: TreesRequestParams
    ): Promise<TreesResponse> {
...
``