Feedback for “Limitations”

[tnypxl]

Are the actual missing APIs being tracked somewhere?

[steebchen]

No, but it's a good idea to do that. The tricky thing is to keep this up-to-date as well, which ideally would also include other 3rd party clients in a table. Definitely something to think about.

[steebchen]

What do you think of this:

https://prisma-compat.vercel.app/

It could include other clients as well:

https://github.com/steebchen/prisma-compat

[tnypxl]

As a first version this is probably good enough. Too much granularity this early could make it less approachable for the community to keep it updated.

[valerii15298]

@steebchen Thank you for such a great library. I actually already hate golang because of extremely poor typesafety(compared to Rust in golang every pointer could be a nil and not give you any hint on compile time), but your library seems to give at least a hope to a bit safer development with db integration.
I compared gorm/ent/prisma-client-go and your library seems to be the only one to give type safety and show errors on compile time instead of run time.

I wanna propose to use this library at my company. I used original typescript prisma and it was not a bad experience.
Can you give a hint what limitations compared to original prisma/gorm/ent this library has? And in general any limitation for better understanding how feature full it is?

[steebchen]

@valerii15298 Thanks, appreciate your words. Feel free to join the Discord Community to chat in depth. Regarding the state of the library, you might also give #860 if you are not familiar with the history of this project.

To answer your question simply, I do try to keep this library up and maintained, and ideally also add missing features (there are currently some in development, such as MongoDB object types (WIP), and soon to be merged unique constraint violation error handling. There are some missing features, such as no Count() method, no nested creates (you can usually do it with a simple transaction instead), no 'interactive transactions yet, no group by, and most likely a bunch more. For some methods it's just quite hard to implement (like group by, Go's type-safety can't really help here), and for some the amount of effort and added complexity plus exponential generated code size is not worth implementing, especially if there is another way which works for most use-cases, such as for nested writes (e.g. create user and 2 posts, instead do 3 calls and run in a tx).

For anything that doesn't work, you can of course always fall back to a raw transaction. Also, all query methods rely on the same query engine, so you will always benefit of the underlying improvements from the Prisma team.

I am actively looking for sponsors, so if you successfully implement the client in the company, I would be grateful if you could support the ongoing development with a sponsorship. Of course that is completely optional, but the more sponsors I can find, the more time I can dedicate to this project.

Regarding your thoughts about type-safety, indeed Go is quite limited with its typesafety, and I tried to max out the options as much as I could, as I agree that it's important to have everything typed as much as possible. Unfortunately, even with the generics, there are still a lot of limitations and the library will probably never have even a basic GroupBy implementation, or a fully type-safe Select(). However, I think Go is not mainly chosen for its type-safety anyway, rather for simpliciy of development, great tooling, and so forth; so this library kind of builds upon this vision.