-
-
Notifications
You must be signed in to change notification settings - Fork 102
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
Comments
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.
Suceeded to revive In tomorrow, I'll test it. |
Failed to de/serialize experiment in It is to composing a transformer into the |
Developing #980: to boost up `@nestia/sdk` performance.
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. |
Current
@nestia/sdk
is performingdynamic import
to every controller files inidividually withts-node
even though NestJS application module already being mounted in thets-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 ints-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 bets.Type
and description comment data.With this strategy,
@nestia/sdk
still needsts-node
, but does not need to inidividualdynamic 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 ontypia
library. If my experiment concludes to failure, this issue would be closed. Otherwise, succeess to reviving thets.Type
class instance, the generation performance would be dramatically enhanced.The text was updated successfully, but these errors were encountered: