Abstracting TypeORM to Support Multiple Database Providers

[tnramalho]

Use case

Rockets is designed to be flexible, but some modules uses TypeORM has default, that limit its ability to be fully ORM-agnostic. While Rockets itself is not tightly coupled to TypeORM, several modules import TypeORM classes, making it harder to use other database providers seamlessly.

Some examples of these references include:

nestjs-cache → import { Repository } from 'typeorm';
nestjs-crud → import { DeepPartial, ObjectLiteral, Repository } from 'typeorm';
nestjs-federated → import { Repository } from 'typeorm';
nestjs-file → import { Repository } from 'typeorm';
nestjs-invitation → import { Repository } from 'typeorm';
nestjs-org → import { Repository } from 'typeorm';
nestjs-otp → import { DeepPartial, Repository } from 'typeorm';
nestjs-report → import { Repository } from 'typeorm';
nestjs-role → import { Repository } from 'typeorm';
nestjs-sample → import { DataSource, FindOneOptions } from 'typeorm';
nestjs-typeorm-ext → import { DataSource, DataSourceOptions } from 'typeorm';
nestjs-user → import { Repository, MoreThan } from 'typeorm';
typeorm-common → import { EntityManager, Repository } from 'typeorm'

This default dependency makes integration with other ORMs such as Prisma, MikroORM, Knex, or Drizzle labor intensive.

Additionally, Rockets heavily relies on @nestjsx/crud, which is designed specifically for TypeORM. This raises another question:

• Should we accelerate the fork of @nestjsx/crud that is already in progress and develop crud services for additional ORMs?

Proposal

Proposed Discussion Topics

1. Abstracting the database repository layter to Support Multiple Database Providers

How can we provide more default ORMs in Rockets and allow developers to choose their preferred database provider? Some possible solutions:

• Introduce an abstract repository layer to provide a common interface for database interactions.
• Develop adapters for different ORMs (e.g., Prisma, MikroORM, Knex).
• Provide additional services in Rockets modules that support other ORM libraries.

Key Questions:

• Should we default to TypeORM but allow flexibility, or go ORM-agnostic from the start?
• How do we handle migrations and schema generation for multiple ORMs?
• How do we ensure backward compatibility for existing Rockets modules?

2. Handling @nestjsx/crud Dependency

Since @nestjsx/crud is deeply tied to TypeORM, we need to decide:

• Should we accelerate the fork that is already in progress and develop crud services for additional ORMs?
• Are there existing solutions that already solve this problem?

Key Questions:

• How much effort would be needed to accelerate the fork of @nestjsx/crud?
• If we introduce an abstraction, how do we design it to allow seamless integration with different database providers?

Timeline for Decisions

To ensure an organized transition, we should set a rough timeline for making these decisions:

• Discussion Phase: Collect feedback from the community and analyze existing ORM-agnostic solutions.
• Proposal Draft: Define a concrete strategy (forking, abstraction, or hybrid approach).
• Implementation Plan: Start implementing the selected approach while ensuring backward compatibility.

[MrMaz]

1. NestJSX Crud is already abstracted from TypeORM. It supports any ORM, but only provides one adapter out of the box.
2. I am already working on a fork of NestJSX crud on my local. The first part is done, which is bringing the Typescript standards up to Rockets standards.