TypeORM takes longer to connect in NestJS than normal

I’m submitting a…

[ ] Regression 
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

TypeORM’s createConnection takes longer to run in NestJS than when you run it on its own. For me it normally takes 2x or longer than it takes outside NestJS.

To test this I edited createConnectionFactory in node_modules/@nestjs/typeorm/dist/typeorm-core.module.js to add var dd = Date.now() before the return yield and the following after .toPromise():

  .then(data => {
    console.log(`finished connection +${Date.now() - dd}ms`);
    return data;
  });

The result for me is:

finished connection +13894ms
[Nest] 25686   - 10/08/2019, 2:48 PM   [InstanceLoader] TypeOrmCoreModule dependencies initialized +13797ms

Tweaking the code to remove the .pipe(typeorm_utils_1.handleRetry(options.retryAttempts, options.retryDelay)) and remove the RxJS code does not significantly change the timing.

To confirm this is a NestJS issue and not a TypeORM issue, I wrote the following script:

import { createConnection } from 'typeorm';
let dd = Date.now();
createConnection({
  type: 'mariadb',
  host: '127.0.0.1',
  port: 3306,
  username: 'root',
  password: 'password',
  database: 'myproject',
  charset: 'utf8_general_ci',
  entities: [process.cwd() + '/**/*.entity{.ts,.js}'],
  migrations: [process.cwd() + '/migrations/*.ts'],
  synchronize: false,
  logger: 'debug',
})
  .then(conn => {
    console.log(`Completed in +${Date.now() - dd}ms`);
    conn.close();
  })
  .catch(console.error);

This is a typeorm createConnection with the exact same options as NestJS passes createConnection with my config.

My results are:

$ npx ts-node -r tsconfig-paths/register ./test.ts 
Completed in +6422ms

Expected behavior

TypeORM’s createConnection should not take longer in NestJS than it normally takes in ts-node.

Minimal reproduction of the problem with instructions

I’m not sure I can build a minimal reproduction. The performance difference only becomes perceptible when you have a large application.

Environment

Nest version: 6.2.0, @nestjs/typeorm 6.1.3

I’ll try and upgrade later and see if anything is different. But this has been an issue for awhile and I didn’t notice anything performance related in the release notes.

[SylvSylv]

I’ve had the same problem for quite some time, and I tried to load entities directly as suggested by @kamilmysliwiec

MyEntitiesFolder 
|-- Client.entity.ts
|-- Entry.entity.ts
|-- Invoice.entity.ts
|-- MyBaseEntity.entity.ts
|-- Payment.entity.ts
|-- PaymentMethod.entity.ts
|-- Settlement.entity.ts
|-- User.entity.ts
|-- Vat.entity.ts

const configWithHarcodedEntities: TypeOrmModuleOptions = {
  ...configService.getTypeOrmConfig(),
  entities: [
    Client,
    Entry,
    Invoice,
    MyBaseEntity,
    Payment,
    PaymentMethod,
    Settlement,
    User,
    Vat
  ]
}

@Module({
  imports: [
    RouterModule.forRoutes(routes),
    TypeOrmModule.forRoot(
    //   configService.getTypeOrmConfig() //classic ormconfig.json with **/*.entity{.ts,.js}
      configWithHarcodedEntities
    ),
    CrudModule,
    JsonapiModule,
  ],
  controllers: [AppController],
  providers: [AppService],
})

Results

load entities directly:
TypeOrmCoreModule dependencies initialized +68ms
with glob path:
TypeOrmCoreModule dependencies initialized +20000ms - +30000ms

After that I used a more targeted glob path:

{
    ...
    // entities: ['**/*.entity{.ts,.js}'],
    entities: ["src/modules/domain-invoice/*.entity{.ts,.js}"],
}

And loading time was still very small:
TypeOrmCoreModule dependencies initialized +122ms

Hope it helps.

[kamilmysliwiec]

I don’t think this is related to the @nestjs/typeorm implementation specifically. If you look at the source code, you’ll see that not too much really happens around the “native” createConnection function. I’d suggest removing glob paths (both entities and migrations) and load entities directly, then compare the performance - perhaps that’s the place where the issue comes from. Also, one thing to note is that Nest resolves all dependencies asynchronously, so if there are lots of synchronous operations to perform, the timestamp difference will be higher. Although, it doesn’t mean createConnection() took longer, but rather the JS engine couldn’t call the callback yet.