Is there a workaround to deal with slow compilation times for a very large openapi file?

[dangdennis]

Question

Is there a workaround to deal with slow compilation times for a very large openapi file when I've directly copied the generated files into my project? I've attempted to use Plaid's very large openapi file but I've found that it leads to long compilation times (30s-60s+ incremental builds) and a slow vscode experience.

https://github.com/plaid/plaid-openapi

I do want to acknowledge a few possible confounding factors that may cause my long compilation times.

1. Quite new to Swift and its server side ecosystem, and thus tooling. Maybe the way the compiler runs the plugin means it skips recompilation of the generated artifacts. Or that I should move my Plaid generated files into a separate SPM product. I've tried both, and both paths still yield a slow experience.
2. I'm using Vapor, and I've actually been unable to import the types generated by the plugin. As in, I'd have my App use the plugin, but can never seem to get the compiler to find my generated types, like Operations. and even APIProtocol. There's also a Client name collision, and I've yet to figure out how to deal with naming collisions in Swift.
3. So on failing to use my types via the plugin, I decided to copy the Client.swift and Types.swift files directly into my App project. At this point, the sheer size of the files basically slows everything even more. But at least my types are now usable!
4. I use watchexec, a file watcher, that runs swift build whenever I save a file. Although I don't think this is a problem as a small Swift project always compiles in a reasonable time (5-15s).

The generator works great on smaller openapi files though!

[czechboy0]

Hi @dangdennis,

for large documents, check out the filter feature, which allows you to only generate the operations you're interested in. That should substantially reduce the size of the generated code and build times.

Regarding using the plugin vs CLI manually, we recommend you use the plugin whenever possible, as that way your OpenAPI document and code are always in sync. If you hit issues that you can resolve by using the CLI manually, please file new issues and we'll investigate them - the plugin should be the preferred adoption method here.

About the type conflicts, note that the generator emits a type called Client, so if you also have a type called Client in the same module, those will conflict. Either rename your type, or generate the types into a separate module, and then import the generated client using its fully qualified name, e.g. MyGeneratedAPI.Client.

[czechboy0]

And watchexec shouldn't be a problem here, as unless the OpenAPI document changes, the generator shouldn't rerun, and your generated files shouldn't have to recompile.

[dangdennis]

Thank you @czechboy0! I didn't know we can filter on other args than just tags. For others, see DocumentFilter. Oh if you're not as blind as I am, it's clearly documented under Create a configuration file.

Now that I'm using just one route, it's significantly faster.

generate:
  - types
  - client
accessModifier: internal
filter:
  paths: 
    - "/link/token/create"