Outline
Hello, I am developer of typia, and studying fastify in nowadays.
During the study, I could understand why fastify is faster t...
For further actions, you may consider blocking this person and/or reporting abuse
Nice work with typia, the job done has been amazing :)
Would you be willing to create a Fastify plugin for typia?
The results can be amazing! Happy to help you with it.
I’m part of Fastify team btw, in case you would like to share some thoughts or doubts about Fastify :)
Got it, I'll try at next Sunday (not tomorrow).
Anyway, where the plugin would be placed in? Just in my github account? Or as a fastify repo?
Sure thing!
Yeah, made everything within a repo of your authorship and once done, we can incorporate it at the list of community plugins :)
Feel free to ping me out if you want a second pair eyes!
What is your github accout name?
I will write an issue on
fastify
repo tagging you, and need to debate about below:At first,
fastify
provides plugin interfaces only through the JSON schema defition. Astypia
can generate JSON schema, it is possible to utilizing current plugin interface offastify
like above.However,
typia
is a transformer library generating optimal code in the compilation time, utilizing pure TypeScript type. To maximize strength oftypia
and make users to be much convenient, I think below code would be should be possible.The
typiaProvider.post<T>()
function will generate both type assertion (+ JSON serialization whenresponse
) and JSON schema definition for Swagger at the same time. Of course, above code requires modifications from plugin APIs offastify
. Therefore, I need to debate about it detaily as an issue.p.s) I'm developing protobuf features, therefore when
fastify
acceptstypia
as a plugin, you can easily support protobuf typed routers very easily.Hey! Please reach out in GH as
metcoder95
!Wow, that sounds interesting. What modifications are you looking for exactly?
In theory, the
fastify.register
should provide you access to the encapsulated context where the plugin is being added, and therefore decorate any possible route being register throughfastify.<post | get | ...>
.But please, open an issue at
fastify
repo and we can help you sorting things out :)Sorry for late.
I've been making guide documents of
typia
andnestia
in nowaydays, and such documentation works had consumed much more time than what I'd expected. Therefore, could not develop the plugin in this weekend.Anyway, stuyding
fastify
, I understood that there're enormous things to develop to adjust transform librarytypia
infastify
. There are already a lot of elements to be developed, so I'm going to make a fastifyplugin
like nestia, which can build SDK library.Please wait for one to two months, then I'll take interesting plugin.
Please, do not rush it. Happy to wait for the results, please let me know if you need any support or similar. Happy to support you with anything!
Currently, succeeded to support
fastify
throughnestia
inNestJS
.nestia.io/docs/
github.com/samchon/nestia/tree/mas...
Now, only "Swagger to NestJS" converter project is left for me. It may requires 2~3 weeks, and I'll start the pure fastify plugin project after that. Also, I'll run benchmark
fastify + typia
, too. Thanks for waiting.Hey! That's amazing! Don't worry about the plugin, take your time :)
So at this point I'm wondering if the benefits of nestia for Fastify can't be embedded upstream (as in making it fast by default when just using fastify)?
It would be nice if
JSON.stringify
function will be optimized on runtime level. And apparently this is doable.Wow, you're planning to send a PR?
It is huge effort. I can explain the idea some day :). It seems V8 devteam is not super interested in this now since they are busy enough with other stuff.
Is it really possible to enhance native
JSON.stringify()
function?Sure, let me give you a "strange" clue. You can take a look on history of how JSON serialization was improved in .NET world. Similar way native JS objects can have some internal methods for reading and writing from reader/writer objects (that hides content streaming under the hood). After that
JSON.stringify
andJSON.parse
are just tiny wrapper under internal JSON serialization pipeline. But again this work should be done in JS engine (v8 or deno). Hope this helps 😄Great article!
As I've promised, wrote an article introducing how to use
typia
inNestJS
.dev.to/samchon/nestia-boost-up-you...
잘보고 있습니다.!
엌... 태양토끼님 반갑읍니다
Hi. One thing I don't get in your benchmarks: in your Fastify code you are running with a schema validator, but in your Express code you are only replacing the default JSON parsing. How is that even comparable?
Benchmark program of current article does not have request body data. It has only response body data. Therefore, if your "schema validator" means a response data validation before JSON serialization, I wanna say that
typia.isStringify()
andtypia.assertStringify()
are doing it.Otherwise, you're meaning request DTO validation, and what you want to say is "this benchmark program does not handle request DTO validation", I want to introduce below article. Although below article's benchmark program is not measuring the pure request DTO validation logic of
fastify
, I think it may helpful for you.By the way, reading your comment, I think that I should enhance above linked article's benchmark program. I'll add
pure-fastify
component in the benchmark pogram, so that resolve your question clearly. By the enhancement, five componets would be compared:github.com/samchon/nestia/tree/mas...
Benchmark result
And how is the development of the plugin for fastify going?
Plan to start at 2023-09. Sorry for delaying
github.com/samchon/schedules/blob/...
Thanks, and do you intend to support SWC?
Not possible to support SWC, because it removes every types like Babel
Amazing work! I have one question: why did you create external dependencies instead of creating a pull request to the different projects mentioned (NestJS and Express)?
About NestJS
NestJS has used
class-validator
,class-transformer
and@nestjs/swagger
for many years.Unless those libraries have lots problems especially in productivity and performance, too much time have passed and strong dependencies had been occured.
Therefore, I think
nestia
can't be standard feature of NestJS, because of ordinary (legacy) projects.About Express
express
does not restrict any special validation and serialization logic.Therefore, whatever user choose, it is up to the user.
Sorry if I wasn't clear. What I meant was that even if NestJS is buried in old code, why not make a big pull request including the Nestia parts? It's a lot of work, but would improvde the DX of a lot of developers
Had tried very long time ago ToT.
I got answered that it would better to make a 3rd party library, and it is the
nestia
.github.com/samchon/nestia
I think you can 1.000.000x faster with you using protobuf
You must be a genius who can see the future.
Next version of typia will support protobuf features like below.
For example, I'll introduce a directory storing protobuf schema files generated by the next version of
typia.message<T>()
function:p.s) Protobuf is not such faster as you think. I'll come back with new benchmark after the next version.
I suggest you can use option on proto file for gen code. "option optimize_for = CODE_SIZE;"
Yes, current
typia.message<T>()
function writes too much long name. I need to make it shorter.How do these compare on deno instead of node?
Because I do not use deno, I do not know how it would be.
Also, deno does not support standard TypeScript compiler, it is hard (possible but not easy to configure) to test in the deno environment.
Deno dont support Typescript?
Dono does not support TypeScript compiler API
Hmm, so if you create a typia plugin for fastify so there's no way that express can beat fastify at all right?