Esta miniguía va a consistir en como desarrollar en este proyecto. Contiene una lista de buenas prácticas para situaciones comunes.
La arquitectura de nuestro back-end es muy similar a una aplicación MVC genérica.
Se encarga de las siguientes tareas:
- Validación de datos
- Pase de parámetros del servicio
NO debe contener lógica de nuestra aplicación. El controlador bajo el framework express sería las rutas
Se encarga de manipular los datos y/o comunicarse con bases de datos o terceros. Puede realizar validaciones que requieren comunicación con los anteriores.
Pueden desarrollarse en funciones/clases.
Contienen la abstracción a la manipulación de datos (persistentes o no). La idea es que si queremos realizar una query para crear un objeto, exportemos un método y se llame en los servicios, no colocar la query directamente en el mismo.
Los cambios a la base de datos se deben hacer mediante migraciones, las cuales se crean con el comando:
npx knex migrate:make <nombre_de_migracion>
Para correr todas las migraciones se debe ejecutar el comando:
npx knex migrate:latest
Para más información, visita la documentación de knex.
Las herramientas a usar serán:
- Express: Framework minimalista que permite crear rest APIs de manera sencilla e intuitiva.
- Jest: Framework de pruebas unitarias para javascript.
- Typescript: Superset de Javascript que otorga tipado al lenguaje, ideal para proyectos grandes.
- Eslint: Linter de javascript, para asegurar buenas prácticas.
- express-validator: Para validaciones de datos.
La mayoría de las pruebas de la aplicacion van a ser pruebas unitarias. Todo se desarrollará bajo el framework jest. No se debe mockear la base de datos de pruebas bajo ningún concepto.
Las pruebas se deben hacer llamando directamente a los endpoints, pues así logramos cubrir la mayor porción de código posible y de este modo tener un buen coverage final.
Debes sencillamente montar un PR al proyecto añadiendo como reviewers a:
- @german1608
- @aitorres
La idea es que este back-end se reuse en los siguientes compushows. Sin embargo, lo mejor sería tener un branch separado por cada año, así tenemos una gran lista de contribuidores y es más fácil reusar cosas.
TODO