The future of Nexus Prisma Plugin #1039
Comments
|
@martzoukos Thanks for the update and the work you guys are doing...are you able to provide a rough estimate/timeline of when this new version of the plugin will be available? I think that would help those of us trying to decide whether to ditch the plugin or wait it out with the current version. Thanks! |
|
Hey @narciero , that's a good question. Our current estimates are end of Q1 or beginning of Q2. We're still early in this journey, so we'll be able to provide more frequent and accurate updates in the coming months. |
|
Thanks a lot for this update. This is good news 👍 I think the community can help to maintain the current codebase to match future version of prisma and let you guys focus on the next version. I already made a PR (#1033) to support prisma 2.15.0. |
That would be amazing 👌. Any help is appreciated! Thank you Luc. |
|
Excellent news for the long-term stability of Nexus / Prisma integration ! |
|
Please support multiple Prisma clients! :-/ #992 |
|
Side note — Are there other companies using Prisma and/or Nexus in production settings? If so, I would love to reach out to you and create a "support group" of sorts as we work through what this all means, and what good paths forward remain. My email is on my GitHub profile. My guess is that our needs are a bit different from folks just building smaller projects or using these frameworks as gateways to experiment with GraphQL. All these transitions and migrations have serious capital and productivity costs. Every migration as a package gets deprecated is expensive, and often we make these calls expecting that the migration will be the last one for a while. While I don't mean to be negative or ungrateful, we've just spent weeks migrating over from Nexus Framework after the migration guide for it specifically mentioned "Nexus Schema Prisma plugin is not being shut down." A stop of all bugfixes and being pegged to an old package is certainly cause for concern. Of course, I'm very appreciative of the open source community and developers working hard to improve this project, which I understand can mean making tough decisions like this. It's just that the business side of me needs to make practical decisions; the developer side of me wish you all a great rewrite & success story! |
|
Hey everyone! We just published the first half of the migration guide covering the migration from I also would like to add a few things to Spiros' (@martzoukos) initial message above! We are very aware that the decision to rewrite the plugin and temporarily remove support for it came very suddenly and without prior notice. This understandably caused a lot of frustration among a lot of you and we want to sincerely apologize for that! Note that during the rewrite we'll try to merge PRs from the community on a best effort basis that helps keep the plugin in sync with Prisma releases. Shoutout to @lvauvillier for his amazing work on the first PR! 💪 As Spiros mentioned before, the plugin had been initially developed in a very short period of time and accumulated a lot of technical debt since its initial release. Little thought went into architectural decisions at the beginning which left the entire codebase in a "prototype" state. Additionally, several organizational changes at Prisma over the past year had led to it not having a clear owner within our organization. This resulted in poor internal and external communication about the general state of the plugin and its codebase. We are very sorry for the frustration this poor communication has caused. We understand that a lot of you are building mission-critical software on top of our tools and these kinds of changes have real impacts on real businesses. While we strongly believe that a rewrite is the only viable path forward to maintain the plugin long-term, we want to help you as best as possible when making decisions about how to move forward with your stack. Feel free to reach out to me personally or leave a comment in this issue if you have any further questions! We also want to emphasize that we're doing our very best to not end up in a similar situation again! The good news in that regard is that the plugin now has a dedicated Product Manager (@martzoukos) with a commitment to make it a proper long-term solution for folks that want to build GraphQL servers with Prisma and Nexus. Additionally, you can now also track the development of the rewrite on Prisma's official roadmap. |
|
I don't get the enthusiasm here with dropping the support of new prisma versions. There is literally nobody here that uses Nexus Prisma plugin in production? I guess that you don't care about keeping up to date with the "stack" that you have been slowly forced over the time and now peacefully accept that we will stop for a few months till it will be ready again so we can update our projects. Then after a year or two same thing will happen again, and again. The same thing happened with Yoga, then with Nexus "project" itself, and so on. I think the size of "product" reached some level and it should be kept update till new version is available. Same as with the Prisma migrate. |
|
And I would like also add that I am pretty sure that a lot of people using this in production don't have any idea that this will happen and would be very surprised about this decision. |
|
I have been frustrated as well, especially with the Nexus framework deprecation. But at the end of the day moving fast and breaking things is what enables the end product to become so **** good. Our confidence and productivity would never have been the same without the tools that you're making, even after taking migrations into account. As soon as it stabilizes, I can't even imagine, how fast we'll be able to move. Thank you for creating so much value for absolute free. We look forward to becoming a customer at some point. |
|
The current plugin has lacks of control on what capabilities cruds exposes. Some nested operation are available (create, connect etc.) and it can open serious security issues. This results on a lot of extra code and validation / filtering hacks before going to production which breaks the main purpose of this plugin: simplicity. After spending some time in the plugin codebase to figure out how to add hooks to add more control, i agree that adding new features is currently painful. I'm really happy to hear that Prisma takes it seriously and start a complete rewrite having this in mind, this is a really good thing. For people that are using it in production: The rewrite is planned to end of Q1 / beginning of Q2, so this is a relatively short timeframe and Prisma Team now accepts community PR to support new version of prisma 🙏. I just don't understand why you are pushing to remove the plugin. If you can share the new API draft, this will definitely helps us to make a decision to wait the new version or to start removing the plugin. |
Yeah, it does not make any sense. |
Sorry if this was misinterpreted: I don't think we're pushing anyone to remove the plugin but we definitely want to provide the option for folks who want to do this, that's why we're publishing the guide. I elaborated a bit on in which scenarios it might make sense for folks to remove the plugin from their projects on Slack today:
Screenshot of the Slack convo
So, ultimately, this is a decision that you need to make in the context of your project (the good ol' "it depends" 🙃 ). If you have any questions and would like some individual advice, don't hesitate to reach out to me!
We definitely want the development process to be transparent and share as much info as possible with you. I've raised this internally and will keep you posted about any updates in that regard! 🙏 |
|
I'm confident, that the community will manage to bridge the migration time with keeping the prisma version up to date :) |
This comment has been minimized.
This comment has been minimized.
|
@jasonkuhrt Thank you for sharing those design sketches. It was very helpful for me to understand the general direction y'all are heading when evaluating what I wanted to do about our current nexus-plugin-prisma usage. Thankfully we were mostly just using |
Same happens with GraphCool, Prisma 1, Nexus Framework, now this. I have a big project running on Prisma 1, with no more support, and basic missing functionalities (they promise to finish soon hehe of curse). Prisma guys, you need to find better guidance |
With any package that is tagged 0.xx.xx, you are taking the risk of having stuff like this happen. Their liability ends at the right semver semantics. If you include such a package into your business critical path, the risks are on you and you need to have developers ready to swap out the next version. |
|
I agree with @homoky. I use Nexus Plugin Prisma in production for internal back-office projects and so I use CRUD feature a lot (really). Dropping support for this wonderful plugin is a big shame for me and migrating to a "native solution" (see @nikolasburk proposal) is just impossible (too much work, regression risks, etc.). Anyway, I don't want just to complain, I want to thank you Prisma team to your amazing work. I will be patient and looking forward the new Nexus Plugin Prisma no matter what :) |
|
An initial unstable release will be coming this Tuesday. You can check it out here as a PR currently https://github.com/prisma/nexus-prisma/tree/feat/emit-model-props-scalars. Unstable releases will be cut every sprint (2 weeks). Same interval as Prisma Client. Unstable releases mean less than 1.0.0 😊. These releases are not intended for production, are missing features, tests, etc. The GitHub gist from before is now out of date and attention should be directed toward the repo, issues there, etc. Marking that comment as outdated now. I already have some ideas that need writing up about how |
|
Do you expect the GraphQL schema (specifically, meaning filters, order-by, and pagination) to be the same with the new plugin as with the old one? Meaning, without a ton of boilerplate that I have to do myself, would my consumers of our QL API not notice that we migrated from the old to the new? Do you expect this to be the case on the root crud query/mutations as well as the model's (including if we use filtering/etc on those models)? |
|
@cmidgley Hard to say but I think it would be great if the high-level Nexus Prisma API were flexible enough to do that, or at least come close. I could see the current one being like a subset of the new one potentially. However, zero effort on your part and zero noticing change by your API consumers part is an unlikely nirvana. So strictly speaking the answer is no. But maybe we can get like ~80% there? We'll see. It might be interesting to go back to a revised spec of something like Open CRUD. Just a default that would then be highly customizable. I wonder if having/using a spec would help users feel more confident about forwarding the contract to their API clients. Anyways, this still far out as we're currently focused on the low-level API which is the Prisma generator. After that we'd probably see what the appetite looks like for the high level API which would be the Nexus plugin. Both neatly packed into |
|
Would be nice if the plugin will support aggregations as well - https://www.opencrud.org/#sec-Queries-Aggregations |
|
I spent at least an hour reading through this (sadly not in order), but at last, I figured out that is going on. Initially, I was happy, that a new more updated plugin will be made, but soon after I read the post "Removing nexus-plugin-prisma from your project". That scared me a bit, but after being able to look at the plugin in development, it all got better. I think that anyone that uses primarily |
Still very confused about the removal, the addition and the link between the orm and graphql. I have the api fine, but the tooling is error-prone, not providing the errors it must. |
|
This past sprint we shipped the beginnings of custom scalars "workflow". Workflow in quotes because what has been shipped is mostly just some convenience and guides. In the next sprint we will probably ship support for projecting enums. Something interesting about this feature is that it was actually never possible with Nexus and Once this lands flushing out the workflow for the remaining custom scalars will probably be a priority. Once that is done it will make Nexus Prisma complete in terms of its generated scalars story and potentially something you might want to use if your use-case fits within this scope. A next juicy item will probably then be relations. This will require automating usage of Prisma Client at runtime and thus a significantly more complex undertaking than the scalars where relying on the default resolvers works in Nexus. Relations will also finally bring to a head issues like pagination ordering and filtering. Further topics will lie within these, such as Relay connection spec compatibility (under pagination aspect). Hopefully that gives some sense of what is on the foreseeable roadmap. --edit We've added a micro roadmap summarizing the above https://github.com/prisma/nexus-prisma#roadmap |
|
Sorry to say but I also migrated to Pothos using it's Prisma plugin. Migration went smoothly and it's maintainer @hayes is also very helpful. To be honest I looked into Pothos already like 6 months but decided then to stick with the Nexus Prisma Plugin - hoping the project would be picked up... One thing to mention for others going the Pothos path is that it will be unlikely that there will be some |
|
Hi guys, I came here to share the project I'm doing to bring to Pothos, something like we had in the old plugin with I think that Pothos is a upgrade of Nexus (because of its no-runtime generation and type safety). Currently, the Pothos Prisma plugin is able to:
But, cant be able to:
I discussed with the Pothos author about the possible implementation of something like we had here. And since those are not the intentions for now. I'm creating a It will generate the InputTypes for all Prisma operations. Then it will only be necessary to import and use as args from Pothos. Something like this: import * as Inputs from './generated/inputs'
builder.queryFields((t) => ({
findManyUser: t.field({
type: [User],
args: {
where: t.arg({ type: Inputs.UserWhereInput }),
orderBy: t.arg({ type: [Inputs.UserOrderByWithRelationInput] }),
cursor: t.arg({ type: Inputs.UserWhereUniqueInput }),
take: t.arg({ type: 'Int' }),
skip: t.arg({ type: 'Int' }),
distinct: t.arg({ type: [Inputs.UserScalarFieldEnum] }),
},
resolve: async (root, args) => {
const user = await db.user.findMany({
where: args.where || undefined,
cursor: args.cursor || undefined,
take: args.take || undefined,
distinct: args.distinct || undefined,
skip: args.skip || undefined,
orderBy: args.orderBy || undefined,
})
return user
}
}),
}))The first release was published at prisma-generator-pothos-codegen - npm This project will evolve, to the point that we can create an entire and customized crud from a Prisma Schema. Having the same thing we had with The roadmap:
It's just beginning, so any contribution is more than welcome. ---- Edit 2022-07-13 ---- Published version 0.2.0 with generator for all Click to see configs options{
inputs?: {
prismaImporter?: string // default: import { Prisma } from ".prisma/client"
builderImporter?: string // default: import { builder } from "./builder"
excludeInputs?: string[] // default: undefined
excludeScalars?: string[] // default: undefined
outputFilePath?: string // path to generate file, from project root
replacer?: (generated: string, position: ReplacerPosition) => string // a function to replace generated source
},
crud?: {
disabled?: boolean // disable generaton of crud. default: false
includeResolversExact?: string[] // generate only resolvers with name in the list. default: undefined. ie: ['createOneUser']
includeResolversContain?: string[] // generate only resolvers with name included in the list. default: undefined. ie: ['User'].
excludeResolversExact?: string[] // default: undefined. ie: ['createOneComment']
excludeResolversContain?: string[] // default: undefined. ie: ['createOne']
resolversImports?: string // default: what to import inside resolver
dbCaller?: string // how to call prisma. default: context.db
inputsImporter?: string // default: import * as Inputs from "@/generated/inputs";
builderImporter?: string // default: import { builder } from "./builder"
outputFolderPath?: string // path to generate files, from project root. default: ./generated
replacer?: (generated: string, position: ReplacerPosition) => string // a function to replace generated source
},
global?: {
replacer?: (generated: string, position: ReplacerPosition) => string // a function to replace generated source
}
}See example: click here ---- Edit 2022-09-07 ---- We published version 0.4.0 with input type field omit from prisma schema. (0.3.0) This changes everything, as now the generated code can be freely replaced, without affecting the customizations already made in the project and maintaining type safety. |
|
Tried https://github.com/hayes/pothos |
|
What ever happened to the good ole days when Separation of Concerns was still a thing? Why are people wanting to couple their API to their database schema? I can only imagine the headaches this must cause. Scale much? |
|
When you're a startup/small company, speed is more valuable than scale. |
It's not coupled, it just reduces duplicating the things that are actually one-to-one. You still have separation and can decide what to expose or not |
👋 Hey strangers, this PR updates this template with a couple of changes. ## Schema builder I decided to switch to [Pothos GraphQL](https://github.com/hayes/pothos) instead of Nexus, because there is [no future](graphql-nexus/nexus-plugin-prisma#1039 (comment)) for `nexus-prisma`, so it doesn't make sense to keep it inside this template. @hayes is doing a great job with Pothos and everything about it is good 🙌 ## Move to JWT I moved the session strategy to `JWT` so it's prepared for edge computing and Next.js middleware. ## New database I decided to move to [PlanetScale](https://planetscale.com), they provide really generous free tier. They are a new cool kid in the block with database branching which is a perfect feature. If this doesn't suit, you can still you another database that Prisma supports. ## Fixes I fixed some problems with types and now it should work as expected. When `JWT` token is not presented, there is a fallback to `userId` and `userRole`. Fixes #29
|
Thx for sharing @homoky @nikolasburk it would be good to update the README's of both |
|
So... does that means that nexus will be abandonned too ? |
|
Even if that could happen in our team we cannot afford immediate migration, we are interested to keep maintenance. Waiting for the final decision, and then based on that we will pick a strategy how to maintain prisma-nexus and nexus. @nikolasburk |
|
In other words, migrating to Pothos is encouraged if long term maintenance is wanted |
But how can we be sure that the same thing won't happen to Photos? |
|
I'd wait for the official statement from the Prisma team, I've seen so many hypes of the year in the past, so I'd invest to long-term maintenance, then migrate every two years to something new. Our colleague did feasibly check and unfortunately, we are not able to migrate to Pothos even though we would like to it's still missing some features, nexus has. |
What features? |
|
Starting migrating to Pothos. And so far I really like it. |
|
Summary from our feasibility check, the following features from nexus are critical for us
Then there is maintainability risk
There are a few others, but mostly minors, we could live with them. |
Thanks for sharing this, it's always helpful to hear what things people are looking for, and might be blockers to adoption!
I'm not sure how exactly what you mean here, but I'll try to address a few interpretations: Pothos doesn't currently have a good way to define standalone types. Currently all types need to be defined through a shared The above workarounds are definitely not an optimal experience, but work well enough once set up. Long term, if this is a common problem we can definitely look into making it easier to build modular types with Pothos that don't require a shared builder instance. I have some ideas on how this could work without significant changes to the current API. The other interpretation of the above issue is you want to generate/export typescript definitions based on types you are defining with Pothos. This unfortunately is not possible. The closes option would probably be using something like graphql-code-generator to generate types based on the built schema. A final note about this: You mentioned wanting to have some intial config that determins what fields are enabled/included in a schema: This sounds a lot like what we do in the SubGraph schema. This plugin effectively lets you declare a set of sub-graphs that fields/types can be a part of, and then on each field/type can decare which of these subGraphs it is a part of. When you call toSchema on the builder, you can pass in one or more subGraphs and it will create a schema with just the fields that declared themeselves as part of that graph. If this doesn't fit your use case, the plugin is pretty simple, and likely could be easily adapted to to something similar that is more specific to what you need.
Adding custom plugins and schema meta-data was one of the core requirements when I first started building Pothos at airbnb. We had specific metadata we needed to attach to each field, so this should be easy to achieve. There are a couple of built in options that would not require anything custom. Every field and type has an There is also a directive plugin, this can be used to define type-safe options that can be added as directives to various parts of the schema. These will also be serialized into an extensions property. This might look something like In addition to these existing options, it is also very easy to add a plugin that adds additonal custom options. In the simplest case, it is as easy as just writing a type decaration for the new option field you want to add. Any option passed to a field will be accessible via
This is definitely a valid concern. This discussion is happening on a thread about a deprecated/unsupported project, so we all know this can happen. I have a lot of feelings about this, and have deleted a few long paragraphs trying to summarize them, but ultimately it comes down to finding the best path forward. There is definitely maintainability risk with Pothos, but I would argue that the risk is less than with any good alternative I can think of. Here are a few things Pothos has going for it from a maintainability standpoint:
The best thing we can do to reduce maintainability risk is to get more people involved. The direction things are heading with Pothos looks very promising, but you are correct that one maintainer isn't great, but it's better than nothing, and I would be very excited to see more contributions from others in the future. |
that actually the problem with Nexus… young package, not very maintained, lots of breaking changes between versions (not really since nexus v1 but I remember the nonNull argument typing struggle). I think @nikolasburk is right and Prisma team should be focused on Prisma itself as it is the main project and intended to not be bound to any backend tech (unlike Prisma1). I also think Pothos deserves to be more spotlighted as it’s good, it provides a fantastic Prisma plugin and could be a very strong alternative to Nexus. If Prisma team officially encourage devs to migrate to Pothos, @hayes will get more support from the community. |
|
@hayes thanks, very helpful.
This is actually ok, we have a mechanism to share singletons to shared packages.
yes, that's also an option.
This is our case, we literally have something like
we would need to investigate this feature more, we somehow misunderstood the concept, because we thought that this subgraph is an isolated subgraph and types can not be shared with other subgraphs.
Exactly that's what we need, but we haven't found our
Yes, I understand, I believe Pothos is an optimistic package but would be good if people would be more careful when proposing sunsetting packages. If there is still a will to maintain the package, then it can live together with others, especially if package was already used in existing solutions. It's not easy and cheap to migrate to another package. It's not just about writing a code but also knowledge, processes etc. That's the nature of production, there is a reasonable obligation to clients that they won't need to invest money every year to refactors. |
|
Hey all. I'm happy that you are coming together to figure out workarounds to your current situation but I'm concerned that this discussion is getting way off topic, potentially also for folks who keep notifications on for a potential update on nexus-prisma. I would kindly suggest that you continue the detailed discussion in another channel, feel free however to come back to share the outcome of your discussions in case they help other folks. Thank you. |
|
Hi guys, while we wait for the new plugin I have brought this old plugin to version 4.5.0 of Prisma. I don't guarantee it will work for you too, my structure is quite simple and works well. |
|
Hello everyone, I'd like to share some positive news on the future of You can read more information in the announcement message and I'm going to close this long issue. I'd like to thank you for your patience so far and all the best from the Prisma team. |
👋 Hey strangers, this PR updates this template with a couple of changes. ## Schema builder I decided to switch to [Pothos GraphQL](https://github.com/hayes/pothos) instead of Nexus, because there is [no future](graphql-nexus/nexus-plugin-prisma#1039 (comment)) for `nexus-prisma`, so it doesn't make sense to keep it inside this template. @hayes is doing a great job with Pothos and everything about it is good 🙌 ## Move to JWT I moved the session strategy to `JWT` so it's prepared for edge computing and Next.js middleware. ## New database I decided to move to [PlanetScale](https://planetscale.com), they provide really generous free tier. They are a new cool kid in the block with database branching which is a perfect feature. If this doesn't suit, you can still you another database that Prisma supports. ## Fixes I fixed some problems with types and now it should work as expected. When `JWT` token is not presented, there is a fallback to `userId` and `userRole`. Fixes huv1k/nextjs-auth-prisma#29
and others
👉 Go to the new Prisma plugin for Nexus: https://github.com/prisma/nexus-prisma
Hello Prisma friends,
it has not been a secret that maintenance work of the
nexus-prisma-pluginhas lagged behind the past few months. In this GitHub issue, we want to provide an update on the current state of the plugin and give you a taste of what is coming next.State of the codebase
The initial version of the codebase was created in a short period of time and has accumulated a lot of technical debt since then. This makes it difficult for us to maintain, and even more difficult to bring new features to the plugin at the moment.
The new Nexus Prisma Plugin
Considering the current state of the codebase and the varying types of issues, it is clear to us that we need to take a step back and, with all the accumulated knowledge so far, rethink how we want this to work.
The vision we came up with is a lighter plugin which will replace the current API (like
t.modeland the experimentalt.crud) with a set of more programmatic capabilities for you to iterate over your Prisma Schema and create functionality like the existing and more.This will allow us to properly maintain and support this new plugin surface in the long term and it will enable you to solve many of the issues you face like iterating over a large number of models or creating custom middleware.
What happens in the current releases
The unfortunate news are that in order to focus all of our efforts in the new version of the plugin, we will need to limit our time in maintaining the current versions, so we will have to temporarily drop support for the current versions of the plugin, which means that:
nexus-plugin-prismafrom your application. We also plan to write a migration guide for this and we'll let you know in the coming weeks about it.We apologize for the inconvenience and the delay in resolving your issues! Hopefully the improvements we introduce will make your wait worthwhile.
Let us know if you have any questions by posting a comment in this issue, we're always happy to help! 💚
The text was updated successfully, but these errors were encountered: