[DRAFT] Drafts about the architecture of the project #34
Comments
Manueluz
changed the title
Propuesta [DRAFT 2]TecnologíasAmbasLenguaje de programaciónEl lenguaje de programación elegido es JS (JavaScript), se llego a esta conclusión tras considerar Java y llegar al acuerdo de que JS era mas simple de desarrollar ademas de que es interesante aprender JS ya que es muy usado en la industria. Los principales contras de esta elección es que nuestra experiencia en JS es significativamente menor y que se trata de un lenguaje interpretado y dinámico por lo que no podemos tener la seguridad de la comprobación de tipos a la hora de compilar por lo que es mas difícil detectar errores. FrontendFramework JS y HTMLHemos decidido usar React ya que una vez mas es muy usado en la industria y lo consideramos mas simple que JS Vanilla, el principal problema de usar react es que se trata de una librería compleja con la que no tenemos experiencia por lo que va a costar realizar ciertos avances en el frontend Framework CSSPara el CSS hemos decidido usar el Framework de TailwindCSS ya que consideramos que hacer CSS a mano es demasiado difícil para nuestra experiencia ademas de ser una forma muy rápida de crear paginas web "bonitas". El principal contra de usar TailWindCSS es que otorga poca personalización y puede hacer que los diseños se sientan "soul.-less". BackendFrameworkPara el backend hemos decidido usar ExpressJS ya que su uso es sencillo y consideramos que es una forma rápida de crear un servidor REST usando NodeJS. El contra vuelve a ser el usar el lenguaje JS. Base de datosPor el momento aunque no se trata de una decisión definitiva hemos decidido probar MongoDB ya que su modelo de datos orientado a documentos y agregados nos resulta interesante a la hora de guardar los usuarios con sus partidas El contra principal es que la falta de experiencia y que usar MongoDB puede considerarse "matar moscas a cañonazos" Despliegue y CIPara el despliegue usaremos Docker y el servicio de GithubActions, elegidos ya que docker es muy sencillo de usar y la tecnología de contenedores mas usada actualmente, la alternativa que descartamos seria desplegar el servidor manualmente lo cual resulta muy tedioso. Aun así docker introduce una complejidad adicional ya que se trata de una tecnología nueva para nosotros. Se decidió usar GithubActions ya que es la unica herramienta no de pago que encontramos para realizar CI ServiciosDivisiónHemos decidido dividir los servicios (En este caso divididos en contenedores Docker) en 3 partes principales:
La idea principal es que todos las peticiones pasan por el gateway de Login el cual verifica de que se trate de un usuario valido, en caso de que no se trate de un usuario valido el gateway solo permitirá acceder a las paginas y apis relacionadas con hacer login o crear una nueva cuenta. Diagrama explicativo del proceso: Verificación de usuariosPara la verificación de usuarios hemos decido un sistema basado en cookies, en el que cuando un usuario hace login se le devuelve una cookie con la id de usuario. El principal pro de esto es se trata de un método muy sencillo de implementar y usar (ya que la cookie ya es directamente la id del usuario). El principal contra de esto es que es mucho menos seguro que métodos como jsonwebtoken (El cual también fue considerado pero descartado por complejidad extra) |
Manueluz
added
the
Architecture
Manueluz
changed the title
Draft [DRAFT 3]TechnologiesBothProgramming languagesWe've decided to use JS in both the frontend and backend, becase we came to the conclusion that is simpler than java and that it is widely used in industry, so it is an interesting language to learn. The main problems that can arise from using this language is that our knowelge of it is quite limited and that we dont have the safety of type checking on compile time as the lenguage is dynamic so its harder to guarantee that the code will work properly (We need to pay more attention to tests as a result!). FrontendFramework (JS + HTML)For the frontend framework weve decided to use react thanks to the amount of avaiable resources on the technology, we consider it easier than vanilla JS and we hope it leads to a faster workflow, the main cons of using react is that currently none of us know it. Framework (CSS)For the CSS framework we've decided to use TailWindCSS because it leads to a faster developing experience than vanilla CSS, the main con of using TailWindCSS is that the resulting look and feel can look bland and "soul-less" as it is the same for every web page created using TailWind. BackendFrameworkFor the backend framework we've decided to use ExpressJS for the simplicity of it, and because we consider a way to develop the app faster. DatabaseFor the database we've decided to use MariaDB because in the team we are all familiar with SQL and MySQL syntaxt, and for a faster development experience we've decided to use an ORM (Specifically Sequelize),please see issue #3 for more information ServicesWeve decied to divide the app into two services (Each one contained in 1 docker container):
For verification and login services, you can log into the API which will return a jwt token with the user id, you can use the token to verify in the following requests to the api. |
|
I also propose a MicroServices architecture for the app, because it allows us to containerize and test each part of the application independently, we can sync them with a common database We should write down the microservices we plan on creating |
|
Id say its done |
Propuesta [DRAFT 1]
Tener 3 servicios principales: login, generador de preguntas y pagina web
La arquitectura de la aplicación seguiría el siguiente patrón:
Peticion externa-----> Servicio de login actuando como gateway ------> El resto de la aplicacion
Por lo que el unico puerto expuesto al exterior seria el puerto del servicio de login, el cual simplemente actua como una puerta que verifica que los usuarios sean validos, y en caso de que no lo sean les redirige a una pagina de login.
The text was updated successfully, but these errors were encountered: