3 ms·

Forgive me the obvious elephant in the room - where is Swift and Java/Kotlin support?

RandomBK 8y ago
For Kotlin/Java you can probably use jOOQ (https://www.jooq.org/ https://www.jooq.org/)
lostmyoldone 8y ago
Written in Scala, has a "greyed out" Python and Java client icon in the diagram at the very top of the readme, and an issue from Jan 2018 querying about a Java client which has had barely any traffic. That's slightly weird, bit of a mixed messages situation! Epilogue: Caveat emptor, rambling ahead. I probably shouldn't write comments when I'm tired. Hasn't type safe ORM mappings and/or middleware, code generation, been done to death, at least for the JVM languages? However, as I've been out of the Java loop for a bit, I'm not 100% sure of the stage of ORM like tools/libs today, I might be wrong. If the admin UI is spectacular, and the migration flawless even with a fair bit of data, those could be useful tools. Neither are easy tasks though. But still, I have to wonder, is there actually more ways to try to do it, to connect code and relational/graph data? Feels like there has been so many attempts and that all of them has shown to have their various, by now, surely rather well known limitations? Better is always possible, though. However, except for mixing in a bit of graphql and having an additional server, I can't really see what it is they claim is so different? Though I've been out of the loop for some year I can't have been the only one that have implemented/integrated a graph querying language on top of a ORM(-like) mapping with code generation, similar to Prisma? Or are there really no decent tooling of that kind, still? Except for admin UI and real-time, I wrote something very similar back in 2007, or something like that. Unfortunately my client weren't interested in open sourcing it, back then it could have been somewhat original. If I recall correctly, it was a customized Hibernate in the bottom, some code generation for Java - ASP - php - and maybe perl - clients, some fancy dependency injection. Connect to the database and you got generated all code that was needed for a service you could query for tree fragments of almost arbitrary shape. Essentially a GraphQL light I quess, as GraphQL wasn't available at the time, if it existed at all. The http API used JAXWS I believe and it exposed few endpoints for some REST-ish+JSON and SOAP You could do transactions over multiple requests if you wanted to, and weren't easily scared. It could obviously prune circular graphs into trees, although that code had a few fun bugs initially. No streaming though, as the client didn't need it.
hokumguru 8y ago
Prisma is meant to be a backend ORM so a swift implementation makes little sense.
nikolasburk 8y ago
(I work at Prisma) That's a great question! We started with a major focus on GraphQL which has now become more generic as Prisma can really be used for any app that uses a DB (REST, gRPC, ...). With that GraphQL history, we've put a lot of focus on the Node/TypeScript ecosystem because that's where GraphQL tooling is most mature. However, we're definitely planning to support more languages in the future. In particular, we are opening the generator API for the Prisma client which means it will be possible for anyone to implement the Prisma client in their own preferred language: https://github.com/prisma/rfcs/blob/client-generators/text/0000-client-generators.md https://github.com/prisma/rfcs/blob/client-generators/text/0...

For Kotlin/Java you can probably use jOOQ (https://www.jooq.org/ https://www.jooq.org/)

Written in Scala, has a "greyed out" Python and Java client icon in the diagram at the very top of the readme, and an issue from Jan 2018 querying about a Java client which has had barely any traffic. That's slightly weird, bit of a mixed messages situation! Epilogue: Caveat emptor, rambling ahead. I probably shouldn't write comments when I'm tired. Hasn't type safe ORM mappings and/or middleware, code generation, been done to death, at least for the JVM languages? However, as I've been out of the Java loop for a bit, I'm not 100% sure of the stage of ORM like tools/libs today, I might be wrong. If the admin UI is spectacular, and the migration flawless even with a fair bit of data, those could be useful tools. Neither are easy tasks though. But still, I have to wonder, is there actually more ways to try to do it, to connect code and relational/graph data? Feels like there has been so many attempts and that all of them has shown to have their various, by now, surely rather well known limitations? Better is always possible, though. However, except for mixing in a bit of graphql and having an additional server, I can't really see what it is they claim is so different? Though I've been out of the loop for some year I can't have been the only one that have implemented/integrated a graph querying language on top of a ORM(-like) mapping with code generation, similar to Prisma? Or are there really no decent tooling of that kind, still? Except for admin UI and real-time, I wrote something very similar back in 2007, or something like that. Unfortunately my client weren't interested in open sourcing it, back then it could have been somewhat original. If I recall correctly, it was a customized Hibernate in the bottom, some code generation for Java - ASP - php - and maybe perl - clients, some fancy dependency injection. Connect to the database and you got generated all code that was needed for a service you could query for tree fragments of almost arbitrary shape. Essentially a GraphQL light I quess, as GraphQL wasn't available at the time, if it existed at all. The http API used JAXWS I believe and it exposed few endpoints for some REST-ish+JSON and SOAP You could do transactions over multiple requests if you wanted to, and weren't easily scared. It could obviously prune circular graphs into trees, although that code had a few fun bugs initially. No streaming though, as the client didn't need it.

hokumguru 8y ago

Prisma is meant to be a backend ORM so a swift implementation makes little sense.

nikolasburk 8y ago

(I work at Prisma) That's a great question! We started with a major focus on GraphQL which has now become more generic as Prisma can really be used for any app that uses a DB (REST, gRPC, ...). With that GraphQL history, we've put a lot of focus on the Node/TypeScript ecosystem because that's where GraphQL tooling is most mature. However, we're definitely planning to support more languages in the future. In particular, we are opening the generator API for the Prisma client which means it will be possible for anyone to implement the Prisma client in their own preferred language: https://github.com/prisma/rfcs/blob/client-generators/text/0000-client-generators.md https://github.com/prisma/rfcs/blob/client-generators/text/0...