prisma-binding icon indicating copy to clipboard operation
prisma-binding copied to clipboard

Proposal: Binding as installable package

Open akoenig opened this issue 6 years ago • 3 comments

Creating Prisma bindings is already a nice solution. Can't imagine how much effort we all would put into it if we had to create / maintain it manually.

Although the experience is already quite nice, I think we could improve DX even further by establishing an endpoint right in the Prisma server. This endpoint could generate a npm package with the generated prisma-binding on the fly.

A npm i http://localhost:4466/myservice/mystage:binding would perform the following steps:

  1. Create a temporary .graphqlconfig.yaml with the respective endpoint
  2. Execute a npx graphql-cli get-schema
  3. Execute a npx graphql-cli codegen (TypeScript as default language)
  4. Create a package.json
  5. Execute a npm pack for creating the tarball
  6. Send the tarball in the response

The behaviour of the package generation could be controlled by passing parameters to the query string, e.g. http://localhost:4466/myservice/mystage:binding?language=typescript, etc.

With that in place, we would have a similar mechanism like installing a SDK from npm.

Happy to hear your thoughts on this 🙂

akoenig avatar Sep 02 '18 14:09 akoenig

Thanks a lot for this great suggestion @akoenig. We're currently working on the next generation of Prisma bindings which will be called the "Prisma Client". There will be a new prisma generate CLI command which allows you to generate the client library without the need for graphql-cli or a .graphqlconfig.yml file.

We're planning to release a beta next week. Would love to hear your thoughts!

Once you've tried out the new Prisma Client beta, please let us know if you still think there should be an endpoint for the client generation.

schickling avatar Sep 03 '18 08:09 schickling

@schickling Oh wow, Prisma Client sounds awesome. Really looking forward to it.

Ditching the need for using graphql-cli eases the process tremendously. Great news!

One thought on this though: In my previous projects there was a clear separation between the API and the actual data model (the Prisma service). They even were separated into own repositories. With Prisma Client in place, I would need to install prisma as a devDependency in my api project as well (for pinning the version). Furthermore, I have to execute prisma generate manually to create the actual binding. Treating the binding as a dependency would, IMHO, streamline the whole process even further. An ordinary npm i in the api repository would be sufficient to have my binding in place.

akoenig avatar Sep 03 '18 10:09 akoenig

Would also greatly appreciate the suggestion @akoenig made, it would simplify things quite a bit for developers that maintain mono-repos / microservice architectures.

Inkdpixels avatar Sep 26 '18 12:09 Inkdpixels