How to make two Nest projects share the same entities and database

[safe cobalt]

I built a simple project A that uses Entities and Typeorm that must run on its own server instance, and that works fine. My problem is that I must build another project B that runs on another server instance and connects to the same database as project A, sharing some entity with it, just reading them, or creating new relations.

I haven't done it before but after googling and thinking about it I've come to these possible solutions:

• copy/past the entities as classes (a lot of problems ahead)
• keep working on project A and expose different api according to environmental variables
• npm workspaces
• monorepo
• Nx/Turborepo

Considering that I'm still new to Nest, so I'll have to study any solution, what's in your opinion the most simple that won't make me regret it?

[crimson zinc]

I'm new to such problem as well
I have two nestjs apps that are using the same database, but they live in two repos
I'm still trying to moving everything to a nestjs monorepo instead so now I'll have one directory called libs/core-database that holds all DB stuff (setup and entities)

but people often use Nx
what I dislike on that is that they abstracts away the nest-cli.json (AFIAK), so you'd have to learn a new tool
With nestjs monorepo mode you just need to understand how TS works

A disadvantage I've seen is that now you'll have only one package.json, thus every dependency on one app will leak to all the others. This is an issue that neither nestjs monorepo nor Nx solves https://github.com/nrwl/nx/issues/1777 We probably could circumvent that in a hacky way tho

[tall fossil]

regarding dependency leaking:

Only the dependencies depended upon by a workspace can be accessed. Said another way, we strictly enforce your workspaces dependencies
https://yarnpkg.com/features/workspaces#:~:text=Only the dependencies depended upon by a workspace can be accessed. Said another way%2C we strictly enforce your workspaces dependencies

Isn't this what you're describing? Just remembered that sentence since I was experimenting with workspaces on Friday, but didn't get far enough to face such issues.

[crimson zinc]

that's correct
with yarn workspaces we will have one package.json per app. I'm not sure how well it plays with nestjs apps

[tall fossil]

I think papooch had some success with that: #887783765068361859 message

[cursive inlet]

It works like a charm with yarn berry and a mono repo setup. You can have a package containing your entities (and also graphql field defs)

[crimson zinc]

the thing is I want to share the code without having another nodejs package for it
Is it possible with Yarn?

I guess is more a typescript thing tho

[digital atlas]

The problem with sharing entities between different modules/projects is that you need to declare all of them again anyway such as with relationships.

[cursive inlet]

Yeah, you can do it with typescript. But keep in mind that your build folder will change

[digital atlas]

I've overcome all of this jazz by using microservices and a message broker like RabbitMQ to RPC/pub-sub between the services and maintaining separation of concerns.

[cursive inlet]

We’ve tried to use the typescript approach but ended up with an entities package. Its a much cleaner way and not messing up your tsconfig

[digital atlas]

What do you mean by "messing up" exactly?

[cursive inlet]

You need to create alliases to the entities in all packages. Your build folder will not start form the src of your package since the entities will also be in the root

Downside is that you need to watch your entities package when making changes to the entities but thats not a big thing

[digital atlas]

What about not fiddling with the typescript config at all and using npm/yarn link?

[cursive inlet]

If your deployed app is capable of creating a production built including the linked packages. That might work. For us, having a monorepo setup (with yarn berry) with multiple packages, was the best way to go so our cicd was capable of creating a nice tree shaked built

We started with the typescript approach but it gave some unwanted side effects and lots of config hassle

[digital atlas]

Gotcha. If we're talking about microservices I can vouch for the overhead (minimal) of publishing a comment entities ("models") package and npm install'ing it in the dependent repo's.

No tsconfig.json fiddling there either heh

[safe cobalt]

In the end, after testing some solution, including lerna and only at the end understanding that it's no more in development, I'm trying Turborepo with pnpm. It looks unobtrusive enough and is native with Nexts, that I'm going to include any way for the frontend. I think that I've found a solution for CI/CD within aws with lambdas to sort the changes in the correct build server.
Why anything on node must feel so uncertain and experimental like I'm inventing it on the spot?