Why does it have so low popularity?

[stalniy]

Hello there,

First of all, your project looks amazing! But I'm curious why is it not very popular on github? Is it produciton ready?

[B4nan]

Thank you! Well I never properly tried to promote the project, and to be honest I am still not very sure where to start :] I started to work on this because I moved from PHP (doctrine) and missed proper ORM in node world (was super pissed with typeorm as it lacks references). After few months I managed to start using it in one project, then few months of bug fixes followed (we have QA department where I work, so not just causally found bugs).

Early this year I started to refactor stuff to make it more robust (higher code coverage, improved docs, support for various databases, improved API, removed necessity of extending BaseEntity, ...), and I am planning to release v2 very soon (once #11 gets merged basically). Then I would love to try to promote it somehow/somewhere as I believe it is pretty much unique project in typescript/node world (have much better API than typeorm, which is I guess the only proper data mapper in node world currently).

I would say it is production ready, it powers 2 medium-sized projects now in production environment and everything works as expected (one of it uses it for about a year). Although, both are using MongoDriver (originally mikro-orm was mongo only ORM), so you could say SQL drivers are still experimental (but their code is fully tested).

[stalniy]

I experienced the same issues when looked through existing ORMs and query builders.

I suggest you to start from:

1. Publishing articles on Medium (create images for articles, otherwise it's hard to attract somebodies attention)
2. Suggest your articles to be published in JS/Node.js publications like DailyJS (you can do this on Medium, and they usually take them).
3. Create example repositories for common tasks and integrations with common HTTP frameworks (e.g., express, feathersjs, nestjs). Ask them to promote your articles. They will take them because by promoting your lib you also does this for them :)
4. Find nodejs/database communities in facebook/raddit/twitter and publish your articles there
5. Add "share" buttons on documentation
6. Register a tag for micro-orm on StackOverflow (if you don't have enough karma, I can do this for you)
7. Don't forget to publish articles when you do major updates in the codebase (like "What's new in Micro-ORM 2.0")

This is a rough list of action items which I did for my own project on github, you can take a look at https://github.com/stalniy/casl

I'm interested in this project because I want to build EavORM but don't want to reinvent the wheel. That's why I started searching for keyword "UnitOfWork" and this is how I found your project :)

P.S.: don't forget to create JS examples to cover more people (there are some who doesn't like static typing or don't want to complicate things on backend by introducing build tools)

[stalniy]

Also use commitizen commit styles and semantic-release package, it will make generate of CHANGELOG easier

[B4nan]

Thanks for the summary, much appreciated!

1. Do you think I should create MikroORM user for this, or can I just use my own medium account? Its empty anyway...
2. That is what I was thinking about last month, I would just like to release v2 first because it can get confusing when the docs say something that you do not get when simply installing without next tag.
3. Also something I was planning to do, I have experience with express, nestjs, restify and sails.js, never tried featherjs -- do you know others that are worth making a sample app?
4. Will need to investigate proper channels to promote it, I know about some twitter handles like JavaScript/TypeScript Daily, but nothing directly related to ORM/database...
5. Hope you won't mind if I try to reuse your github pages template, looks amazing! I wanted to have some side menu anyway, share buttons makes sense as well.
6. Currently I am near to 8k reputation, looks like it should be accessible from 1500, but if I understand it, I will need to create some question and tag it first, right? Do you think I should create some question myself and post the answer directly? What question would you start with? Or do you have some question I could answer there so we create a bit more organic content? :]
7. This one is obvious, once I will start blogging about it :]

I was also thinking about adopting some automatic commit message changelog, never heard of commitizen, looks nice! Will try to adopt that once v2 is released. Do you have some good articles to start with, or should I just go thru the docs?

About JS usage -- currently it is not supported, as entity metadata are gathered via TS decorators. When I started the project, I aimed to vanilla JS version only, but migrated to TS before releasing the first version. I have a WIP for parsing annotations from JSDoc comments, that way it could be used with vanilla JS too, but it could be a lot of work to finish that I guess (and test it properly). Or I could simply let users provide the same JSON with metadata that is now generated when caching. Do you think it is worth it to invest some time finishing vanilla JS support before I start to promote the project?

[stalniy]

