api/src/afip/Afip.ts
no se recomeiuenda el uso de var, mejor let y const
tambien usar let y const cuando corresponde
tampoco se recomiendo el uso de snake_case en js lo normal es camelCase
debe
Creo que deberiamos intentar agregar afip sdk como dependencia no pegando el codigo fuente
https://www.npmjs.com/package/@afipsdk/afip.js?activeTab=code
api/src/comprobantes/factura/factura.html
deberiamos eliminar codigo comentado
muy interesante el uso de pupeteer para generar la factura
tambien se podria hacer en el front directamente y mandarela a imprimir como pdf
hay mucha manipulacion directa que se podria resolver mas facil con react en el front.
no se si necesitas enviar la factura a algun lado desde el back-.
Sino se podria usar SSR de react para generar la factura y evitar todo el codgo de reemplazo de strings que enemos en comprobante.ts
api/src/controllers/cliente.controller.ts
No veoposibilidad de que no encuuentre el cliente a actualizar
si esta el duplicated pero creo que hay una confusion ahi
deberia devolver 404 sino lo encuentra
api/src/models/base.model.ts
Me sorprende que hayas armado un ORM, me parece interesante la idea para un ejercicio pero no recomendable para un proyecto real.
No veo en el orm que hagas validacion o escaping de strings lo cual puede ser un probnlema de seguridad importante.
Tal vez lo tiene pero es un tema a tener en cuenta
El logging deberia ser iopcionar, en un ambiente productivo usar console.log puede traer muchpos problemas de performance
api/src/models/cliente.model.ts
Eliminemos codigo comentado de todos lados (todos los archivos) solo confunde, el git ya guarda un historico de todo lo que hacemos
En js recomiendo usar camelCase todas las api normales son asi no es comun usar snake_case
api/src/models/consignacion.model.ts
No es conveniente manipular fechas con strings, puede traer muchos errores inadvertidos menos si manipulamos el timezone
mejor usar una lib bien probada como date-fns
api/src/schemas/validate.ts
Mismo que con el ORM, para valiudar podes usar zod yup o algun otro framework comprobado, de todas formas me parece interesante que te hayas puesto a ahacerlo por tu lado
No lo recomiendo para nada en un proyecto productivo, te agregas codigo a mantener y podes tener mas errores
api/package.json
hay dependencias que podrian ser devDependencies (todos los types)
api/src/afip/Afip.ts no se recomeiuenda el uso de var, mejor let y const tambien usar let y const cuando corresponde tampoco se recomiendo el uso de snake_case en js lo normal es camelCase debe Creo que deberiamos intentar agregar afip sdk como dependencia no pegando el codigo fuente https://www.npmjs.com/package/@afipsdk/afip.js?activeTab=code
api/src/comprobantes/factura/factura.html deberiamos eliminar codigo comentado muy interesante el uso de pupeteer para generar la factura tambien se podria hacer en el front directamente y mandarela a imprimir como pdf hay mucha manipulacion directa que se podria resolver mas facil con react en el front.
no se si necesitas enviar la factura a algun lado desde el back-.
Sino se podria usar SSR de react para generar la factura y evitar todo el codgo de reemplazo de strings que enemos en comprobante.ts
api/src/controllers/cliente.controller.ts No veoposibilidad de que no encuuentre el cliente a actualizar si esta el duplicated pero creo que hay una confusion ahi deberia devolver 404 sino lo encuentra
api/src/models/base.model.ts Me sorprende que hayas armado un ORM, me parece interesante la idea para un ejercicio pero no recomendable para un proyecto real. No veo en el orm que hagas validacion o escaping de strings lo cual puede ser un probnlema de seguridad importante. Tal vez lo tiene pero es un tema a tener en cuenta El logging deberia ser iopcionar, en un ambiente productivo usar console.log puede traer muchpos problemas de performance
api/src/models/cliente.model.ts Eliminemos codigo comentado de todos lados (todos los archivos) solo confunde, el git ya guarda un historico de todo lo que hacemos En js recomiendo usar camelCase todas las api normales son asi no es comun usar snake_case
api/src/models/consignacion.model.ts No es conveniente manipular fechas con strings, puede traer muchos errores inadvertidos menos si manipulamos el timezone mejor usar una lib bien probada como date-fns
api/src/schemas/validate.ts Mismo que con el ORM, para valiudar podes usar zod yup o algun otro framework comprobado, de todas formas me parece interesante que te hayas puesto a ahacerlo por tu lado No lo recomiendo para nada en un proyecto productivo, te agregas codigo a mantener y podes tener mas errores
api/package.json hay dependencias que podrian ser devDependencies (todos los types)