Multiple prisma with nx workspaces and nestjs

[ionut-gheorghe]

Bug description

I have tried nx workspace with nestjs and prisma which outputs to node_modules (default setup) and it works, but using multiple prismas with custom directory output fails.

Running nx build shows warnings

Running nx serve shows errors

I have this kind of setup with nestjs and many prisma (need to access different databases) using the default structure (no monorepo) and it works without problems. I think the problem resides with webpack and the binaries from prisma, but I don't know how to solve it.

nx structure

How to reproduce

1. Clone repository https://github.com/ionut-gheorghe/nx-multi-prisma.git
2. Run npm install
3. Run npm run prisma1:generate script
4. Run npm run prisma2:generate script
5. Run nx serve

Expected behavior

To run without errors

Prisma information

datasource db {
  provider = "sqlite"
  url      = "file:./dev.db"
}

generator client {
  provider = "prisma-client-js"
  output   = "../generated"
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
}

Environment & setup

• OS: Windows 10
• Database: Sql Lite
• Node.js version: 14 Lts

Prisma Version

2.23.0

[3dmind]

@ionut-gheorghe I'm having the same problem here with a project using Nx and Prisma.

My use-case is to have a monorepo using Nx with multiple micro services. I would like to use a separate Prisma client with its own schema in every micro service.

[Jolg42]

Could be related to #7439

[janpio]

@3dmind Could you maybe open your own issue about this and explain your full use case, maybe even create a minimal reproduction of what you are trying to do and how it fails? We are super interested in making Prisma Client work with mono repos of course, but need more input.

@ionut-gheorghe Did this work before or did you just hit this problem when trying to use Prisma?

[ionut-gheorghe]

What do you mean by if it worked before.

Current I use nestjs with multiple prisma's but it is not a monorepo, its the standard structure. I have the prisma's folders (each folder is a differrent database) at the root level of the project and I reference them from the code. When deploying I just copy prisma's folders along side with node_modules, dist and package.json.

[janpio]

Sorry for not being clear, I wanted to know if you did the same thing with an earlier Prisma version and if it worked there - or if you are just now trying to change your project structure and are hitting this problem. This seems to be the case.

[pantharshit00]

I can reproduce the behaviour with 2.25 and the reproduction provided.

I don't have any experience with Nx so I can't really assess this but I will mark this as confirmed bug so that someone else can have a look.

[BetterLuke]

@ionut-gheorghe I'm having the same problem here with a project using Nx and Prisma.

My use-case is to have a monorepo using Nx with multiple micro services. I would like to use a separate Prisma client with its own schema in every micro service.

Hi bro, did you solve this problem?

[BetterLuke]

Hi all, I found a temporary solution for this case:

For schema file:

generator client {
    provider        = "prisma-client-js"
    output          = "../../../node_modules/@prisma/client-2"  // make output into node_modules folder to avoid nx bundle that
    binaryTargets   = ["native", "rhel-openssl-1.0.x"]
}

and then, in nest module file, you can import client like that

import { PrismaClient } from '@prisma/client-2'

If you find a better solution, remember to be brave and share it like I did. lol :D

[3dmind]

@BetterLuke Hi 👋

I tested your solution and it works.
I have to investigate if it still works when I run the app in a docker container.

[nwidynski]

@3dmind @BetterLuke @janpio @pantharshit00 This issue is caused by webpack bundling the prisma-generated .js files and trying to resolve the node internal modules.

Your should be able to fix this by configuring webpack:

const nodeExternals = require('webpack-node-externals');

module.exports = (webpack, options) => {
  return { ...webpack, externals: [nodeExternals(), 'encoding', '_http_common'] };
};

[millsp]

Hey everyone, I just have used the reproduction with @prisma/client@dev and confirm that this has been fixed. Feel free to try it and let us know if you find anything unexpected. Thanks, @ionut-gheorghe for taking the time to provide the reproduction.

[johannesschobel]

So what is the actual solution to this issue? Do we (developers) do something on our side or is it fixed with Prisma by default?
Or is it the solution provided by @nwidynski ?
Thank you very much

[janpio]

You can try the current dev version of Prisma (npm install prisma@dev @prisma/client@dev) already and let us know, or next week Tuesday this will be released as part of 3.12.0.

(If the dev version does not work for your, please let us know!)

[exsesx]

What's exactly the solution to this?

What do developers have to do to achieve different Prisma setups for each microservice (app)?

[johannesschobel]

@exsesx : the idea is as follows. Maybe you want to have everything that is related to one particular feature of your app (i.e., user, articles, comments) to also reside in one specific directory (i.e., libs\user\ and so on).

In this case, you would also want to have the specific User model in the user directory, and the Article model in the article directory. Furthermore, you would need to have a mechanism to later combine all those different schema-fragments into one large file that can be processed and managed by prisma.

Hope this helps?!
All the best,
Johannes

[exsesx]

Thanks @johannesschobel

My end goal is to have separate microservices with their schema, connections strings, and maybe even different databases.

I'll dig into it more to see if any of the above works.

[johannesschobel]

Dear @exsesx

please note, that the current state of my library does not support generating multiple prisma.schema files. However, i can take a look at it and add this as a feature, if you're interested. This way, each microservice could have its own dedicated prisma.schema file.

All the best

[exsesx]

Dear @exsesx

please note, that the current state of my library does not support generating multiple prisma.schema files. However, i can take a look at it and add this as a feature, if you're interested. This way, each microservice could have its own dedicated prisma.schema file.

All the best

That'd be fantastic, thanks 👍🏻

[johannesschobel]

Dear @exsesx ,

try the latest version of prisma-utils/prismerge (https://github.com/prisma-utils/prisma-utils/tree/main/libs/prismerge). it now supports "apps", designed for your use-case of having various microservices (each with its own database connection, schema, and so on).

[millsp]

For microservices in a monorepo, I believe the best is to generate in a custom output location.
https://www.prisma.io/docs/concepts/components/prisma-schema/generators

[johannesschobel]

@millsp yeah, but you still need multiple schema files (i.e. one per service). And that is what my library solves.

All the best

[hoghweed]

Dear @exsesx ,

try the latest version of prisma-utils/prismerge (prisma-utils/prisma-utils@main/libs/prismerge). it now supports "apps", designed for your use-case of having various microservices (each with its own database connection, schema, and so on).

@johannesschobel I'm very interested in prismerge, even if it is a workaround (my solution support a kind of microservices where each service has a prisma schema but uses the same physical database as per the other services ) I find prismerge very interesting.

Unfortunately, there is ZERO docs about usage and how to integrate into "microservices" oriented architecture. Where it is possible to find some examples?

[johannesschobel]

Dear @hoghweed ,

i think, this may be a very specific use-case that you describe here. I use PrisMerge in a different setup (i.e., one backend application, but the *.prisma files are scattered all across different libraries). Therefore, the documentation provided in the ReadMe mainly covers these aspects.

I believe, however, that PrisMerge already supports this kind of use-case. Basically, PrisMerge generates one (or more) schema.prisma files from multiple input documents for you. How you "load" these files to create your database, migrate a database properly from one state to another one, ... is not part of PrisMerge - that is what Prisma does for you.

Can you describe, what PrisMerge should provide for you or how i can extend the docs to fit your needs?

All the best,
Johannes