Browser shim?

[205g0]

Is your feature request related to a problem? Please describe.
Does MO offers a browser shim?

If you have a monorepo with DRY models you want to import the models (or decorate types/classes) to the frontend but the decorators shouldn't do anything on the browsers because yeah, you don't have a db there and you just want the type defs. And besides, you don't want to bloat the frontend gzips with unneeded code.

Describe the solution you'd like
Check type-graphql, the maintainer created an elegant browser shim.

Describe alternatives you've considered
To copy the files to the frontend folders and strip out the decorators with sed on file save haha but this is rather super messy.

[B4nan]

In frontend you could import just the type (something like import type { Author } from './entities/author';).

Check type-graphql, the maintainer created an elegant browser shim.

Not sure how is this describing anything. At least provide a link to what you are talking about. Ideally send a PR right ahead :]

[205g0]

import type { Author } from './entities/author';

This is nice. Howeveer, wouldn't I also import the attached decorators as well? If not this could be elegant way.

Re type-graph!l, https://typegraphql.com/docs/browser-usage.html

[B4nan]

Nope, this will import only the type, so basically only what is inside the d.ts file. And there are no decorators, its basically just an interface of the actual class

[205g0]

This is actually smart, it just needs a compile step before the FE repo can import the d.ts.

But wait, there is one catch: Decorators like those from class-validator are also helpful in the FE, so I would like to keep them and not repeat them there myself AND I even couldn't add them manually because I would just have an imported d.ts. which I cannot decorate...

[B4nan]

Importing type will only... import the type :] There cant be any decorators, it will be just a (typescript) type, so basically an interface.

[205g0]

Yes sure but if the FE dev imported the decorated class from the BE and not the type he would benefit from the class-validator decorators he would need for his FE work as well. Otherwise he would need to re-implement validators in the FE (e.g. is the entered input really an email address etc.).

What the type-graphql maintainer did is actually just an empty module with the same API but doing nothing and with webpack you have—AFAIK a NormalModuleReplacement or so where you can kick out the real lib and exchange it with the fake lib. So you kick out type-graphql but keep class-validator.

[B4nan]

We can definitely add a shim here too, but as I never even used the project with webpack myself, I'd prefer if someone else could do this and test it in real world scenario. In the end you should not even need the ORM to provide a shim, you could plug in your own I guess, right? And if it works fine, send a PR :]

[MartinAndreev]

If you are only using it to store data, why not use DTO instead?

[ThatOneAwkwardGuy]

Has, Anyone made any progress on the shim? I tried to make one but only ran into errors. I'm thinking maybe separating the classes into a validator class and the schema class using nestjs's mapped types might be necessary.

[B4nan]

I'm thinking maybe separating the classes into a validator class and the schema class using nestjs's mapped types might be necessary.

I don't really understand what you mean by that, but keep in mind that MikroORM on its own can't use anything from nestjs, as it is not dependent on nestjs anyhow.

[ThatOneAwkwardGuy]

I'm thinking maybe separating the classes into a validator class and the schema class using nestjs's mapped types might be necessary.

I don't really understand what you mean by that, but keep in mind that MikroORM on its own can't use anything from nestjs, as it is not dependent on nestjs anyhow.

Oh, what I was thinking is that nestjs has some utility functions that can directly copy a class with its class-validation decorators. So if I use that, then I can technically have a single source of truth with a copy of the class containing just its validation. However, I just realized that regardless it leads to an indirect import of the main class that has all the decorators I can't use on the front-end.

Maybe what I can do is have an EntityValidation class and an Entity class, but then I would have to define each class attribute twice.

[myknbani]

TypeORM has it:

https://github.com/typeorm/typeorm/blob/master/extra/typeorm-model-shim.js#L16-L21

Most decorators are no-ops.

[ghost]

one could use technically use mikro-orm in the browser with sqljs or when one is using a webview and integration with cordova and/or capacitor.

I myself just got knex working with an ionic/capacitor plugin (which i think can also use sqljs), but it'll be a bit tougher to bring in mikroorm.

[MatthewAry]

I have been wanting to build a system similar to what was described in this video https://www.youtube.com/watch?v=WxK11RsLqp4&t=2176s (there are two talks, the video should start at the right spot).

The solution shown seems very inspired by MikroORM. They have created an ORM that works in the browser that uses Single Table Inheritance (AKA the Object Pool in the video) for an In-Memory database type implementation.

Since this video was posted, they have implemented multi-layer storage strategy on the browser. In-Memory (for high performance with volatility), IndexedDB for local persistence and reduced requests to the back-end, and the back-end or as the video calls it, the Object Store.

They publish changes to the back-end using GraphQL and they avoid making queries to the back-end by having those queries be performed in the front-end.

If MikroORM could make browser support a first-class citizen for something like that, it would be super cool.