Preface
As I've promised in the previous Typia Series Articles (dev.to), I'll introduce you my new library nestia, which can make Nest...
For further actions, you may consider blocking this person and/or reporting abuse
Been interesting following your articles, I think you're doing a great job but the title is a bit misleading. This is making serialising and validating a hell of a lot faster but that is only one aspect of the "speed" most people will think of, your major resource/time intensive operations tend to be connected to other services like database read/write, file storage, cache access etc. So I'm not sure 20k times faster is really applicable in the real world, for most they will shave a few milliseconds off their APIs, but this is still great when you think about heavily active apis and the amount of time "wasted".
Great stuff, hope I get chance to give typia a go sometime.
Titles are always difficult for me.
A title listing all the core features of Typia and nestia would be too long. In contrary, when I tried to find a great word to summarize them all at once, there was no other word like that.
At first, I tried to appeal to the SDK or pure typescript type DTO, but it was too unfamiliar and unfamiliar to people. Therefore, I explored elements that could introduce my library well, and studied how other open sources introduced themselves.
What I learned from studying other open source cases is that most open sources emphasize speed first when appealing, even if they have various advantages other than speed. Speed is clearly revealed as an objective figure, and these kinds of performance improvements seem to stimulate the developers' desire.
Because of that, I first appeal for speed, and then I talk about the next merits. I also introduce my open source library, and I always think about how to write a title, but I haven't been able to find something clear other than this speed yet. If you have any good ideas, please let me know.
Very interesting library, I'd like to read some more articles describing how the speed-ups are achieved and what are the downsides of your approach as opposed to alternatives (also an explanation why "ts-patch" is required).
I'd also like to see a benchmark package, so your performance claims can be reproduced by myself and others so we can make an informed decision before adopting the library in production.
github.com/samchon/typia/issues/155
Informative article
Learning nextjs now this may be help me in next project.
Thankyou....!!
Holy Molly Shit is so amazing.
what the... is so amazing👍
Is there a full stack mono repo example of this? Would love to see one!
What about async validation ? cannt find referance
Why asynchronous validation is required in DTO level?
Can you give me an exmaple case?
Any use case were it doesnt make sense to seperate the buissness logic validation from the DTO itself for rexample You have DTO A that Point to DTO B and yuwant validate the B exists
Replacing decorators with JSDoc feels like going 10 steps back.
Well, if you think below code seems advanced, nothing to say:
Do you have any plans integrate nestjs with Graphql nest implementation?
As I've not used it yet, have no insight about it.
Can you tell me which points of
gql
inNestJS
are inconvenient, so that how feature do you want innestia
, as an issue?