The future of Nexus Prisma Plugin
martzoukos opened this issue · 146 comments
👉 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-plugin has 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 experimental t.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:
- We will not be able to fix any issues for the current versions of the plugin.
- No new releases of the plugin to keep it up to date with new Prisma Client versions will be made, so the latest supported Client version is 2.14.0. If you want to use the newer Prisma versions, you can remove the Prisma plugin and still enjoy the Prisma benefits with Nexus. Feel free to reach out to us (e.g. on Slack) if you have any questions about removing the the
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! 💚
@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.
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.
That would be amazing 👌. Any help is appreciated!
Thank you Luc.
Excellent news for the long-term stability of Nexus / Prisma integration !
Middleware support is exciting stuff, are there public RFC somewhere ?
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 t.model() to vanilla Nexus here. The path to migrate CRUD operations from t.crud() will be added very soon, sorry for the delay! 🙏
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.
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.
I just don't understand why you are pushing to remove the plugin.
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:
- Do you want/need to upgrade your app to the latest Prisma release in the next few months? If yes, you should probably migrate away to be able to do that. If you don't care about upgrading your Prisma versions too much, you can consider keeping the plugin as is. Also note that we're merging PRs that keep the plugin in sync with Prisma releases on a best effort basis, so in the best case it can be kept up to date for the coming weeks (however, since it's on best effort basis, we can't fully guarantee this).
- The rewrite of the plugin also most likely will come with a new API, resulting in breaking changes. Therefore, even when upgrading to the rewritten version you'll need to make changes to your codebase.
- It also depends a bit on the size of your datamodel and which features of the plugin you're using. If you're using mostly
t.modelwithout pagination, filtering and ordering enabled on list relation fields, the migration should be very quick. If you are using these pagination, filtering and ordering capabilities and/ort.cruda lot in your API, the migration will probably require you to write a lot of boilerplate in which case you have to be aware that this migration might be quite a time investment. (By the way, if your entire API is only based ont.crud, you might even consider switching to TypeGraphQL which similarly to the Nexus plugin provides a very quick way to generate a full CRUD API for Prisma models, we we just added one to ourprisma-examplesrepo.)
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!
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.
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 :)
@lvauvillier Right now we can offer access to raw unfiltered hot off the press design sketches. Anyone looking for something simple polished clear and succinct should not look at this. This is raw stream of consciousness stuff.
https://gist.github.com/jasonkuhrt/fb5dcb58ba9bf68123460138cb17bc40
This gist won't last for too long. Work will be happening in https://github.com/prisma/nexus-prisma and issues will start emerging there.
I still believe that there were design breakthroughs in Unified computed & connect & create CRUD config worth trying. I am generally happy with that spec. But before getting to more opinionated abstractions we want a solid simple maintainable data foundation that provides the ultimate escape hatch and primitive for your abstractions, not just ours.
@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 t.model so the migration to vanilla nexus shouldn't be too bad. Although I was initially a bit frustrated, when I look at how little we're actually using nexus-plugin-prisma due to shortcomings (t.crud exposing too much, wanting to use relay pagination etc), it makes a lot of sense to start back at building good primitives.
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.
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
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.
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.).
I used Yoga and Prisma1 in production once. I'm a really big fan of Prisma since the very beginning and like @homoky said, it was very painful each time Prisma team drop one of it product support. You have each time to find (quickly) a proper and production-ready alternative (write my own subscriptions, convince my boss to use experimental migration engine, writting raw SQL, ...). My biggest fear about prisma plugin support drop is that the rework will miss some of the current plugin features (like CRUD capability, which is a top requested feature in my case).
On another hand, it's very cool to see Prisma team is perfectionnist and always seek a way to do things more efficiently. I'm really supportive for that way of thinking but don't let your fans down guys :). Even if you don't add more features until the rework, please at least made it compatible with lastest Prisma versions (even if new Prisma features are not supported, that's fine for me)
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 nexus-prisma will be a dual Prisma plugin and Nexus plugin nexus-prisma/plugin, indepently usable as such. Maybe they will complement each other even but so far no ideas about that. I'll try to pen some specs about how I'm seeing this in the coming week or so.
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 nexus-prisma package.
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 model will be able to transition easily.
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
modelwill be able to transition easily.
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 nexus-plugin-prisma. While this was because of a limitation of the Nexus API that in theory could be lifted, it is still valuable that the new Prisma generator approach gives us another way to solve the issue. Refer to the issue for details.
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
I though a little about CRUD feature and in fact the concept very simple. It’s just about using prisma methods with args from GQL requests. But in fact, the real pain is the args!
Writing your own input types can be very long and complex to match prisma capabilities. The current plugin is fantastic because of it. One big and wonderful feature for the new prisma-nexus would be the possibility to generate « CreateDataInput », « UpdateDataInput » « WhereInput » « WhereUniqueInput » and also all filters (string, int, float, etc.) and orderBy inputs. With this kind of feature, no need for t.crud anymore, just generate the inputs you need and use it in a very simple request that use prisma client :)
if you fear that it exposes to must capabilities to the users it could be interesting to restrict which properties will be generated (t.model-like feature ?).
I wrote this comment on my phone, so making an example is hard but tomorrow I will try to do it with my computer
@MikaStark I agree with you, but the difference between what you suggest and with giving the crud api that will also generate the prisma api itself is small. I think Prisma should give us the possibility to do what you suggest, but also to generate the standard use cases, like the t.crud that exists today.
Here is a proposal for my previous comment (It can be very long, so I only focus on posts query but the idea could be the same for everything).
The main idea is to generate a list of inputs with a bundle of helper functions.
The good points
- the dev can control every inputs he wants to expose
- every types are generated by the dev and are passed to nexus, so there is no magic
The bad points
- that represent a lots of code
- you have to expose scalar filters by yourself int the first place
import { makeSchema, list, nonNull, objectType, queryType } from 'nexus';
import { inputTypes, orderByInputs, scalarFilterInputs } from 'nexus-prisma';
// expose all scalar inputs you want
const FiltersInputs = scalarFilterInputs([
// GQL scalars
'ID', // is it useful?
'String',
'Int',
'Float',
'Boolean',
// Prisma scalars
'DateTime',
'Json'
])
// expose Post "Where" input
const PostWhereInputs = inputTypes('Post', {
// expose PostWhereInput and all its sub-inputs
where: [
'AND',
'NOT',
'OR',
'id',
'title',
'content',
'author',
'createdAt',
'updatedAt'
],
// expose PostWhereUniqueInput and all its sub-inputs
whereUnique: [
'id'
]
})
// expose PostOrderByInput
const PostOrderByInputs = orderByInputs('Post', [
'id',
'title',
'content',
'createdAt',
'updatedAt',
])
const Query = queryType({
definition(t) {
// CRUD is fairly easy now
t.nonNull.list.nonNull.field('Posts', {
type: 'Post',
args: {
orderBy: list(nonNull('PostOrderByInput')),
skip: 'Int',
take: 'Int',
where: 'PostWhereInput',
},
resolve: (root, args, ctx) => ctx.prisma.post.findMany(args)
});
},
});
export const schema = makeSchema({
types: [Query, ...FiltersInputs, ...PostOrderByInputs, ...PostWhereInputs],
});@jasonkuhrt It's great to see the Prisma team moving so fast on the new plugin. Has any consideration been given to properly adding support for cursor based paging? This is one of those areas that is a necessity in most production applications and an utter p.i.t.a to put in place. Second, any thought as to additional generation support to tie in more closely with frameworks like NestJs?
Has any consideration been given to properly adding support for cursor based paging?
Once pagination comes up I would definitely expect Relay connection spec to be top of mind. We would be using that feature ourselves in Prisma Cloud so that helps drive the development here.
Second, any thought as to additional generation support to tie in more closely with frameworks like NestJs?
Anyone is free to make their own Prisma generator of course but to my knowledge we don't have plans to be writing the generators for other frameworks. Nexus is an exception for historical reasons.
@MikaStark Not there yet but yep this area will require some consideration. All ideas welcome! I've thought also about a generate-time config like nexusPrisma.config.ts that would be called at generate time and be allowed to customize what gets configured. For example right now any @id field gets mapped to an ID graphql type. But maybe some users want that mapped to Int when the field type is Int in their Prisma model. Such a "generation config api" would probably serve many CRUD customization use-cases.
@jasonkuhrt There hasn't been any news in a long time. Any updates ?
I am starting a project soon and I would love to use the new prisma plugin.
Also, for me and for most others (I guess), the most important feature is t.model. If you can ship that fast in the new plugin, we could start using it.
Just stumbled upon https://giraphql.com/ which seems very similar to Nexus and I was wondering if both project could somehow benefit from one another, especially in regards to a future prisma integration.
Hey @jasonkuhrt, @martzoukos, @nikolasburk
Many of us have been waiting patiently a while now for any update on the progress of the new plugin. The nexus-prisma repo even tells us to check in here for updates.
I completely understand that road blocks can appear, and that you guys are busy with several projects. I dont expect you to check in every day, but a little more frequent updates would go a long way in rebuilding trust around this project.
Considering the history of nexus framework and nexus-plugin-prisma, the lack of updates and communication does not exactly strengthen my belief that you are commited to this project (this lack of communication/updates was also the precursor to the announcement of ending nexus framework development).
I have been using nexus and nexus-plugin-prisma in production for a while and was considering using it again for my next project because I really love using these libraries and I greatly appreciate all your work on them. However, I have to consider alternatives right now since I have no idea where this project is headed.
I second what @orjellingsen is saying -- and others. For myself, I have a few projects that have been postponed in hope and anticipation of the new nexus system.
I would recommend, from my point of view, to stick just with nexus without nexus-plugin-prisma. I found out that even in old projects with old nexus it still works and could be easily updated if there are no dependencies to prisma ecosystem. Implement it yourself even it cost you some more time. From my perspective, it is worth it because you are not tied to updates of this plugin and you don't even need to worry about its future anymore.
I would second what @homoky has said. With the api updates to Prisma, it was causing our GraphQL types to update outside of our control. This lead to client api requests failing due to a GraphQL type mismatch. The previous version of the plugin is great to bootstrap but there is a large loss of control between the client and the database that the api is meant to serve.
I am interested with what the new plugin may hold but think it is wise to continue without it for the time being.
Hello @orefalo ,
Thank you, and everyone else, for your patience with this project so far.
The first thing I want to say is that the project is still ongoing. Our only plan for it is to continue development, so I want to get these concerns out of the way.
Now, about the recent radio silence, I just want to ask for your understanding as we have been extremely busy, the past month, with launching this other thing. We had hoped that this last 4 weeks sprint would have accommodate some wiggle room for some work on nexus-prisma but that was just not the case.
As the launch seems to be going okay and we will resume our previous pace, we will pick up work on it again next week. Expect a more specific update from @jasonkuhrt towards the end of next week, about the next steps and rough timeline. "End of next week" as we are already having chats internally (middle of next week) about a first release of the plugin.
Hopefully we will have released something so robust that even @homoky will convert :) .
I am looking forward to it. Thanks, @martzoukos for the feedback.
Thanks for your response @martzoukos.
Like I said before, I greatly appreciate everything that you all do. I really want your products to succeed so I can keep using them, which is why I made my post in the first place :)
I am glad to hear that development is still underway, and I look forward to seeing the next release!
@homonky @dominichadfield Thanks for the input. This will probably be my way forward while waiting for the plugin :)
Hey everyone, update from my side.
I will be spending tomorrow and next week getting the new plugin to a state ready for its first launch. Regarding if this be a 1.0 or more 0.x we are not sure yet.
The work will centre on the short/mid-term listed here https://github.com/prisma/nexus-prisma#roadmap.
Thanks @jasonkuhrt for your work!
I don't see anything about inputTypes generation in the roadmap. And this is what takes the most time for us, especially the Prisma filters. Any plan for that ? I think it's an essential feature for the v1 milestone.
@durdenx long term yep, that falls under the t.crud like functionality which isn't broken down right now in the roadmap. So it is in scope, just without a clear ETA. There is still a fair bit of brainstorming needed around that topic. My hope is that some simple 80% solutions can come out sooner rather than later but we'll see.
Are the long-term (t.crud, etc.) milestones included in the production release? I would like to know what to expect from the stable release. I’m sure it’ll cut down a lot of boilerplates very very quickly.
Anyway, this is such an amazing piece of software 👏🏻👏🏻. Thank you Nexus team for making our lives a lot easier 🎉! Hope to see upcoming updates very soon.
Is there any way I could contribute to speed up development? I am using the old nexus and I love it. Would be a pleasure to be able to contribute to getting the continuation to a stable version with all the important features that the old one had.
@bruno02100 I'll try to keep well defined issues on the new repo so that its accessible to that kind of open collaboration. Unfortunately the exploration heavy parts don't lend themselves to that however I can start documenting the simple things that I don't have time to get to that maybe others can! I can't think of what those are off the top of my head as they tend to be small and come-and-go. I need to capture them when the observations happen. 🥅 🏒
I'm just about to start a new project - can someone point me into the right/best direction on what I should be using? I still get tripped up on the differences between nexus-prisma-plugin and nexus-prisma.
You have two choices :
- use the current nexus-prisma-plugin and keep in mind that you will have to migrate later to nexus-prisma (they are complete different techs that fulfill the same purpose). In my opinion it’s the best way as it’s production ready, easy and save a lot of time.
- Use nexus and prisma without any plugin (vanilla). But it may require a lot of code if you need all features (pagination, multi filters, expose crud, etc.) but if your project is small and doesn’t need complex logic you may find this solution appropriate.
the eventual third solution is to use the early nexus-prisma plugin but it’s not production ready and breaking changes may come sooner or later.
for the two previous solutions you can easily use the examples provided by prisma team. They are fantastic.
Just chiming in, for vanilla nexus and prisma, yes it requires more efforts like duplicating your objectType to match your Prisma model, not to mention that if you need to handle relation fields, CRUD, pagination, filtering, sorting for every entity.
It may sound tedious, but once you try to do it, I find it not as bad as it initially sounded. In fact, thanks to the Typescript type completion, composability, and schema-resolver colocation, writing your API almost gives you a joy, not kidding.
Also I found out that in most cases you wouldn’t need all the filtering and sorting that the old plugin gives (every fields for every entities). So it’s perfectly fine to add more options as you go. And as a result 1 complicated entity file would require 200-300 LOC and this already includes fully customized several relation fields, sorting, pagination, filter, complete CRUD operations, field authorization. And best of all, it’s already type-safe. In addition to that, if you find yourself repeating over and over (for example when defining the pagination arguments, or authorization logic), you can always refactor it and bring those LOC down.
I can subscribe to what @jasonlimantoro is saying. I also switched from nexus-plugin-prisma to vanilla nexus and was surprised how fast I could write all those types by hand. I first tried automatic type generation with PalJS but I could not figure out how to switch their implementation of non-nullability by default to the nexus style nullability by default so I decided to write my types manually. Custom code snippets also come in handy when implementing similar patterns in resolvers.
I also think my API is getting better in a sense that I really have to think about which filters/sorting options I really need and then implement only the specific types and optimise database indexes accordingly.
When you are working on big back offices or management tools you need a large bundle of capabilities like crud and filters on every entities. So vanilla is a pain to implement such needs.
Again it may depend on your business/project. There is no magic solution.
@MikaStark You can always create your own generators. https://gist.github.com/deckchairlabs/8a11c33311c01273deec7e739417dbc9
I just tried to migrate to vanilla and I finally gave up. This is so massive to expose each filters, types etc. even when using SDL converter...
Also I have composed primary keys and when you are using vanilla you have to expose each ones (in the following example siteId and position. I don't want to expose siteId) otherwise Typescript will throw you an error (parent type is deduced from objectType definition).
export const FooterLink = objectType({
name: 'FooterLink',
definition(t) {
t.model.position()
t.model.link()
},
})VS
export const FooterLink = objectType({
name: 'FooterLink',
definition(t) {
t.nonNull.string('siteId')
t.nonNull.int('position')
t.nonNull.field('link', {
type: 'Link',
resolve: (parent, _, { prisma }) =>
prisma.footerLink
.findUnique({
where: {
siteId_position: {
position: parent.position,
siteId: parent.siteId,
},
},
})
.link(),
})
},
})Well, after giving a try, I just don't recommand to switch to vanilla for dashboard/back-offices. In my opinion, you will lose a lot of time and get frustrated.
Maybe vanilla can fit to other kinds of project. But, if you need a large bundle of capabilities, keep using nexus-plugin-prisma
I understand the pain @MikaStark. My project is also backoffice-related with 20 entities and up to 50 APIs 😅, 10+ relationships (1-m,1-1,m-n) . Did the migration from type-graphql within 1 week (including writing the tests). It was an improvement of my life but of course it was not ideal. Prisma also has a gotcha for the cascade delete that doesn’t work out of the box, just to warn everyone.
Although we have contrasting opinions regarding the tool, hopefully we can agree that the new and robust nexus prisma plugin will definitely make our lives easier.
We just cut https://github.com/prisma/nexus-prisma/releases/tag/0.26.0 which brings some support for relation fields. Special thanks to @lvauvillier for doing much of the heavy work there. Also shoutout to @iddan for help on the new configuration system.
I finally did it 🥳 ! I successfully removed the old plugin. It wasn’t so hard, in fact if you just expose features you only need it can be done quick. So now I can’t wait to see the futur plug-in 👍
Any status on this project?
@KrychuTM no longer maintained, focus has shifted here https://github.com/prisma/nexus-prisma
@KrychuTM no longer maintained, focus has shifted here https://github.com/prisma/nexus-prisma
????? Then whats this - https://github.com/prisma/nexus-prisma
The roadmap is posted on the nexus-prisma readme. The link you referenced above is the active project
You can use the actual nexus-prisma-plugin but no new feature will be added. Eventually, it will support later prisma version.
For now, it’s recommended to remove this plugin from your project and use vanilla Nexus code. It will require a bit more code but I can assure you that it’s not so hard (just done it few weeks ago in 2 days)
Nexus-prisma is a whole new project that is a full replacement for nexus-plugin-prisma. For now, it’s in a early access state and you should not use it for production. But this project is promising and you should keep an eye on it.
There is immense progress being made in nexus-prisma. There are tasks there that we, the community, can take care of.
Nexus Prisma Plugin is great! Literally speeds up the Dev process exponentially (well, it's all Nexus and Prisma that do this, everything involved makes life so much easier).
Since the Prisma team is no longer supporting Prisma version updates, I forked the repo and will be separately keeping it up to date renamed as @kenchi/nexus-plugin-prisma.
Note that you need to add the following to your .npmrc since it's hosted on Github:
@kenchi:registry=https://npm.pkg.github.com/
I'll keep it in sync with Prisma versions, at least until nexus-prisma is in a more mature place.
Huge thanks to the Prisma team for all their hard work! I totally understand why they're deprecating this in favor of nexus-prisma, and am excited for the new library.
Hi. Thanks you contribute for open source. I had written an issue about feature of nexus-prisma. The link is in here Generating type names end of specified suffix for avoiding conflict of name of GraphQLObjectType
Since the Prisma team is no longer supporting Prisma version updates, I forked the repo and will be separately keeping it up to date renamed as
@kenchi/nexus-plugin-prisma.Note that you need to add the following to your
.npmrcsince it's hosted on Github:@kenchi:registry=https://npm.pkg.github.com/I'll keep it in sync with Prisma versions, at least until
nexus-prismais in a more mature place.Huge thanks to the Prisma team for all their hard work! I totally understand why they're deprecating this in favor of
nexus-prisma, and am excited for the new library.
@bkrausz Any chance you could publish to npm? We're having trouble getting this to work with yarn
@bkrausz Are there basic tests in your fork against the various Prisma releases to address possible breaking changes that could occur? Or are you simply incrementing the peerDep version to match the latest prisma release?
@bkrausz Are there basic tests in your fork against the various Prisma releases to address possible breaking changes that could occur? Or are you simply incrementing the peerDep version to match the latest prisma release?
I'm running the same full test suite and intend to fix basic issues
Also let's take any future discussion to that fork's issues so as not to push this thread off topic.
A number of improvements were made to the current feature set over the past week bringing more stability and polish. The iteration these past few days ended with sketches of an upcoming feature, the biggest in months, about customizing the name mapping between Prisma and GraphQL.
You can checkout my comment laying out some thoughts here graphql-nexus/nexus-prisma#102 (comment).
Aside from bugs and staying on top of Prisma releases, that issue is next up.
It will hopefully ship sometime in September but we'll see.
This issue opens up a big new API surface area frontier and will be a gateway toward things like customizing pagination, ordering, etc.
Another noteworthy aspect of the past week is how we've stayed on top of testing. I'm taking that pretty seriously so for example we have a growing suite of e2e tests to make sure things like "bundability" is working (our current test covers @vercel/ncc).
I just gave it a try and it seems to me like you can “have your .crud and eat it too“ by just having both @kenchi/nexus-plugin-prisma and nexus-prisma as dependencies in package.json. Their respective configuration and build-time behavior don't appear to interfere with each other, and you can do t.field() in your objectTypes and t.crud.User() in your queryTypes.
Edit: if you only use .crud() and not .model (as the latter is now covered by the new prisma-plugin implementation), you can set shouldGenerateArtifacts: false in the declaration for the “old” plugins: [nexusPrisma({...})], which is even better (easier to reason about). Example:
export const schema = makeSchema({
plugins: [
nexusPrisma({
experimentalCRUD: true, // Make `.crud()` available
shouldGenerateArtifacts: false // No `.model`, no out-of-band typegens, no fuss, no muss
})
]
})
Does anyone use next-auth with nexus? I am trying to upgrade this project to not use the plugin. Is there an example I can go off to update the User .crud to get the current user?
I'm lost on the whole query section in removing nexus-plugin-prisma
@nrgapple You can check official example https://github.com/prisma/prisma-examples/tree/latest/typescript/rest-nextjs-api-routes-auth
By the way, my template use rest-api for auth and graphql for other things. And i planed to upgrade prisma and delete nexus-plugin-prisma this week.
- It also depends a bit on the size of your datamodel and which features of the plugin you're using. If you're using mostly
t.modelwithout pagination, filtering and ordering enabled on list relation fields, the migration should be very quick. If you are using these pagination, filtering and ordering capabilities and/ort.cruda lot in your API, the migration will probably require you to write a lot of boilerplate in which case you have to be aware that this migration might be quite a time investment. (By the way, if your entire API is only based ont.crud, you might even consider switching to TypeGraphQL which similarly to the Nexus plugin provides a very quick way to generate a full CRUD API for Prisma models, we we just added one to ourprisma-examplesrepo.)
No offensive to Typegraphql but I came here because Typegraphql generator has no support for federation, whereas Nexus does.
The crud api in conjunction with federation support was exactly what I was looking for.
@martzoukos do you think that would be possible to draft some ETA for a stable version, it doesn't have to be something exact, I mean is it expected to be delivered in days, weeks or months, or even years? Such information is kind of critical for the next planning.
@martzoukos do you think that would be possible to draft some ETA for a stable version, it doesn't have to be something exact, I mean is it expected to be delivered in days, weeks or months, or even years? Such information is kind of critical for the next planning.
We are in production with the previous version of this plugin. The last commit made on the new plugin was over a month ago. We need to know if you will ever finish developing this new plugin, and how long it will take. We are stuck at 2.23 with Prisma. The more time passes, the more we risk also in terms of security.
I have nexus-prisma (the new version) running in production for some weeks now without a problem.
I have pinned the dependency and update manually by checking for breaking changes on every release, but it works very good so far. For me the old plugin became unusable, because you are stuck with Prisma 2.23. The new plugin works fine with the latest prisma version.
Of course, using a package with a version <1.0.0 might not be adequate for everyone, but maybe this feedback convinces some folks to try out the new plugin even when it is in early preview.
Hello @rostislav-simonik ,
thank you for your patience. The very vague ETA is in the scale of months to quarters for a stable version, which means everything up to the "Longterm" section in the Roadmap.
Regarding bringing the plugin up to date with the latest prisma version, we are going to work on it in November.
Thank you.
Hello @martzoukos
Thank you for reply about when the plugin gonna progress. How are you doing guys? Half of November passed and how is it progressing, any updates ? 🥇 Love you guys!
Hello @Tuguldurbayar-g !
We are picking up work on it this week. Our preparations for our Serverless Conference went a bit overboard so we got held up a bit but we are resuming it now.
Hello @martzoukos
I am really happy for this project is being developed. Can you guys provide estimated date/time of beta or earliest stable version ?
Hello @martzoukos I am really happy for this project is being developed. Can you guys provide estimated date/time of beta or earliest stable version ?
The latest released (minor version) of nexus-prisma plugin was 19 days ago... :/ be patient
Hello @martzoukos I am really happy for this project is being developed. Can you guys provide estimated date/time of beta or earliest stable version ?
The latest released (minor version) of
nexus-prismaplugin was 19 days ago... :/ be patient
I think most of us are patient. Seems to me @Tuguldurbayar-g was simply asking for an ETA?
Hello @martzoukos I am really happy for this project is being developed. Can you guys provide estimated date/time of beta or earliest stable version ?
The latest released (minor version) of
nexus-prismaplugin was 19 days ago... :/ be patientI think most of us are patient. Seems to me @Tuguldurbayar-g was simply asking for an ETA?
Yes, Definitely. It is my most wanted Package.
What's the status of the support of crud?
Any updates on the stable version?
Hi @martzoukos and everyone involved in this project.
First, I want to appreciate the huge work by the Prisma Company in the past years making GraphQL such popular and develop so many useful tools for it. I have been using Prisma 2 in production for over a year and found this plugin really useful.
But I am really a bit disappointed when the team deprecated nexus-plugin-prisma without providing a production ready alternative, which makes Prisma users unable to update version without fear. We are basically stuck.
I understand that human resources are limited these days and we are using this for free. But please allow me to be impolite here on behalf of many curious people out there. Can Prisma be more transparent about ETA / no. of people working on various projects? We can see the Prisma main package is having a lot of activity and we understand where the funds went. At the same time, if some projects are not going to be maintained in near future, please inform the developers that use your packages, so that we can be prepared to migrate our code to other tools rather waiting without an ETA.
Once again, thank you for all the work. Nexus / Prisma is a good combination and I will definitely try out the new plugin once it's ready
Hi @martzoukos and everyone involved in this project.
First, I want to appreciate the huge work by the Prisma Company in the past years making GraphQL such popular and develop so many useful tools for it. I have been using Prisma 2 in production for over a year and found this plugin really useful.
But I am really a bit disappointed when the team deprecated
nexus-plugin-prismawithout providing a production ready alternative, which makes Prisma users unable to update version without fear. We are basically stuck.I understand that human resources are limited these days and we are using this for free. But please allow me to be impolite here on behalf of many curious people out there. Can Prisma be more transparent about ETA / no. of people working on various projects? We can see the Prisma main package is having a lot of activity and we understand where the funds went. At the same time, if some projects are not going to be maintained in near future, please inform the developers that use your packages, so that we can be prepared to migrate our code to other tools rather waiting without an ETA.
Once again, thank you for all the work. Nexus / Prisma is a good combination and I will definitely try out the new plugin once it's ready
Yes, definitely. I have been visiting to this thread and Nexus Prisma Github since October 2021 :)). Really waiting updates ❤️
I would recommend, from my point of view, to stick just with nexus without nexus-plugin-prisma. I found out that even in old projects with old nexus it still works and could be easily updated if there are no dependencies to prisma ecosystem. Implement it yourself even it cost you some more time. From my perspective, it is worth it because you are not tied to updates of this plugin and you don't even need to worry about its future anymore.
👆 I would like to quote myself from 29 Apr 2021. As I wrote before, use plain Prisma Client without any plugin in Nexus.
Hello, I believe the library is already stable. A colleague of mine migrated the project and everything works. It was quite straightforward no complications. Probably you should try as well. Those features which are still in progress are more new features. So you should be pretty ok with existing features.
Hello, I believe the library is already stable. A colleague of mine migrated the project and everything works. It was quite straightforward no complications. Probably you should try as well. Those features which are still in progress are more new features. So you should be pretty ok with existing features.
Just to be clear, this does not include the crud operations. The types and resolvers need to be migrated manually at this point in time, a migration guide is here. You should be able to quickly generate the nexus types using your current graphql schema and this tool
Hello, I believe the library is already stable. A colleague of mine migrated the project and everything works. It was quite straightforward no complications. Probably you should try as well. Those features which are still in progress are more new features. So you should be pretty ok with existing features.
This is not Nexus Prisma which autogenerates a lot of the code for you. The reason I used this was so that I could auto-gerate most of the code and save a lot of time.
Long time no new update is posted by @jasonkuhrt or @martzoukos ... and last early release is 3 months ago.
Could you please share some update about the progress?
You're really putting us in a very inconfortable situation, not updating the existing plugin, which however is the only one production ready, and no code update on the new one in almost two months 😔.
We have the choice between:
- not updating Prisma, which releases a main version every two weeks, so waiting for months to upgrade is a huge risk;
- updating Prisma and ignore the not-reassuring-warning of
nexus-plugin-prismaat startupWarning: nexus-plugin-prisma@0.35.0 does not support @prisma/client@3.6.0. The supported range is: 2.23.x. This could lead to undefined behaviors and bugs.🥲; - use the new unstable-not-production-ready
nexus-prismaplugin.
Those are all very bad options when you have code in production 😞.
I am checking right now the Pothos. I would recommend the same. We can share feedback here.
just to chime in since i get notifications about this every few days, prisma is not good at delivering. they way overpromise & way underdeliver so my estimates would be q2-q3 of 2022 if they start working now otherwise q4 2022 😂
personally, i'm using @kenchi/nexus-plugin-prisma which gets updated once in a while but unofficial.
I am going to chip in too just to give another prospective.
Rather than overcriticise we could all try to be more proactive and propose to collaborate and help, maybe it will not be met with radio silence.