The future of Nexus Prisma Plugin

[martzoukos]

👉 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-prisma from 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! 💚

[narciero]

@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!

[martzoukos]

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.

[lvauvillier]

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.

[martzoukos]

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.

[lewebsimple]

Excellent news for the long-term stability of Nexus / Prisma integration ! Middleware support is exciting stuff, are there public RFC somewhere ?

[PerfectedApp]

Please support multiple Prisma clients! :-/ #992

[bw]

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!

[nikolasburk]

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.

[homoky]

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.

[homoky]

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.

[mikkelsl]

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.

[lvauvillier]

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.

[homoky]

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.

[nikolasburk]

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.model without 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/or t.crud a 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 on t.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 our prisma-examples repo.)

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! 🙏

[BjoernRave]

I'm confident, that the community will manage to bridge the migration time with keeping the prisma version up to date :)

[jasonkuhrt]

@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.

[TLadd]

@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.

[cesarve77]

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

[BiscuiTech]

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.

[MikaStark]

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 :)

[jasonkuhrt]

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.

[cmidgley]

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)?

[jasonkuhrt]

@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.

[Newbie012]

Would be nice if the plugin will support aggregations as well - https://www.opencrud.org/#sec-Queries-Aggregations

[Akxe]

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.

[orefalo]

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.

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.

[jasonkuhrt]

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

[MikaStark]

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

[omerman]

@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.

[MikaStark]

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],
});

[dvins]

@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?

[jasonkuhrt]

@dvins

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.

[ahmedosama5200]

@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.

[lewebsimple]

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.

[orjellingsen]

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.

[PerfectedApp]

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.

[homoky]

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.

[dominichadfield-jelly]

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.

[martzoukos]

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 :) .

[homoky]

I am looking forward to it. Thanks, @martzoukos for the feedback.

[orjellingsen]

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 :)

[jasonkuhrt]

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.

[durdenx]

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.

[jasonkuhrt]

@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.

[jasonlimantoro]

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.

[bruno02100]

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.

[jasonkuhrt]

@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. 🥅 🏒

[devdanio]

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.

[MikaStark]

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.

[jasonlimantoro]

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.