Prisma Integration

[clayrisser]

This issue is for sharing thoughts on using prisma with loopback 4.

I wrote a simple example using prisma with loopback 4 and below are my initial observations.

1. Prisma does not work well with repositories, datasources or modals. The main reason for this is because prisma modals are tightly coupled with prisma datasources. This creates real friction with repositories, since repositories depend on a modal and datasource. I found it made the most sense to just directly use prisma in my controllers. The downside to this is that you cannot create loopback repository relationships with prisma data. Honestly though, that responsibility probably should lie with prisma anyways if you choose to use it.

2. The prisma api gets generated from prisma modals, which I find a bit awkward, although I understand it makes it easier to deal with the types. This will create challenges with loopbacks type system because loopback will be unaware of prisma types. This might be able to be improved with some hackery.

You can look at my example below.

https://github.com/codejamninja/lb4-prisma/blob/master/example/src/controllers/user.controller.ts

[dhmlau]

@codejamninja, thanks for your info! @bajtos, @raymondfeng and I had some discussion around prisma integration, so this is helpful.

@bajtos @raymondfeng, what do you think about creating a spike on this and perhaps target it for Q1?

[bajtos]

Thank you @codejamninja for the write up.

I found it made the most sense to just directly use prisma in my controllers. The downside to this is that you cannot create loopback repository relationships with prisma data. Honestly though, that responsibility probably should lie with prisma anyways if you choose to use it.

I agree with your conclusion to use Prisma directly in the controllers and bypass LoopBack models/datasources/repositories and let Prisma handle relations.

We may want to find a way how to register Prisma artifacts for dependency injection though.

This will create challenges with loopbacks type system because loopback will be unaware of prisma types.

Doesn't Prisma offer code-generation of TypeScript interfaces or classes to describe data shape? If not, then perhaps we can write one as part of loopback-prisma integration.

I think we should also look into ways how to obtain JSON Schema for Prisma type/data definitions. For example, when writing a hypothetical ProductController, I would like to use ProductSchema generated from my prisma definition files, I don't want to write (and maintain) it myself.

@dhmlau

what do you think about creating a spike on this and perhaps target it for Q1?

Sure, sound good :+1:

[clayrisser]

Yes, prisma generates the types, but they are different than loopback's types

[clayrisser]

I thinks some kind of type shim would need to be created to make it integrate better.

[clayrisser]

Photon might be the answer for easily shimming the prisma types with loopback 4.

https://photonjs.prisma.io

[jonathansolorzn]

Is it right to think on how to integrate prisma 2 with loopback or should we take prisma as a similar solution for the same problem loopback solves?, in other words, shall we consider choosing between them?

[clayrisser]

Prisma 2 does not really allow business logic. It's more or less an ORM over a rest/graphql api.

[stale[bot]]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[VinayaSathyanarayana]

Any update on this. I would like to use lb4 using the model definitions as specified in Prisma schema.

You may question on why I cannot create lb4 models - the answer to it is that I do not create Prisma schema. Prisma schema is auto generated by another tool for me

[VinayaSathyanarayana]

Any progress on this?

[achrinza]

Still prototyping on how the initial integration will work; Hopefully I can get a PR ready in the upcoming weeks, but no promises as of now.

Though this should not be blocker to using Prisma; The Prisma Client can be imported into a Controller/Service/etc. like any other Node.js application

[VinayaSathyanarayana]

@achrinza Hope you could progress on the prisma integration

[achrinza]

Hi @VinayaSathyanarayana, the Prisma integration is still in progress, though I haven't had as much time as I'd like to work on it.

To give an update, lifecycle integration is complete, and the remaining todo are:

• More Tests
• Prisma Model dependency injection

These 2 todos have been interesting to work with due to Prisma generating the typings on-demand and not having a common "base model", but it should be possible to work around them.

Still no ETA though.

[raymondfeng]

I was able to leverage Prisma in my project with LoopBack. In my case, I discovered a Postgresql database to generate schemas and strongly-typed client code. I also created repositories that use the generated Prisma client to interact with the DB. To expose REST APIs, I created controllers that inject repositories.

