[Feature Request] Performance Best Practices Guide for Large Schemas

[drakedeatonuk]

I work with a large 100+ table schema. Due to the number of generated files this wonderful package creates, there's been a number of non-trivial performance challenges.

Given this, I think it would be beneficial if somewhere in this package or its Github there was a little compendium of best practices for getting the best possible performance out of this package. I appreciate TypeScript performance is a bit outside the scope of this library, but these challenges took me personally quite a while to navigate, and I almost stopped using this package because of these challenges, so having this type of info to hand may help others navigate those challenges and thus improve adoption of this package.

I'm no TS wizard but here's a couple of examples of things I did to improve performance:

• Generating the validators into a .gitignore directory. Introducing hundreds of tracked files at once when running the generator gave me noticeable performance dips every time I ran it. The generator became much easier to re-run with this change.
• Adding the generated folder to the 'excludes' section of my tsconfig. when compiling the app I found this improved how quickly it compiled, at the tradeoff of intellisense imports.
• Enable useMultipleFiles & disable writeBarrelFiles.

Some challenges I'm still having that I'd love to hear others approaches to:

• Methods for improving compilation time. With many validators imported from the generator files, the time it takes our backend to compile has still more than doubled.
• Improving my webpack.config.js. There's configuration changes I'm investigating, such as using fork-ts-checker-webpack-plugin.
• Other tsconfig improvements. Specific compiler options that may help improve perf.

---

Massive thank you @chrishoermann for making such a useful package. Truly it is awesome 👏

[CyanoFresh]

yes, generated file is huge. maybe some generator options are needed for granular tweaking of which schemas to generate. we probably will end up writing (or forking) our own generator

[KuryKat]

I'll be honest, the only reason I still plan on sticking with zod-prisma (even tho it hasn't been updated in 2 years) is because of how simple the schema generation is, it generates one file for each model, period.

This package here, is without a doubt amazing, but the MASSIVE amount of tiny files it generates creates these performance issues on bigger database schemas (such as your case @drakedeatonuk)

I would love if this package's useMultipleFiles would generate LESS FILES, for example: one file for each model, with all it's related models and validators inside of it, that would reduce the amount of files from 1000+ to just 100ish in Drake's case.

---

As for tips, tweak the settings to generate just what you'll use... the less amount of files I could generate with my schema (22 models, 17 enums) was 68 files, while using these settings:

generator zod {
  provider                         = "zod-prisma-types"
  output                           = "./generated/zod" // default is ./generated/zod
  useMultipleFiles                 = true // default is false
  writeBarrelFiles                 = true // default is true
  createInputTypes                 = false // default is true
  createModelTypes                 = true // default is true
  addInputTypeValidation           = false // default is true
  addIncludeType                   = false // default is true
  addSelectType                    = false // default is true
  validateWhereUniqueInput         = false // default is true
  createOptionalDefaultValuesTypes = false // default is false
  createRelationValuesTypes        = false // default is false
  createPartialTypes               = false // default is false
  useDefaultValidators             = true // default is true
  coerceDate                       = true // default is true
  writeNullishInModelTypes         = false // default is false
  useTypeAssertions                = false // default is false
}

Check your use-case, and think about what you're actually using, for example: Do you even use the schemas for validating your where, select and include prisma queries? if not, you can safely disable addIncludeType, addSelectType and validateWhereUniqueInput, and so on!