Elección del runtime a utilizar

[arsa-dev]

Creo esta issue para debatir el runtime a utilizar en el proyecto.

He estado leyendo esta comparativa que creo que es bastante objetiva, saco las siguientes conclusiones:

• Deno tiene algunos beneficios en el uso de typescript de forma directa, módulos ES en lugar de SystemJS
• No sería necesario el uso de gestor de paquetes ya que se puede importar directamente mediante urls, esto hace necesario por otro lado una serie de mejoras de seguridad que implementa Deno y no NodeJS. Por este mismo motivo el language server y typings que ofrece Deno para el proceso de desarrollo no está tan desarrollado para ofrecer un intellisense como al usar NodeJS descargando las dependencias.

Por otro lado, he estado revisando algunos de los frameworks más extendidos en el lenguaje pero no tienen compatibilidad con Deno:

• NestJS for deno... nestjs/nest#5183 (comment)
• Port to Deno loopbackio/loopback-next#2383

Como conclusión, creo que es más conveniente en el proyecto usar NodeJS ya que está mucho más extendido y se cuenta con frameworks consolidados que nos permiten no tener que reinventar la rueda para resolver problemas ya resueltos y mantenidos por la comunidad. Aunque esto abierto ante cualquier discusión extra que no conozca y me pueda hacer cambiar de opinión.

[arsa-dev]

Tras ver la extensión de visual studio code para deno he visto que lo que comentaba antes de que estaba peor integrado con las dependencias remotas no era correcto, se puede cachear esa dependencia y ya estaría disponible tanto para ejecución como para el servidor de lenguajes.

Aunque analizando un poco más las posibilidades de crear el producto de interfaz REST con Deno, en concreto en conjunto de una tecnología muy util cada vez más utilizada (OpenAPI). Tampoco he encontrado nada que ofrezca niveles de abstracción similares a los de los frameworks de NodeJS comentados anteriormente (sin soporte para Deno) por lo que habría que trabajar a más bajo nivel para disfrutar de los beneficios de Deno. He encontrado las siguientes opciones:

• https://github.com/singhcool/deno-swagger-doc - Utiliza JSDoc en lugar de decorators, también habría que generar la especificación manualmente, aunque se haga en el JSDoc en lugar de en el json resultante.
• Add Deno support to typescript(experimental) generator OpenAPITools/openapi-generator#6732 - Está enfocado para generar código no para generar la especificación a partir del código.

Fuentes: https://dev.to/craigmorten/what-is-the-best-deno-web-framework-2k69#comment-10dg6

[JJ]

¿Habéis visto bun?

[arsa-dev]

No, le echo un vistazo en cuanto saque un momento.

…

On Sat, Oct 22, 2022, 6:02 PM Juan Julián Merelo Guervós < ***@***.***> wrote: ¿Habéis visto bun? — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQCRRMELTQGEBJUBRC2MCDWEQF2TANCNFSM6AAAAAARLZ6HOQ> . You are receiving this because you were assigned.Message ID: ***@***.***>

[arsa-dev]

Ya le he echado un vistazo, me parece mucho más interesante, aporta ventajas (principalmente de rendimiento) frente a, al menos por el momento no perjudicar en compatibilidad. Hasta el momento es el que más interesante veo de los tres que hemos analizado. De hecho no sería necesario configurar nada específico en el proyecto para hacer uso del mismo, simplemente quitar la extensión de los ficheros en los imports tal y como se haría con NodeJS. @JJ @vdeq79 si ambos estáis también de acuerdo optamos por este runtime que es lo único que le quedaría para terminar al PR #10

[vdeq79]

Tras echar un vistazo a bun, me parece interesante que se presente como el runtime de JS que supere a Deno y Node.js en cuanto a rendimiento (y tiene una serie de funcionalidades que facilita el desarrollo). Y aunque sea reciente, no creo que vaya a dar problemas en el tipo de proyecto que estamos desarrollando, así que pienso que es una buena elección.