Objetivo 8 #37
Objetivo 8 #37
Conversation
El orden en el que se toman las configuraciones es: 1. Servidor 2. Enviroment 3. Valores predeterminados De esta forma la aplicación siempre tiene una configuración preparada para utilizar. Puesto que no se puede devolver una promesa de un objeto dada su propiedad inherente de *disponibilidad(Readiness)*, la solución que se ha tomado es crear una atributo que corresponde a una promesa y ejecutar los metodos necesarios cuando la promesa se verifique. La solución detallada se puede encontrar en: https://stackoverflow.com/questions/35743426/async-constructor-functions-in-typescript
Primer intento de implentacion de un controlador asincrono. No funciona correctamente porque, por un motivo desconocido, no se está esperando a que la instancia config del controlador se termine de instanciar antes de utilizarla en el index o en los test aunque el test específico de la clase configuración funciona cocorrectamente.
|
Revisión @JJ. |
|
No le he hecho el pr al repositorio porque no tengo el Objetivo-7 superado y fallarían los test. Igualmente cuando corrijas, por favor, échale un ojo porque es independiente del Objetivo-7 y necesito saber cómo va para seguir avanzando. |
Puedes hacerlo inicialmente como un PR a la rama del objetivo 7, y cuando lo fusiones simplemente cambias la rama a la que vas a hacer PR. |
|
⛹ Revisores → @modejota @Slowmybrosh |
|
Revisión @JJ. |
docs/tools.md
Outdated
| Se han considerado los siguientes frameworks: [nest](https://www.npmjs.com/package/@nestjs/core), [fastify](https://www.npmjs.com/package/fastify), [hapi](https://www.npmjs.com/package/@hapi/hapi), [restify](https://www.npmjs.com/package/restify). | ||
|
|
||
| - Nest es la alternativa más popular. Nest es un proyecto apoyado por grandes multinacionales como Redhat y empresas como NX y Labster que tiene como objetivo resolver los problemas arquitectónicos frecuentes en las aplicaciones escritas en javascript/typescript: "... However, while plenty of superb libraries, helpers, and tools exist for Node (and server-side JavaScript), none of them effectively solve the main problem of - Architecture". Esto implica que las herramientas necesarias para construir el API están pensadas para usarse con el resto de las herramientas del proyecto pero sobre todo que hay que seguir la estructura de aplicación propuesta. Por lo tanto no verifica la tercera condición y ha sido descartado. | ||
| - Fastify es la segunda alternativa más popular y la más novedosa. Esta librería esta centrada en la eficiencia siendo esta uno de sus principales atractivos; es la alternativa más eficiente de las consideradas según sus propios benchmark que se pueden encontrar en https://github.com/fastify/benchmarks. Su estado de mantenimiento es muy bueno y se integra bien con el logger elegido pero se integra muy mal con la librería de test luego no termina de verificar tercera condición. Ha sido descartada por este motivo y porque su novedad implica una falta de pluggins disponibles y de posible documentación de cara a la implementación de características sofisticadas. |
There was a problem hiding this comment.
Sorry por no haber comentado nada, cosas de tomarse el día 1 de fiesta. Como ya lo has puesto para revisión, solo te diré como comentario que fastify tiene la funcion "inject" para hacer peticiones HTTP "fake" en los test, con JEST funciona bastante bien, ya no sé con Mocha, pero supongo será 3/4 de lo mismo.
There was a problem hiding this comment.
Sorry por no haber comentado nada, cosas de tomarse el día 1 de fiesta. Como ya lo has puesto para revisión, solo te diré como comentario que fastify tiene la funcion "inject" para hacer peticiones HTTP "fake" en los test, con JEST funciona bastante bien, ya no sé con Mocha, pero supongo será 3/4 de lo mismo.
Aunque lo haya puesto para revisión podéis comentar lo que queráis, si me da tiempo a cambiarlo antes de la revisión, lo haré. Tienes razón con el tema de los injects, lo que realmente no me gusta es que la declaración de las rutas y sus llamadas sean distintas(entre otras cosas). Voy a actualizar la documentación.
There was a problem hiding this comment.
Dado que la justificación no es demasiado buena, y que además el interfaz no está demasiado bien diseñado, estaba en el límite de ser aceptado. Sin embargo, lo que lo alejó del límite es que hayas instalado una dependencia que es claramente de producción como dependencia de desarrollo. Lo siento, pero no pasa.
| | GET | /product | Obtención de todos los productos | | ||
| | GET | /product/id | Obtención del producto relacionado con la id | | ||
| | POST | /product | Creación de un nuevo producto | | ||
| | PUT | /product | Actualización de un producto | |
There was a problem hiding this comment.
PUT siempre debe usar un URI, porque es idempotente.
There was a problem hiding this comment.
Lo que quiere decir que no cambia el estado.
There was a problem hiding this comment.
Te estás refiriendo a la documentación que no está actualizada porque se me olvidó. El verdadero diseño de la API está reflejado en el código que siempre está actualizado.
There was a problem hiding this comment.
Me estoy refiriendo a lo que veo, claro. En este objetivo se trataba de hacer sólo la documentación.
| - Nest es la alternativa más popular. Nest es un proyecto apoyado por grandes multinacionales como Redhat y empresas como NX y Labster que tiene como objetivo resolver los problemas arquitectónicos frecuentes en las aplicaciones escritas en javascript/typescript: "... However, while plenty of superb libraries, helpers, and tools exist for Node (and server-side JavaScript), none of them effectively solve the main problem of - Architecture". Esto implica que las herramientas necesarias para construir el API están pensadas para usarse con el resto de las herramientas del proyecto pero sobre todo que hay que seguir la estructura de aplicación propuesta. Por lo tanto no verifica la tercera condición y ha sido descartado. | ||
| - Fastify es la sugunda alternativa más popular y la más novedosa. Esta librería esta centrada en la eficiencia siendo esta uno de sus principales atractivos; es la alternativa más eficiente de las consideradas según sus propios benchmark que se pueden encontrar en https://github.com/fastify/benchmarks. Su estado de mantenimiento es muy bueno y se integra bien con el logger y la librería de test escogidos. Por otra parte no verifica ninguna los requisitos convenientes y su novedad implica una falta de pluggins disponibles y de posible documentación de cara a la implementación de características sofisticadas. Además, la declaración de las rutas y sus llamadas no es uniforme. Por todas estas razones ha sido descartada. | ||
| - Restify es la tercera de las alternativas consideradas. Es utilizada por grandes empresas/organizaciones como npm, netflix, pinterest o napster. La librería fue descartada porque, a pesar de cumplir todos los requisitos de la lista tiene un estado de conservación relativamente malo(76 issues de los cuales los últimos no han sido tan siquiera respondidos) lo cual convierte su elección en un tanto arriesgada. | ||
| - Por último está hapi que, a pesar de ser la librería menos popular, es la elegida. Hapi se desarrollo gestionar Walmart durante el Black Friday y es utilizada por grandes empresas como Brave(web browser) y Beats. Verifica todos los requisitos necesarios y convenientes y, además, tiene un estado de conservación bueno y una documentación muy clara y concisa que facilitan enormemente su uso. |
There was a problem hiding this comment.
Podías poner enlaces o algo y al final qué es lo que has elegido. O resaltar más que has elegido esta. No dices nada de los criterios, y dices cosas que no vienen a cuento como que la usa Brave (¿¿¿???)
There was a problem hiding this comment.
Podías poner enlaces o algo y al final qué es lo que has elegido.
Todos los framework están enlazados a sus correspondientes páginas la primera vez que son mencionados y se indica claramente el framework escogido en el instante en el que se realiza su justificación.
No dices nada de los criterios
En algunos casos se mencionan de forma implícita y en otros de forma explícita y toda la justificación gira en torno a los mismos:
-
Nest: Esto implica que las herramientas necesarias para construir el API están pensadas para usarse con el resto de las herramientas del proyecto pero sobre todo que hay que seguir la estructura de aplicación propuesta. Por lo tanto no verifica la tercera condición y ha sido descartado.
-
Fastify: Su estado de mantenimiento es muy bueno y se integra bien con el logger y la librería de test escogidos. Por otra parte no verifica ninguna los requisitos convenientes...
-
Restify: La librería fue descartada porque, a pesar de cumplir todos los requisitos de la lista tiene un estado de conservación relativamente malo.
-
Hapi: Verifica todos los requisitos necesarios y convenientes y, además, tiene un estado de conservación bueno y una documentación muy clara y concisa...
y dices cosas que no vienen a cuento como que la usa Brave (¿¿¿???)
Sólo me pareció un dato curioso, evidentemente no forma parte de la justificación pero el texto no es sólo justificación, también es documentación.
There was a problem hiding this comment.
El problema es "la forma implícita". Hay que decodificar lo que dice para ver si cumplen los criterios o no. En cuanto a lo de Brave, "Datos curiosos" pueden ser interesantes en algún contexto, para el que tiene que evaluar este PR sólo es ruido.
|
|
||
| Se han considerado los siguientes frameworks: [nest](https://www.npmjs.com/package/@nestjs/core), [fastify](https://www.npmjs.com/package/fastify), [hapi](https://www.npmjs.com/package/@hapi/hapi), [restify](https://www.npmjs.com/package/restify). | ||
|
|
||
| - Nest es la alternativa más popular. Nest es un proyecto apoyado por grandes multinacionales como Redhat y empresas como NX y Labster que tiene como objetivo resolver los problemas arquitectónicos frecuentes en las aplicaciones escritas en javascript/typescript: "... However, while plenty of superb libraries, helpers, and tools exist for Node (and server-side JavaScript), none of them effectively solve the main problem of - Architecture". Esto implica que las herramientas necesarias para construir el API están pensadas para usarse con el resto de las herramientas del proyecto pero sobre todo que hay que seguir la estructura de aplicación propuesta. Por lo tanto no verifica la tercera condición y ha sido descartado. |
There was a problem hiding this comment.
¿Es flexible, integrable, eficiente y tiene soporte para Typescript? Después de establecer los criterios ni siquiera los mencionas.
There was a problem hiding this comment.
Ya he respondido a esto arriba...
There was a problem hiding this comment.
Sí, pero el que te lo pregunte indica que no está nada claro. ¿Qué trabajo os cuesta poner una tabla con vuestros criterios y si se cumplen o no?
There was a problem hiding this comment.
La frase en inglés está copiada aparentemente de https://www.mitzon.com/mooc/develop-restful-web-services-using-nestjs-and-mongodb/ y ni siquiera tiene sentido. Es una web con mucho SEO juice que atrae a los incautos. ¿Qué es la "Arquitectura -"?
Use the source, Luke: Si te vas a ella, lo que dice es:
none of them effectively solve the main problem - the architecture.
Lo que sí tiene sentido (y es también irrelevante a su elección o no como framework en este contexto)
| Se han considerado los siguientes frameworks: [nest](https://www.npmjs.com/package/@nestjs/core), [fastify](https://www.npmjs.com/package/fastify), [hapi](https://www.npmjs.com/package/@hapi/hapi), [restify](https://www.npmjs.com/package/restify). | ||
|
|
||
| - Nest es la alternativa más popular. Nest es un proyecto apoyado por grandes multinacionales como Redhat y empresas como NX y Labster que tiene como objetivo resolver los problemas arquitectónicos frecuentes en las aplicaciones escritas en javascript/typescript: "... However, while plenty of superb libraries, helpers, and tools exist for Node (and server-side JavaScript), none of them effectively solve the main problem of - Architecture". Esto implica que las herramientas necesarias para construir el API están pensadas para usarse con el resto de las herramientas del proyecto pero sobre todo que hay que seguir la estructura de aplicación propuesta. Por lo tanto no verifica la tercera condición y ha sido descartado. | ||
| - Fastify es la sugunda alternativa más popular y la más novedosa. Esta librería esta centrada en la eficiencia siendo esta uno de sus principales atractivos; es la alternativa más eficiente de las consideradas según sus propios benchmark que se pueden encontrar en https://github.com/fastify/benchmarks. Su estado de mantenimiento es muy bueno y se integra bien con el logger y la librería de test escogidos. Por otra parte no verifica ninguna los requisitos convenientes y su novedad implica una falta de pluggins disponibles y de posible documentación de cara a la implementación de características sofisticadas. Además, la declaración de las rutas y sus llamadas no es uniforme. Por todas estas razones ha sido descartada. |
| "license": "ISC", | ||
| "bugs": { | ||
| "url": "https://github.com/Balrrach/IV-Proyecto/issues" | ||
| }, | ||
| "homepage": "https://github.com/Balrrach/IV-Proyecto#readme", | ||
| "devDependencies": { | ||
| "@hapi/hapi": "^20.2.1", |
There was a problem hiding this comment.
Pero ¿cómo va a ser esto devDepencency? Tendrá que ser de producción. Dev son las dependencias que sólo se instalan durante el desarrollo, test y cosas así. La mayoría de las que hay debajo, imagino (salvo lo relacionado con hapi)
There was a problem hiding this comment.
Cierto, me equivoqué al instalarla, es una dependencia de producción.
¿Por qué?
¿Por qué? |
Porque, como tú has dicho, es "implícita" y no explícita e incluso explícitamente no queda claro qué es lo que cada uno de los frameworks cumplen y qué no. Añades detalles irrelevantes en la descripción de los mismos, y eventualmente no se cumple el objetivo; que se pueda seguir claramente el proceso de aprendizaje de los conceptos de este objetivo y tu toma de decisiones.
Uso de PUT de manera no idempotente (o no actualización de la documentación, que viene a ser lo mismo, porque no hay forma de evaluarlo que no sea la documentación) En todo caso, como te he comentado, eso no habría impedido que pasaras si hubieras añadido la dependencia correctamente. |
Nest no verifica 3, Fastify no verifica ninguno de los requisitos convenientes, Restify, pese a verificar todos los requisitos no tiene un buen estado de mantenimiento y Hipo verifica todos los requisitos y está correctamente mantenido y documentado. ¿De verdad todo esto no queda claro en el documento?.
Si no hay otra forma de evaluarlo que no sea la documentación no entiendo como fueron aprobados estos dos objetivos antes del mío: https://github.com/modejota/StoragIV/pull/35, Slowmybrosh/DietApp#47. Salvo que esté muy equivocado ninguno de ellos tenía documentada la estructura de la API y, sin embargo, superaron el objetivo porque se entendió que quedaba reflejada en el propio código. Parece que, si ese es el caso, se me está penalizando por haber documentado la API puesto que, no sólo es más trabajo sino que, además, al olvidárseme actualizarla el objetivo se considera no superado cuando realmente el fallo no existe en el código. |
Tú mismo has dicho que está "implícito". Y no, te estoy diciendo que no queda claro. Vamos a ver por qué no queda claro. Y de veras que me parece un poco increíble que tenga que poner yo esto aquí, pero es tu derecho a la reclamación y yo lo hago con gusto. Quedamos en que había 4 condiciones: flexible, eficiente, integrable y soporte para tipos de typescript (no considero los "convenientes"). Vamos a ver el primero de ellos:
Irrelevante
Irrelevante.
La tercera condición es "integrable con test y logging". ¿No es integrable con test y logging? ¿Es esto tan importante? ¿"Por lo tanto" de que tenga su propio generador de aplicaciones se deduce que no se puedan usar herramientas de test y logging? ¿Ves lo que pasa si no pones unas casillas y marcas o no las condiciones que cumples? Es más, esta es una nueva condición: que te permita integrarse a un proyecto existente (lo que, por cierto, debería ser un prerrequisito, porque el proyecto ya existe), que no has mencionado como requisito. Si quieres sigo con el resto, pero es que en casi todos los casos es así. Insisto, tú has dicho que es "implícita". Si quieres cambio la corrección "débil" por "implícita", pero creo que ya habrás cogido la idea.
No, existe en un issue que te abrí para ayudarte a superar el objetivo y que simplemente obviaste. Ayuda que, por cierto, no tuvieron tus compañeros. Vamos a ver. ¿Estamos de acuerdo que has cometido un error en la documentación? ¿Un error que te señalé en #40 y que no arreglaste en la documentación, provocando una discrepancia entre esta y el código que es tan errónea (o más) que el que simplemente hubieras tenido un error en la documentación? ¿Poniendo un fix a un issue que ponía explícitamente la línea donde estaba el error? E, insisto, ¿entiendes que todo eso habría pasado (ish, acabo de ver que no hiciste caso al issue de la forma como lo planteé, pero igual no lo hubiera visto) si no hubieras cometido el error bastante grave de poner el framework como dependencia de desarrollo? |
|
Entendido. |
elegido ni
flaskniexpress?