Installation of MikroORM

01-installation.sh

# using yarn
$ yarn add mikro-orm mongodb # for mongo
$ yarn add mikro-orm mysql2  # for mysql
$ yarn add mikro-orm pg      # for postgresql
$ yarn add mikro-orm sqlite  # for sqlite

# or npm
$ npm i -s mikro-orm mongodb # for mongo
$ npm i -s mikro-orm mysql2  # for mysql
$ npm i -s mikro-orm pg      # for postgresql
$ npm i -s mikro-orm sqlite  # for sqlite

02-tsconfig.json

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es2017",
    "moduleResolution": "node",
    "declaration": true,
    "strict": true,
    "strictPropertyInitialization": false,
    "experimentalDecorators": true
  }
}

03-initialising.ts

const orm = await MikroORM.init({
  entities: [Author, Book, BookTag],
  dbName: 'my-db-name',
  clientUrl: '...', // defaults to 'mongodb://127.0.0.1:27017' for mongodb driver
  type: 'mongo', // one of 'mysql', 'postgresql', 'sqlite', defaults to 'mongo'
  autoFlush: false, // read more here: https://b4nan.github.io/mikro-orm/unit-of-work/
});

console.log(orm.em); // access EntityManager via `em` property

04-forking-entity-manager.ts

const app = express();

app.use((req, res, next) => {
  req.em = orm.em.fork(); // save the fork to `req` object
});

app.get('/books', async (req, res) => {
  const books = await req.em.find(Book); // use the fork via `req.em`
});

05-providing-request-context.ts

const app = express();

// by providing request context, creating forked EntityManager will be handled automatically
app.use((req, res, next) => {
  RequestContext.create(orm.em, next);
});

I'd like to add my 5 cents about interface of MicroORM.init object. I'd allow people to decide whether to store all entities in a single folder or to store entities per module (very often it's much to easier to start project as monolith with module/feature system, and later migrate to microservices if there is a need). Also you can take a look at this Node.js best practices - https://github.com/i0natan/nodebestpractices/blob/master/sections/projectstructre/breakintcomponents.md

I don't say that grouping files by their role is bad, it just doesn't work well for big apps, especially if you follow Single Responsibility principle.

So, my suggested API is:

const glob = require('glob')

const orm = await MikroORM.init({
  entities: glob.sync('./src/entities/**/*.js').map(require),
  dbName: 'my-db-name',
  clientUrl: '...', // defaults to 'mongodb://localhost:27017' for mongodb driver
});

This way you allow people to decide whether they want to load everything automatically or manually and can reduce responsibility of the lib by delegating some stuff to others (like node-glob).

Well it's an array, so you are free to use multiple folders. I will think about allowing something like entities array, but not sure if it can work with the TypeScriptMetadataProvider, as I need to analyse TS source files to know all types (that is what the entitiesDirsTs is for).

I was already trying to get around this and parse the tsconfig.json to be able to get to source file without specifying entitiesDirsTs, but it is not that easy (no universal way). I could also scan the whole project based on tsconfig.json, but that is much slower than the current approach (even though I have caching in place now, so it would be one time only delay).

@stalniy After few hours of thinking and prototyping, I found a way to get around this and provide the API you suggested. Take a look at mikro-orm/mikro-orm#18 :]

I also removed the need for entitiesDirsTs, using tsconfig.json by default. It is a bit slower but one can still use entitiesDirsTs to make it faster.