Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boost up SDK and Swagger Document generation speed #980

Closed
samchon opened this issue Aug 7, 2024 · 3 comments
Closed

Boost up SDK and Swagger Document generation speed #980

samchon opened this issue Aug 7, 2024 · 3 comments
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request good first issue Good for newcomers

Comments

@samchon
Copy link
Owner

samchon commented Aug 7, 2024

Current @nestia/sdk is performing dynamic import to every controller files inidividually with ts-node even though NestJS application module already being mounted in the ts-node process. This step had been essentially required due to reflection information acquisition and matching the reflection information with metadata of each API operations.

By the way, as dynamic import statement in ts-node occurs excessive load on the TypeScript compiler, SDK and Swagger Document generation was slower. For example, my example backend server has 200 number of API endpoints, and its consumption time on SDK or Swagger Document generation overs 30 seconds.

In today, I got an idea to reduce the SDK and Swagger Document generation time shorter. It is to making an internal transformer into the @nestia/sdk, and the internal transformer of @nestia/sdk adjusts a method decorator with metadata information. The metadata information would be ts.Type and description comment data.

With this strategy, @nestia/sdk still needs ts-node, but does not need to inidividual dynamic import step. The metadata of API operation would be enrolled to the metadata, so I expect that SDK and Swagger Document generation time would be about 10x faster.

To accomplish this mission, the transformed raw level (JSON level) metadata must be delivered to the runtime, and the runtime must revive the metadata. However, ts.Type is a type of class with a lot of methods, and its member properties are recursive. If the transformer writes the primitive literal object value (JSON value) of metadata to the JavaScript, its recursive member properties and methods would be broken.

Therefore, I'm testing serializing and derializing such ts.Type class instance in both compilation and runtime level. My experiment is going on typia library. If my experiment concludes to failure, this issue would be closed. Otherwise, succeess to reviving the ts.Type class instance, the generation performance would be dramatically enhanced.

@samchon samchon added documentation Improvements or additions to documentation enhancement New feature or request good first issue Good for newcomers labels Aug 7, 2024
@samchon samchon self-assigned this Aug 7, 2024
samchon added a commit to samchon/typia that referenced this issue Aug 7, 2024
Succeeded to serialized and deserialize `ts.Type` class instnace from the JSON value level.

Also, to accomplish the experiment, refactored `typia` code never to utlize the `ts.Type` methods.
@samchon
Copy link
Owner Author

samchon commented Aug 7, 2024

Suceeded to revive ts.Type, but cannot sure it would work on generator.

In tomorrow, I'll test it.

@samchon samchon pinned this issue Aug 7, 2024
@samchon
Copy link
Owner Author

samchon commented Aug 10, 2024

Failed to de/serialize experiment in typia, but got another idea.

It is to composing a transformer into the @nestia/sdk and getting JSON schema and type name ealirer then generation.

samchon added a commit that referenced this issue Aug 14, 2024
Developing #980: to boost up `@nestia/sdk` performance.
@samchon
Copy link
Owner Author

samchon commented Aug 14, 2024

Completed.

Even though the SDK and Swagger Document generation speeds are not significantly faster than before when building only one module, it would be dramatically boosted up when building multiple swagger & SDK library files/modules.

@samchon samchon closed this as completed Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request good first issue Good for newcomers
Projects
No open projects
Status: Done
Development

No branches or pull requests

1 participant