1. Use your own user (at least for the nearest future).
2. Sounds good!
3. You would cover first express, feathersjs, graphql integration (later others like nestjs koa, restify).
4. I published several articles in https://medium.com/dailyjs . Also take a look at https://blog.feathersjs.com/ . I also used more frontend related channels for lib promotion, don't know whether it can help you. Can't help you with backend related channels unfortunately. Please share links if you find something good :)
5. No problem, you can use it
6. I'll try to think about some meaningful question and will get back to you in this issue with the link to the issue. I checked and micro-orm tag has been occupied but somebody else, so probably you will need to create something like micro-orm.js
7. Cool!

About Commitizen:

1. You can start from reading this doc https://gist.github.com/brianclements/841ea7bffdb01346392c . There is a link to original document at the bottom of gist
2. Setup lint-staged and husky for automatic (before every commit) tslint checks and commitlint checks
3. Use semantic-release to automate, changelog generation, release and publish to npm processes

About Metadata generation:

Just implement possibility to create a custom MetadataProvider, everybody will be able to write adapter which fills his needs. I can help to implement manual MetadataProvider, something similar to what TypeORM creators did (https://github.com/typeorm/javascript-example/tree/master/src/app3-es6)

Update:
If everything will be good, I will release a complementary library to integrate CASL and Micro-ORM. So, let's move on :)

[B4nan]

Thanks again for your suggestions, hope I will have enough time in near future to get things moving :]

Regarding the metadata provider, any help will be appreciated :] Will try to add support for that asap, in the end it could be pretty simple. Just finished #11 so will spend some time with that right now.

One thing to note - the name is mikro-orm with k, that tag is afaik available :] I chose the name with k as it was available when I was publishing my first node package (mikro-config) and followed the same convention with others. Also in my language (czech), we use k in this word, so the idea also origins from there :]

[B4nan]

Also spent some time with that medium article. I am not much of a writer, so any suggestions are welcome (including for images) :] Its pretty much the same content as in docs, just added some introduction/motivation and wrapped things up. For cover image I was thinking about some meme with text "Yet another ORM? ORLY?" or something like that.

Here is a draft link: https://medium.com/@b4nan/introducing-mikro-orm-typescript-data-mapper-orm-with-identity-map-9ba58d049e02

[stalniy]

Hi @B4nan ,

I read the article. It's good :)
I found few typos and suggested several changes in the article content and as well in MicroORM API, one comment is left in gist

[stalniy]

Another point which may help.

There is a website for searching npm modules. It calculates some quality attributes for every package. Currently for MikroORM (1.2.3) it shows quality 80 (from 100). You can go here to check analyses results.

You can find some explanations on About Page but the source code of their analyzer is pretty simple, so also you can read the code :) (this is what I did to understand JSON results). In this file you can find information how quality parameter is calculated

[B4nan]

Strange, it reports my readme size as 0. Will check that later once v2 is out (after #13 and #18 are merged).

[B4nan]

Closing this now.

• article is basically ready (will be glad if you could have a final look)
• example integrations are in progress (express js/ts are almost ready)
• docs template is updated (including social share buttons)
• husky, commitlint & other stuff integrated (will manage releasing manually for now, while using semantic-release to generate the changelog)
• will be glad if you could come up with that SO question 😉

[stalniy]

Hello,

Sorry for the delay ("release time" :) ). So,

• the article is great, I think it's time to publish
• SO question: https://stackoverflow.com/questions/55339019/how-can-i-insert-an-object-graph-by-using-mikroorm

One more action item:

• Please add https://b4nan.github.io/mikro-orm/ to the "Website" field (at the top of you repo, there should be "Edit" button, click -> set website). So, that it's easier/quicker to find docs

[B4nan]

No problem, I had enough time to test v2 in my projects to find some bugs that needed fixing anyway :]

I am finalising basic support for generating db schema from entity metadata, I guess I will have that ready this evening, then I will release v2.1 that also includes support for postgres and some other nice features (e.g. uuid primary keys, automatic ts-node detection, 1:M ordering, ... as well as some bug fixes), so will wait till that is ready before publishing the article.

Thanks for the question, I tried to make the answer a bit thorough, to highlight some advanced features.

Website added.

[B4nan]

So the article is published and submitted to DailyJS (waiting for approval).

