Moving from TypeORM to MikroORM

[olivermrbl]

Hi everyone.

As some of you already know, we started moving toward MikroORM as the default ORM of Medusa.

This post intends to provide an overview of the reasons for the change, why we chose to go with MikroORM, and how our new ORM implementation will differ from the current approach.

Why are we changing ORM?

There are numerous reasons behind our decision to move away from Typeorm, some technically grounded and others relating to maintainability.

Here are three of them:

Lack of responsiveness and maintenance

We have been using Typeorm for nearly three years and have generally been satisfied with what the project has helped us achieve. However, it appears that the core maintainers of the package are becoming less attentive than before. Issues are going unanswered, pull requests are left hanging, and upgrades are breaking without documentation.

The last minor upgrade caused a range of business-critical issues that we reported and offered to help fix. Only a few of these were addressed by the core Typeorm team, even though the issues effectively made Typeorm unsuitable for production use, provided you want to use specific features.

Serverless portability

In April, we introduced the concept of Modules, which are self-contained pieces of code that can run independently from the main core application e.g. in serverless environments or edge functions. Some of these environments come with constraints around bundle size, e.g. the maximum size for a Vercel Edge Functions is 1mb on the Hobby Plan. Thus, going forward, we’ll have to be cautious about our choice of libraries to ensure they never become a limiting factor for the portability of our commerce modules.

The bundle size of Typeorm is very large, because all functionality, database drivers, CLI, utils, etc. are bundled in one package. Therefore, in our quest to make Medusa portable to modern environments, moving away from Typeorm was inevitable.

Timing

It is very rare, you get the opportunity to rethink your ORM and data layer. The modularization of our core is one of those rare occasions, and we are leveraging that opportunity to build a more robust and flexible foundation for the future.

What made us choose MikroORM?

When choosing our next ORM we were split between a lightweight query builder and a fully-fledged ORM. Ultimately, we decided to with the latter to avoid having to build a lot of ORM-type APIs ourselves and because of its familiarity with the core team.