[raymondfeng]

@achrinza I would love to see your progress. It seems that Prisma and LoopBack can meet in the middle to leverage the best of breeds:

• Prisma provides DB access
• LoopBack provides composition capabilities
• LoopBack exposes REST/GraphQL APIs

[VinayaSathyanarayana]

I was able to leverage Prisma in my project with LoopBack. In my case, I discovered a Postgresql database to generate schemas and strongly-typed client code. I also created repositories that use the generated Prisma client to interact with the DB. To expose REST APIs, I created controllers that inject repositories.

@raymondfeng Can you share the code you used?

[josemotta]

I would love to see Prisma & LoopBack integration. Currently, the LoopBack model generates the OpenAPI schema that becomes the source of truth for API development. Where would Prisma schema enter the party?

[achrinza]

@josemotta

When it comes to ORMs, I see that there's two types of LoopBack integration that can be done:

1. LoopBack-to-ORM
2. ORM-to-LoopBack

---

LoopBack-to-ORM can be broken down into 2 "stages" of integration I'd call "skeleton integration" and "native integration"

1. Skeleton integration is the minimal implementation of bootstrapping the ORM into LoopBack 4 (e.g. connection lifecycle management). The ORM's original Models and DataSource are used by the developer. This does mean that there is no "source of truth", as there would be duplicate Models for LB4 and the ORM, but this stage enables lift-and-shift from existing codebases that use those ORMs.
2. Native integration is the next stage which conversion layer that allows the use of LoopBack 4 Datasources, Models, (and Relations) are provided. This would allow for cross-ORM integration (e.g. between Juggler and TypeORM).

This skeleton integration is what @loopback/typeorm is, and what https://github.com/loopbackio/loopback-next/pull/7500 attempts to implement for Prisma.

The vision is to eventually implement native integration so that developers can more easily work between different ORMs. Currently, it's only "implemented" for the in-house Juggler ORM that comes bundled in @loopback/repository.

---

ORM-to-LoopBack would be to use the ORM's own Models as the source of truth for the rest of LoopBack (e.g. OpenAPI validation). However, there is no package that currently implement this.

---

Where would Prisma schema enter the party?

For the Skeleton, the Prisma schema would continue to work as a standalone component for use in Prisma only while the LoopBack 4 Model continues to be used for the rest of the framework.

For a theorhetical native integration, the LB4 Models would be be used to generate the Prisma schema behind the scenes. But since native integration would build on top of the skeleton integration, Prisma schemas would still be directly usable if the developer wants to.

As for a theorhetical ORM-to-LoopBack integration, that would mean using Prisma schemas as the source of truth (i.e. as a replacement for LB4 Models). Though this would require maintaining a Prisma Generator.

---

At this moment, the Prisma integration that's been worked on has stalled a bit since Prisma hsa evolved quite a bit since the the work initially started though I'm always open to continuing the work when I can or support someone else who wants to continue championing the work.

Feel free to share if you have any ideas to add on to the above :-)

[josemotta]

Thanks @achrinza for sharing your vision. I can live with skeleton integration to use Prisma at LB4 controllers.

Looking from the developer's perspective: first, you design a distributed model that requires APIs to communicate. The Prisma language allows modeling entities and their relationships very well but the LoopBack modeling schema is also fine, a standardization would be appreciated.

Then, the OpenAPI is generated based on the language that defined the model. Development and validation for all distributed services should follow this OpenAPI schema, isn't it? It would behave like a "model first" that becomes "API first".

[achrinza]

Yes, that's would be the general idea: Use LB4/Prisma/Some other modelling to generate the OpenAPI 3.0 spec which can then be used by other API consumers. One additional scenario is to put common LB4 models into their own Node.js package and directly import that into multiple LB4 projects thereby providing consistent TypeScript definitions.

[ricar2ce]

All the best, Any update on this topic? Currently, Prisma, in my opinion, has proven to be one of the best, if not the best, javascript ORM. Please I would like to know if there is a real intention to create the integration or if I have a way to use prism with loopback, since this depends on whether I use loopback for an important project that I am starting. I await your response thank you very much