Thanks again for all the feedback and suggestions!

[MichalLytek]

was super pissed with typeorm as it lacks references
have much better API than typeorm

I think that you should focus on comparing to TypeORM, showing its flaws and how mikro-orm fixes them. Someone that could convince me and other TypeORM or mongoose/Typegoose users to switch to mikro-orm that at first look is like 90% copy-paste with slightly tuned names.

[B4nan]

I agree, need to focus on this. I am planning to help my friend with migrating typeorm project to mikroorm, so will definitely write notes on what differs and why its better.

I can guarantee its not a copy-paste thing, but yeah, from outside it is really similar, I know what you mean.

[chaoyangnz]

my two cents.

1. create a new Github org account and move to there from you own personal account.
2. create amazing website (register a domain) and documentation
3. plan good route map and make others easier to contribute

which make it more professional, and lead some tech guys to make decision and want to have a try.

[B4nan]

Thanks for your suggestions, I already moved to mikro-orm org, I was planning to do this soon anyway. I will register domain also soon, probably before the release of v3. For v4 I am thinking about turning the repository into monorepo, with one core package, one cli package and then one package per driver probably.

I would love to make the documentation better, do you have any concrete suggestions in this manner? It can be very time consuming so currently I am investing more time into features so I can compete with others, but my goal is to have up to date docs as much as possible.

Not sure about the website itself, I think I will stick to github pages for now. What content other than docs would you expect there? Maybe something similar to what NestJS has? Simple one pager with highlights of some interesting features?

I will also try to plan the development more transparently after v3 release. I have few bigger features I would like to cover soon (composite keys for example). I was planning to use github issues for this, plus link to them in ROADMAP.md. Will be also glad for suggestions on how to do it better. Currently I started developing features in dev branch so I can publish bug fixes asap and keep feature releases separate.

[RDeluxe]

Just jumping in to say congrats, this is clean and neat. I'm going to dig deeper in the code but to be faire from what I've seen for now Mikro could have a bright future.

Typeorm is dying slowly, sadly and for understandable reasons the team does not have the time to maintain such a huge project without support. Moreover, TypeORM internals are questionnables, and even if it was a stepping stone for Typescript ORMs Mikro could very well be the next step.

I would love to the NestJS devs embrace Mikro, I think it would greatly boost the project popularity.

[stalniy]

I’d recommend to add it to https://stackshare.io/ so people can compare it to typeorm

Also you can add it here https://www.slant.co/topics/11235/~javascript-orms

Search for articles and questions like “which ORM to use?” and try to naturally answer those questions or provide an opinion and proofs that is the best one currently

[fullofcaffeine]

Sorry to hijack this thread, just found out about mikroorm, must say that from what I've seen and read so far, I'm quite impressed!

I'm wondering how hard would it be to migrate a project from TypeORM to it, I guess considering there are no huge custom code that relies on TypeORM's API, and considering the mikroorm and TypeORM APIs look similar, it wouldn't be that hard, right?

Also, what do you think of an automatic converter/migration* tool?

* not SQL migrations, but some kind of converter that takes a set of TypeORM objects (config, migrations, models) and generates mikroorm equivalents).

[B4nan]

While they have similar entity definition, the internals are very different. TypeORM is more of a query builder for me, there is no in memory state management or implicit transactions - unit of work and identity map. In MikroORM you change the state of entities (synchronously) and then flush the changes to database once (inside a transaction). It is not that hard to migrate, but you need to understand the differences, nothing an automation tool can do for you. It could help with the config and entity definitions for sure, but personally I would rather use the entity generator to create new entities and port the missing logic from the old ones manually.

You can take a look here to see how a migration from TypeORM to MikroORM may look like:

mikro-orm/nestjs-realworld-example-app@3345750

[fullofcaffeine]

Hey @B4nan, thanks a lot for the comprehensive reply!

I'll definitely try MikroORM out for my next project, as I'm already a bit invested in TypeORM for the current one. Bad timing.

