Loading repository data…
Loading repository data…
PeterDamianG / repository
Este repositorio, es una posible solución al desafío de javascript propuesto por la aceleradora Alkemy.
A transparent discovery signal based on current public GitHub metadata.
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
En el marco de el desafío "Challenge JS" sobre Javascript propuesto por Alkemy. Este es un contenedor/workspace para la APP, la API y pruebas e2e.
Alkemy - - - Alkemy Challenges
El desafío elegido es el de "Challenge JS", que puede observarse en la web de challenges o también en el siguiente archivo PDF:
git clone https://github.com/PeterDamianG/challengejs-alkemy.git
cd challengejs-alkemy
npm run install-all
Anotación: Usando el sistema de workspace, todas las dependencias serán instalas juntas. Y además se pasará una bandera --legacy-peer-deps, para evitar problemas conocidos con NPM versión 7, es necesario tener la misma o superior. También el comando iniciara automaticamente, nuestro ORM Prisma.
4.1 - Manualmente ir a la carpeta de "frontend" y la de "backend". En ambas observaras un archivo .env.example. Tienes que borrar la extensión .example y que el archivo quede como .env con ese bastaría.
4.2 - Automaticamente con el siguiente comando, podría no funcionar en todos los sistemas operativos. (No funcionara en una Mac - Apple):
npm run fix-env
Nota: Es recomendable entender para que sirven los archivos de entorno .env
npm run build-app
npm run start-dev
La aplicación comenzara a funcionar en LocalHost.
Se encarga de inicializar el ORM Prisma Es para uso interno, no debería ser necesario su llamado individual.
Se encarga de instalar todas las dependencias de la APP (FronEnd), API (BackEnd) y Cypress de este contenedor. Es el comando que engloba todas las llamadas de instalación con el flag --legacy-peer-deps e inicialización del ORM Prisma, es el que se debería usar normalmente.
Se encarga de reemplazar el nombre del archivo de entorno en la API. Es para uso interno, no debería ser necesario su llamado individual.
Se encarga de reemplazar el nombre del archivo de entorno en la APP. Es para uso interno, no debería ser necesario su llamado individual.
Se encarga de llamar los comandos que reemplazan los archivos de entorno. Es el comando que se debería usar normalmente.
Se encarga de construir la aplicación en React, sí vas a iniciar la aplicación desde el paquete workspace de este proyecto. Deberías usar este comando para construirla, pero no difiere de usar el comando original que se encuentra en el desarrollo del FrontEnd.
Se levantara la API, que servira los estáticos generados con React. Usará el modo de producción de Node, Prisma y la base de datos SQLite también será la de producción. Estando en este modo, todo estara optimizado, pero el mal manejo de la base de datos puede generar grandes daños.
Se levantara la API, que servira los estáticos generados con React. Usará el modo de desarrollo de Node, Prisma y la base de datos SQLite también será la de desarrollo. Básicamente usalo para el desarrollo.
Se levantara la API, que servira los estáticos generados con React. Usará el modo de pruebas de Node, Prisma y la base de datos SQLite también será la de pruebas. El uso recomendado es con Cypress. También se utiliza para las pruebas en el BackEnd (Las usará el por sí mismo, no necesitaras levatar este comando).
Levantara el test-runner de Cypress en modo con cabecera. Es necesario que algunos de los "start", estén actualmente corriendo. En caso de no ser la base de datos de pruebas, puede haber errores.
Aclaración: Los comandos mencionados previamente, sólo se constituyen a este parte del proyecto. El BackEnd y FrontEnd, respectivamente tienen sus propios comandos para funciones internas y externas. Como linters, pruebas, generar documentación y levantarse.
Este proyecto está constituido por dos partes principales y su contenedor.
El FrontEnd, construido con React. Que puede funcionar independientemente haciendo llamadas a una API. Puedes observar todo su desarrollo independiente en el folder "frontend".
El BackEnd, construido en Express. Que puede funcionar independiente proveyendo una API para que clientes usen, con un estilo similar a una API REST. Puedes observar todo su desarrollo independiente en el folder "backend".
Y por último este paquete contenedor, que se encargara de funcionar como un WorkSpace. Aprovechando su condición de empaquetador/contenedor/workspace, también se utiliza para realizar las pruebas end to end.
Los Workspaces, son una tecnología relativamente nueva a la fecha. Se ha optado por usar está, para este proyecto y no los "submodules". En consecuencia, pueden ocurrir problemas de dependencias cruzadas y rutas relacionadas.
En algunos casos, quedan resueltos con la instalación pasandole el flag --legacy-peer-deps en otros el --force, aunque acarrean problemas internos de compleja resolución. Más que nada porque corresponden a la versión 7 de NPM y escapa a nuestras capacidades.
No se pretende, realizar un proyecto listo para producción en optima condición, donde haya un coverage de testing de alto porcentaje. Un uso extensivo y profundo de carácteristicas de React como useMemo, useCallback y React.Memo, más que lo mínimo necesario. Y tampoco el uso de la API Profiler.
El objectivo es generar un MVP, un Producto Mínimo Viable que sirva como demostración.