[WIP] Estudio de la solución Rest API

[JoseJPR]

En esta issue se definirá el tipo de solución que se aplicará al proyecto Rest API a desarrollar.

La finalidad de este proyecto es la de hacer las veces de integrador/proxy entre el proyecto Frontend y los Servicios Externos.

Seguridad

Ya que trabajaremos con frameworks y librerías OpenSource externas y con la idea de crear un proyecto sostenible y con un alto nivel de seguridad, propongo realizar el proyecto en base a micro-dependencias. Este ecosistema se consigue realizando un análisis de las necesidades del proyecto definiendo qué se desarrollará internamente por el equipo y qué será importado desde el ecosistema externo OpenSource. En este último caso propongo trabajar con las librerías expuestas en el siguiente punto dado su situación actual, pasada y prevista de futuro.

TODO: Revisar la posibilidad de agregar Snyk como Herramienta Cloud de análisis de dependencias.

Framework Base y Librerías

• Typescript
• ESLint
• Jest
• Fastify
• PouchDB
• node-cron (En el caso de crear un schedule interno)
• jscpd
• fastify-gql

Posibles Servicios Externos

• Slack
• Youtube
• Github

Arquitectura de Software

Como Arquitectura de Software propongo una Rest API compuesta según las siguientes bases de diseño:

• Generación de las queries GraphQL por servicio externo a obtener. Dicha API estará versionada pudiendo escalar tanto de forma horizontal router-middleware-service, por servicio externo, como en vertical por version.

Ejemplo de query: /graphql/v1?query={services: { name: "slack", api: "users" }} /graphql/v1?query={services: { name: "slack", api: "jobs" }} /graphql/v1?query={services: { name: "youtube", api: "videos" }} /graphql/v1?query={services: { name: "github", repository: "coffeewip-organization", api: "issues" }}

Información adicional para trabajar con versionados y no deprecaciones con GraphQL: https://medium.com/swlh/no-graphql-doesnt-magically-fix-api-versioning-sorry-10ba203f491f

• Diseño y elaboración de una capta de abstracción mediante librerías propias (posible publicación en NPM) con la idea de que cada librería sea un propio proyecto y paquete instalable en el proyecto mediante NPM. Como grupo de librerías, en una primera instancia, deberíamos abordar una por cada Servicio Externo.

Ejemplo de librerías: coffeewip-slack -> [WIP] Creación una librería NPM wrapper como enlace a la API de Slack coffeewip-youtube coffeewip-github

Persistencia de Datos

• Con la idea de que no se tengan que realizar consultas a los Servicios Externos por cada petición desde el proyecto Frontend propongo elaborar una estrategia de alojamiento local de datos. Esta estrategia consiste en la creación de una DB local no relacional gestionada con la librería PouchDB en la que podamos alojar los documentos capturados de forma recurrente desde los Servicios Externos.
• Inicialmente, por cada nuevo deploy, el proyecto Backend será el encargado de llamar a los Servicios Externos y extraer los documentos mínimos que sea necesario para el correcto funcionamiento del proyecto Frontend.
• De forma cíclica y gestionado mediante un scheduler el proyecto Backend se encargará de obtener información actualizada desde los Servicios Externos siendo actualizada dicha información por cada servicio en el caso de que la misma cumpla unas reglas de negocio concretas y los documentos hayan sido obtenidos correctamente.

[chempogonzalez]

Me parece perfect. Yo añadiría quizás estas 2 librerías también:

• jscp : Para hacer más "lint" y evitar el copy/paste (duplicación)
• dotenv-checker: Para checkear/crear el .env basado en .env.schema en develop
• fastify-blipp: Para mostrar los endpoints disponibles en el servicio al levantarlo

Los servicios externos me parecen bien para la finalidad actual de la web.

[chempogonzalez]

Para la parte del versionado/escalado propongo GraphQL y evitar ese /v1 /v2 y crear endpoints nuevos para devolver diferentes modelos de datos.

Web: https://graphql.org/

[JoseJPR]

@chempogonzalez Creo que te refieres a jscpd en vez de "jscp", ¿estoy en lo correcto?

He realizado unos test de "fastify-blipp" y funciona de forma "correcta" cuando generamos un router con fastify pero tengo dudas si con "fastify-gql" lo haga. Creo que es algo que podemos dejar para más adelante :)

[chempogonzalez]

Vale perfecto! Cierto, al tirar por GraphQL pierdee bastante su función ya que es más útil para las REST APIs. :)

Si, me refería a esa librería que menciones, fallo técnico jajaja

[JoseJPR]

Done! agregado a la descripción general de la issue para tenerlo en cuenta para desarrollo, thanks por los tips @chempogonzalez :)