search

medz / prisma-dart

Prisma Client Dart is an auto-generated type-safe ORM. It uses Prisma Engine as the data access layer and is as consistent as possible with the Prisma Client JS/TS APIs.
https://prisma.pub
BSD 3-Clause "New" or "Revised" License
450 stars 30 forks source link

Support Flutter App #328

Open medz opened 8 months ago

medz commented 8 months ago

Prisma Dart Client was originally built for the Dart server-side, and we look forward to introducing it in Flutter.

Progress

kidusdev commented 3 months ago

internally I'm using Zig. So I may also release a Zig version of Prisma in the future its very intresting

that would be amazing if Zig took off in the future.

listepo commented 2 months ago

Any news?

medz commented 2 months ago

Any news?

@listepo Sorry, no new news. Maybe https://github.com/prisma/prisma-engines/pull/4913 is one of the news.

My original plan was to use the binary engine to build macOS/Windows/Linux support (of course, it is not a high priority) but I did not try my best to implement it for the following reasons:

  1. Prisma engine has been working towards the WASM build goal

  2. The binary engine has been phased out since last year (most of the third-party language implementations are still in use)

  3. There is no clear direction for Prisma to move in. I can only work as hard as possible on the engine provided by Prisma, because any implementation of my own can be easily destroyed by the above. (This is not the scope of Prisma's official obligations)

  4. My personal energy is really limited. To put it bluntly, China's current unemployment rate is very high and everyone is working hard to make a living, otherwise they will not be able to eat tomorrow. (I am no exception)

Combining the above, it is difficult for Prisma Dart to make new breakthroughs. Completing similar implementations for most of the Prisma official engine is the best I can do at this point.

MulverineX commented 2 months ago
  1. This could be very powerful, but it does come with a small performance hit
  2. Im not sure what this means, but dont those third party implementations all rely on the binary engine in some way?
  3. Completely understandable, keeping up with constant internal changes would be a massive pain and is infeasible for one person to maintain.
  4. My most sincere condolences, its very difficult to make fulfilling & productive career/hobby choices in such a tight job market. I can sympathize a little, as I've had a tough time finding a software company to take a chance on me. I'm lucky to be living with my parents still though. It seems that most of the world is headed into a recession. I wish I could donate more and/or that some startups would take notice of this project and fund its development 😮‍💨. Good luck out there, hoping that you find some stability and rest soon.
medz commented 2 months ago

@MulverineX

Thank you for your understanding and support.

This could be very powerful, but it does come with a small performance hit

This means that it becomes more difficult to use the Prisma engine in environments that do not support loading WASM natively. Currently, other third-party languages have strong official or community support for loading WASM modules, but Dart does not. The Dart official team is currently committed to using Dart to build WASM modules and has no plans to load WASM modules at the moment.

Im not sure what this means, but dont those third party implementations all rely on the binary engine in some way?

Yes, currently third-party languages are using the Prisma binary engine. But almost all Prisma official clients are no longer used.

As far as I know, the Wasm version of the last Scheme Engine in Prisma's official engine is about to be built. Perhaps after the last remaining binary engine implemented WASM migration, several versions of bug fixes were made. Prisma official will no longer maintain or even completely stop building binary engines (this is just my guess, because continuing to maintain binary engines after all switches to WASM is meaningless for Prisma official and will increase costs)

MulverineX commented 2 months ago

strong official or community support for loading WASM modules, but Dart does not.

luckily this is actually not the case! https://github.com/juancastillo0/wasm_run

MulverineX commented 2 months ago

continuing to maintain binary engines after all switches to WASM is meaningless for Prisma official and will increase costs

not necessarily, Many people will still want to use the system binary engine for better performance.

listepo commented 2 months ago

yes native code better

listepo commented 2 months ago

@medz I would like to try to help, could you share the Zig code?

medz commented 2 months ago

@listepo Unfortunately, I deleted it after Prisma released the CABI engine. Because its essence is to use Rust FFI to write C ABI, and then call it from Zig to build a unified engine.  I am sorry that I deleted it after trying this technology (because I gave up the huge upstream dependency work)

Currently, the only thing left of Prisma Dart is the client based on the official Prisma engine.  Again, I am sorry that I no longer have the energy to try new technologies. My current personal plan for Prisma Dart (not disclosed) is as follows:

  1. Stability maintenance (I will fix it once someone submits a bug)

  2. Remove code_buinder from the code base (very low priority, I have always planned to remove code_builder/build_runner/json_serializable, and it took me a long time to successfully remove the build_* ecosystem package)

  3. Migrate fromJson and toJson of // to macros. (Once macros enters the official version of Dart SDK, the experimental flag will not be required)  And my company has already given up using the Zig language. Forgive me for being too busy to do anything else. I can only keep up with the normal bug fixes for the open source project. (Because my company has once again reached the point where I am the only one left, I must find a way to save it and ensure my livelihood)

The reason I tried Zig to write the engine before was that Rust cross-compilation was too complicated, while Zig was much simpler (it can be said that it is very easy to cross-compile)