Swoosh Query Filters

2. Parse query input in the DTO.

• Use explicit DTO names like FindAllProductsDto.
• Use class-transformer and class-validator.
• Convert repeated params or comma-separated params in the DTO layer.
• Keep DTO properties typed to the normalized result, not the raw query string shape.
• Keep validation messages in module constants.

3. Document query fields in module Swagger docs.

• Add query property docs in <module>.swagger.ts.
• Reuse named ...PropertyDocs wrappers instead of raw ApiProperty blocks.
• Keep examples realistic and aligned with the DTO contract.

4. Normalize shared query formats in shared utils.

• Use helpers like toStringArrayQueryParam and toNumberArrayQueryParam for array-like query values.
• Promote transforms to src/shared/utils only when multiple modules benefit.

5. Build database query options in a feature utility.

• Create a function like buildProductListQueryOptions(dto).
• Return a small object such as { filters, sort, limit }.
• Keep default sort and default limit in module constants.
• Keep string matching rules explicit, such as exact case-insensitive regex helpers when needed.
• Keep range handling deterministic, for example by sorting min and max before building $gte and $lte.

6. Keep services thin.

• Services should call the query-options builder, then apply .find(filters).sort(sort).limit(limit).
• Populate and select logic can stay in the service, but raw query normalization should not.

7. Verify before finishing.

• Build the backend.
• Check that invalid query input fails in DTO validation.
• Check that Swagger examples still match the DTO shape.

Avoid

• Parsing raw req.query inside services
• Duplicating comma splitting and trimming logic in every module
• Hiding business-specific filtering rules inside shared utilities
• Mixing validation, normalization, and DB querying in one large method
• Letting Swagger docs drift away from DTO behavior