Custom QueryString parser support

[radixxko]

Bug Report

Hey Samchon,

we are having issue processing extended querystring using @TypedQuery decorator since you are using URLSearchParams for parsing querystring

Summary

When sending complex querystring like foo[0][type]=a&foo[0][value]=foo&foo[1][type]=b&foo[1][value]=bar nestia is unable to parse it using @TypedQuery decorator

Write detailed description in here.

In src/decorators/TypedQuery.ts you are parsing request.query using URLSearchParams however it does not support extended query strings.

I suggest changing a functionality to using already parsed QueryString from request.query if already parsed by middleware querystring parser and then change the validation logic accordingly to accept object instead of URLSearchParams instance

const params: object = request.query && typeof request.query === 'object' ? request.query : new URLSearchParams(tail(request.url)).searchParams;

[gitaugakwa]

I'm also having the same issue.

Would be nice getting this addressed.

[samchon]

Your suggestion is a typical anti pattern that violating standard.

If you write a query string "person.address.id=2", it means obj["person.address.id"] = 2 in the query string spec.

Also, URL path has length limit in most browsers (about 1,023), and nested query is much dangerous than non-nested.

[samchon]

Instead, I recommend to use request body of POST/PATCH/PUT/DELETE methods.

The request body does not have any length and depth limit.

In my case, I prefer PATCH method when replacing GET method endpoint for the same reason with you.

https://github.com/samchon/bbs-backend/blob/5d398c6fc3aa26deec975b1870f457a71c0beed6/src/controllers/bbs/BbsArticlesController.ts#L13-L29

https://github.com/samchon/bbs-backend/blob/5d398c6fc3aa26deec975b1870f457a71c0beed6/src/api/structures/bbs/IBbsArticle.ts#L78-L118

[radixxko]

The main issue is that if somebody is already using its own querystring parser that works in nestjs, it stops working once nestia is installed since you are not using already parsed query value that Express/Fastify framework already handled.

We have spend few hours debugging why we are receiving completely different values with TypedQuery which should happen

[samchon]

In that case, it would better to use @Query() of original NestJS.

Also, in that case, how serialize the query string in the frontend application?

I need to update the SDK generator only for @Query() decorator case.