The default ORM in Medusa will be MikroORM](https://mikro-orm.io/).

Our reasoning for going with MikroORM specifically is fairly trivial.

Syntax

MikroORM is syntactically similar to Typeorm, making the migration more seamless for our core team, users, and developer community. See the examples below.

Defining an entity

// Typeorm
@Entity({ tableName: "product" })
class Product {
  @PrimaryKey({ columnType: "text" })
  id!: string

  @Property({ columnType: "text" })
  name: string
}

// MikroORM
@Entity()
export class Product {
  @PrimaryKey({ type: "string" }
  id: string = "";

  @Property({ type: "string" })
  name: string;
}

Using repositories

// Typeorm
const productRepository = entityManager.getRepository(Product)

const products = await productRepository.find({ where: { name: "..." }})

// MikroORM
const productRepository = entityManager.getRepository(Product);

const products = await productRepository.find({ name: "..." });

In addition to having a similar syntax, this project seems to be very actively maintained (with response times of less than a day), and the bundle size is kept small enough to ensure it won’t be an issue for portability to serverless environments.

These three arguments constitute the reason for going with MikroORM.

What will we be doing differently?

In our current implementation, Typeorm is tightly coupled with our repository layer. This means that replacing Typeorm would require a tremendous amount of work, to the extent of being almost impossible.

This tight coupling is somewhat contradicting what we want to offer developers. Developers using Medusa should be equipped with a strong tooling comprising highly customizable and extensible primitives. If your product is better off with a different ORM than what Medusa ships with by default, you should be able to replace this without jumping through hoops.

Introducing a DAL

As we replace Typeorm, we will create a data access layer (DAL), defining a set of generic methods to query data from your chosen data store. The DAL separates the business logic from the ORM. It serves as a contract for what you will – as a minimum – have to implement if you wish to switch out the default ORM or connect to an entirely different type of storage provider. This allows developers to choose the ORM that best fits their needs.

We are excited about the new DAL implementation because of its flexibility and hope to see new use cases of our modules as we open up the underlying data layer.

What will this mean for your setup?

The migration away from Typeorm to MikroORM will happen in parallel with breaking down our entire architecture into modules, that are shipped independently from the core in separate npm packages. This approach will make the migration long-lasting and, hopefully, much less painful for projects that have extended the data layer with custom repositories and schemas.

We are still in the early stages of separating our modules from the core, and there is still a lot of work to be done on our side before you have to think about migrating your customizations. When the time comes, we will provide a thorough walkthrough, taking you through the migration in the most seamless way possible.

Finally...

...as always, we appreciate your feedback and input. Please don’t hesitate to ask questions or voice concerns about our move away from Typeorm. We will address them to the best of our ability.

[octalpixel]

@olivermrbl Just a sudden train of thought. Since there is ORM switch, is there any capacity within the team to inject the store_id across all the models ? So moving forward if anyone want to implement multivendor/marketplace can just work on extending the relevant services only. Your team knows best on where the store id would be relevant for the use case.
CC: @adrien2p

[robodove]

Voicing a concern here: Mikro ORM is owned by a single person who owns ~90% of contributions
As can be seen here

While it is certainly sometimes frustrating to work with, prisma is maintained by dozens actively and hundreds occasionally

With extensions such as Prisma-Multischema (which is quite simple and could be forked if the owner of that repo ever goes dark)
Extending base objects (medusa entities) is relatively easy and the DX of working with prisma is quite unmatched in the nodejs space

Your comment suggests that there will be a DAL in the future, do you have any roadmap for that?
We went with Medusa for our ecommerce store and i want to make sure this can scale with our needs

[octalpixel]

Prisma has its limitations when working on the edge. Medusa is moving towards serverless/edge direction with their modules system. I belive using Prisma might cause some challenges on this scenario.

Having said that Prisma has been my go to ORM for all the projects so far due to DX.

[octalpixel]

Thinking out loud, i believe that with the implementation of the DAL , there might be community driven projects to use Prisma as the ORM of choice.

[robodove]

Thinking out loud, i believe that with the implementation of the DAL , there might be community driven projects to use Prisma as the ORM of choice.

That's my point, i would immediately create a prisma adapter if there was a DAL

Especially important since we could reuse the types from the prisma schema on our frontend too

[rickylabs]

Have you given thought to Drizzle (https://orm.drizzle.team/)?

While community DAL implementations are suitable for small to mid-sized projects, larger enterprises often lean towards official implementations to ensure long-term support. When businesses invest in an e-commerce solution, one of the first things they evaluate is the underlying technology. If they already have in-house expertise with the chosen ORM, it's a significant advantage. Otherwise, they might need to re-evaluate their decision.

It's crucial for Medusa to make a well-informed choice regarding its default ORM, keeping these considerations in mind.

I'm merely voicing my concerns, and I hope the Medusa team will take these points into account. On a side note, I haven't had the opportunity to experiment with MikroORM yet.

[octalpixel]

Definitely relate to your sentiments! Especially when making custom integrations.

@olivermrbl would love your thoughts on whats happening in the roadmap for this one.

[olalonde]

Any update on this? I would strongly recommend going for Prisma, though it's more of a query builder than an ORM. It's very mature and has a large community. I've tried about every JS ORM out there and it's miles ahead of the competition.

[olivermrbl]

Hi @olalonde, as mentioned in the original post, we decided to go with MikroORM as the replacement for Typeorm a while back, due to the similarities in their API and general syntax.

Are you looking for an update on something else related to this?

[chemicalkosek]

Even thought I use Prisma for all of my projects, it has some shortcomings that make it not feasible to use with Medusa.

The most important would be lack of soft deletes (which are used by Medusa).
Relevant thread: prisma/prisma#3398

[rickylabs]

Prisma just dropped support for serverless database:
https://www.prisma.io/blog/serverless-database-drivers-KML1ehXORxZV

They're working on Cloudflare Worker and Vercel Edge Function support, Medusa team should ask for early access:
https://pris.ly/survey/driver-adapters-serverless-blog

[appauldev]

Hi! For those who are suggesting using Prisma, I think Prisma has still some challenges to overcome when it comes to implementing performant SQL JOIN operations as indicated in this issue in their repo (which has been opened for 2 years already). But the Prisma team is actively working on this issue.

[reigeneric]

Nevertheless, it's a great decision. There is a top one problem that one was created by one guy. As you know underbox of the mikro-orm is knex query builder. The knex is awesome. In fact, the mikro-orm supports to do some jobs easier (crud operations, joins, etc.).

[Coachonko]

Would rather raw SQL tbh. Migrating ORM is no joke, your application is large and relatively complex, what is the likelihood you'll have to do this again in the future? Especially considering the concerns that other people have brought up: mikro-orm is mostly developed by a single individual.
Just write plain SQL, you're supporting Postgres alone anyway in production, you're not going to see users migrate across DBMS anyway.

[Julian-Dumitrascu]

We want similar things when choosing a provider.
For instance, I'd like to build a dialogue with you, which includes planning together.
I share what we want to achieve; you share what you'd do to help us achieve our goal: building a marketplace.

[geekyayush]

I have gone through like 5-6 threads (reddit/github) regarding which is the best ORM. Most of them are saying Prisma is not a good ORM due to the basic things being missed. and it's quite heavy compared to other ORMs like Mikro-orm and Drizzle.

So I guess choosing Mikro over primsa would be a good choice.

Also for reference, here are the ORMs or query builder I have looked at:

• https://mikro-orm.io/
• https://kysely.dev/
• https://orm.drizzle.team/

PS: I have been using TypeORM for over 4 years now. It's great but not really being updated (just stable) and TS support is not that great.
I am thinking of moving from TypeORM to Mikro for one of my projects.

[undercontr]

Is there any plan to support other databases like MongoDb or MySql? I see that MikroORM does support many database

[adrien2p]

When the modules are isolated they can use a different database, and the database is configurable. So in the future it is likely that you will be able to do that yes. Also, replacing the data layer will allow lot of flexibility for customisation around specific providers

[undercontr]

I see, so it would be not possible to provide like a plugin to add a different provider to Medusa right?

[MicahBCode]

@adrien2p Is there any timeline on when the modules are isolated/the DAL will be implemented? What's the current state/percentage? I would be highly interested in contributing to this since I plan to adapt it to mysql/mariadb. The reason for that is I don't want to introduce another db provider into our environment.

Let me know If you have something for me :)

[undercontr]

For reducing the costs of the production users of the Medusa and to have a wider data support, I suggest implementing MongoDb compatibility to the Medusa. I see that MikroORM have a relatively different API for MongoDb, I don't know the possibilities of implementing MongoDb (I think data types are different), but I'm ready to provide help about that too. I can work on it if it's needed :)

[MicahBCode]

What is the current state of this process? How is the isolation of the modules coming along? I'm very anticipated to contribute to the support of different database drivers other than PostgreSQL.

[rk12129]

Thanks for the amazing work you guys are doing, would really love to know if you have any updates on this.