Dbconnection

[waltervan00]

Personal observations

I would like to bring attention to api-router.ts where the database models are meant to be generated.

Models generated within this file are bound to individual api Handlers through the bind method. Hence for each ApiRequestHandler type, the model can be accessed through this.<model property in api-router.ts>.

Is this an intended outcome? For each new model required it would have to update this class. So far we have a User model and nothing else. But in terms of extending the DB model for further collections, how do you think this will interact?

[chomosuke]

I think the answer is Yes. Looking at server.ts, all routes starting with /api will be routed to ApiRouter. After that ApiRouter will direct each route to their corresponding handler, and presumably pass all the models to each handler as well.

this.<model property in api-router.ts> wouldn't work for now I think because userModel at least in ApiRouter is private.

However it's probably a good idea to get the author of this code which is @shangzhel i'm assuming to clarify and confirm on this issue.

[chomosuke]

After some test, I've successfully made the collection appear on my Compass by inserting an document into the collection. I was expecting the collection to appear straight away after db.model but I guess this works too.

Everything else looks good to me too.

[shangzhel]

But in terms of extending the DB model for further collections, how do you think this will interact?

Indeed it is not perfect in terms of extensibility. The Mongoose models could be exposed through property getters, and the getters themselves located in an interface so that the ApiRequestHandlers do not depend directly on the ApiRouter class. For example:

In db-provider.ts

import { Model } from 'mongoose';

interface IDbProvider {
  get User(): Model<IUser>;
}

In api-router.ts

import { IDbProvider } from './db-provider';

class ApiRouter implements IDbProvider {
  // ...

  get User() {
    return this.userModel;
  }
}

I was going to make this change when I set up testing because the routes need to be testable without actually making a database connection in test cases.

[waltervan00]

But in terms of extending the DB model for further collections, how do you think this will interact?

Indeed it is not perfect in terms of extensibility. The Mongoose models could be exposed through property getters, and the getters themselves located in an interface so that the ApiRequestHandlers do not depend directly on the ApiRouter class. For example:

In db-provider.ts

import { Model } from 'mongoose';

interface IDbProvider {
  get User(): Model<IUser>;
}

In api-router.ts

import { IDbProvider } from './db-provider';

class ApiRouter implements IDbProvider {
  // ...

  get User() {
    return this.userModel;
  }
}

I was going to make this change when I set up testing because the routes need to be testable without actually making a database connection in test cases.

I could make these changes and make a new commit if you'd like.

[waltervan00]

@shangzhel Actually, considering that you'll implement that feature in CI. I will refrain from making these changes else we run into conflicts.

[shangzhel]

Let's leave this PR open until after the CI PR gets merged, then we can write unit tests before merging.

[shangzhel]

Needs a few fixes.

[shangzhel]

Move this property up to before the arrays.

[shangzhel]

Move this element down to before the fields value.

[shangzhel]

Rename property to match ITag interface definition.

[shangzhel]

Same as above, rename property to match interface definition.

[shangzhel]

Just one change, otherwise it looks good.

[shangzhel]

Move the initialization of the ICardField schema into another constant above like const cardFieldSchema = .... It does not need to be exported.

[shangzhel]

Don't know how your code got past the linter pre-commit hook, but I can fix it for you.

[shangzhel]

Looks good to me.