As I mentioned though, I'm really impressed with the work you've been doing. I also like that the community is tight but responsive. It has been very difficult to get feedback on TypeORM as of late, let alone contact the core team/author :(

One thing that I really like about TypeORM is the schema auto-sync feature. When developing prototypes or an MVP, it really helps as I don't need to have a strict idea about the schema, and I can just change the entity and TypeORM will update the schema in the RDBMS automatically, for me. I see that MikroORM also has something similar, am I right?

TypeGraphQL is also a vital part of my stack, but I see no reason why it wouldn't work the same with MikroORM.

Perhaps a migration guide that lists main gotchas about converting a project from TypeORM to MikroORM would be useful, as well. I'd gladly contribute once I get my hands on it, as well.

All in all, I'm quite excited about MikroORM and its future. Keep up the great work!

[H6LS1S]

Hello everyone, I was just looking for a new ORM to replace TypeORM, because many commonplace things turned into butthurt and dances with tambourines ( :rain dance ), performance tests were pleasantly surprised. Since I got here from the first Google request, the recommendations above work.

P.S.

Please add additional driver benchmarks.

Keep up the great work!

[Dezzmeister]

This is fantastic. Good enough to compel me to switch from typeorm halfway through a project.

[bkstorm]

Hello everyone, I was just looking for a new ORM to replace TypeORM, because many commonplace things turned into butthurt and dances with tambourines ( :rain dance ), performance tests were pleasantly surprised. Since I got here from the first Google request, the recommendations above work.

P.S.

Please add additional driver benchmarks.

Keep up the great work!

Hi @H6LS1S ,
I have an performance issue with TypeORM (CPU is too high when generating query), so I'm finding a new ORM to replace it.
https://github.com/bkstorm/typescript-orm-benchmark
I just fork a repository to benchmark Mikro-ORM vs TypeORM, you can check it out.
It seems like Mikro-ORM is slower than TypeORM when getting data.
My database has 100 orders, 100 items and 100 orders_items rows.

• Mikro-ORM:
  

• TypeORM:
  

[B4nan]

@bkstorm you do not set up any request context so your identity map gets bigger and bigger, making each request slower and slower. This is indeed a misusage.

Also for performance testing you should use AsyncLocalStorage or manual forking, as the RequestContext helper in v4 uses domain api (that is indeed slowing things down too).

For simlicity, I would suggest to go for manual forking, so instead of using the global DI.orm.em, do const em = DI.orm.em.fork(); at the beginning of each request handler and use the fork instead.

router.post(
  '/orders',
  async (req: Request, res: Response, next: NextFunction) => {
    const em = DI.orm.em.fork(); // <-- make a fresh fork so we dont polluate the identity map
    try {
      const order = em.create(Order, req.body);
      order.items.add(em.create(Item, req.body[0].items));
      await em.persistAndFlush(order);
      return res.status(200).send({ orders: [order] });
    } catch (error) {
      return next('Error processing values');
    }
  },
);

[bkstorm]

@B4nan I setup a request context in server.ts, I think I setup it correctly. Right?
app.use((req, res, next) => { RequestContext.create(DI.orm.em, next); });
Anyway, after using manual forking, the result is much better :D

[B4nan]

I see, missed that file (and it indeed looks ok), that might be because of the domain API as mentioned above. v5 uses AsyncLocalStorage which is much faster (and manual forking will be even better, but the difference should be rather minimal).

[bkstorm]

I see, missed that file (and it indeed looks ok), that might be because of the domain API as mentioned above. v5 uses AsyncLocalStorage which is much faster (and manual forking will be even better, but the difference should be rather minimal).

Nice. Based on the benchmark result, I decide to migrate my current project from TypeORM to Mikro-ORM.
Thank you for supporting me!

[dzcpy]

Is there any performance bechmark which is based on the most current version of these libraries? I've got dissed by TypeORM fans. It feels bad, please help

[yangli-io]

We rewrote our entire codebase, 100k lines in mikro-orm and then went back to typeorm.

1. The two main issues were a persist and flush issue that we had similar to Bull - Scoped Jobs nestjs#5
2. Poor Migration Manager

Whilst it solved a lot of issues that Typeorm had, we considered these two issues to be pretty major and typeorms issues arent so major. Mikroorm has a lot of nice features but also comes with a lot of its own issues. It's also important to note usecase was with PostgresSQL.

[B4nan]

What do you mean by poor migration manager? What version were you using? Did you report any of your problems? I don't see a single issue created by you...