RFC-0002 12-08-2024 Modificaciones al fullstack template

[Zoomelectrico]

Contexto

La motivación este RFC es que nuestro template esta bastante desactualizado y en este punto es más sencillo hacerlo de 0 que seguir intentando actualizar la dependencias.
Las versiones de las herramientas estan bastante desactualizadas, las herramientas son distintas entre proyectos. Hay nuevas herramientas que no se han agregado y hay patrones que no se han ejemplificado en el template.
Por otra parte, esta migración es un parte importante del RFC-0001 09-08-2024 Pipeline de testing y despliegueporque en el template es en donde se agregara los pipelines de CI/CD para pruebas y despliegues, se demostrara el uso features flags y la documentación en general.

Alcance

El alcance es un borro e inicio nuevo en el fullstack template. Esto implica

1. Definir las librerias y frameworks a utilizar.
2. Definir y ejemplificar los patrones a utilizar
3. Definir y configurar la herramienta de CI/CD
4. Documentar el uso de la herramienta

Propuesta

La propuesta es realizar un nuevo repo de 0 y dejar que cada departamento incluya dentro del fullstack template la estructuras, frameworks, librerias y documentación, necesarias para el funcionamiento del proyecto.
Detalles técnicos
Para lograr esto es necesario:

1. Crear un nuevo repositorio en Github
2. Desplegar una versión inicial del Fullstack template
3. Agregar las estructuras necesarias y su documentación
4. Hacer pruebas a la estructura determinada
5. Ejecutar el pipeline de CI/CD para revisar su funcionamiento
6. Documentar el uso de la herramienta

[Zoomelectrico]

@Lstanislao Pregunta: que tool se mono repo debems utilizar: Turbo vs nx?

[Zoomelectrico]

@Lstanislao Nx tiene más funcionalidades lo que trae consigo mayor complejidad, creo que turbo es simple para lo que buscamos y queremos hacer actualmente. Ya de por si a veces las personas se complican con turbo o parece difícil y no lo es.

[Zoomelectrico]

Me parece válido podemos quedarnos con turbo por la simplicidad y porque tiene cubiertos los features que necesitamos

[Zoomelectrico]

@Lstanislao Pregunta: Como debemos manejar los packages del mono repo?

[Zoomelectrico]

@Lstanislao Respuesta: Hay que tener cuidado en como se comparten las cosas, debido que nos ha pasado que se terminan ejecutando dependencias en el cliente que solo deberían ejecutarse en el back por ejemplo. Hago una propuesta de como debemos de tener los paquetes

• Models: solo interfaces y zod de los modelos de la BD. Los DTO deben de vivir en al respectiva aplicación, o verían util que esten acá. Me gustaria escuchar si tinen experiencia con esta distribución, a veces da dolores de cabeza con depedencias circulares y los builds
• Components: estaran los componentes de la libreria
• UI: componentes compartidos entre los distintos fronts (no se si colocarle otro nombre). A veces mas que componentes terminan siendo hasta flujos que se comparten entre ambas apps que viven en un paquete.
• Services: Sabrina me comento que se podria tener todos los queries fragmentos y mutaciones en un paquete que se comparta entre client y backoffice. En el caso que sea rest se tienen los fetch acá
• Utils: funciones compartidas entre distintas aplicaciones
• Typescript-config
• Adicionalmente debemos de evaluar que cuando se vaya hacer una integración nueva de un servicio como una pasarela de paga se haga en un paquete esto permite que se pueda usar en otro proyecto más fácil como en algún momento @Zoomelectrico hizo con Luka y Santi ya lo hizo con Stripe esto nos ahorra mucho tiempo de desarrollo.

[Zoomelectrico]

Esta es otra de la preguntas que tenía pendiente, el tema de los paquetes es algo a considerar. Por ejemplo cal.com (https://github.com/calcom/cal.com/) en su repo manejan full paquetes. A manera general dejo estos ejemplos por acá:

• https://github.com/calcom/cal.com
• https://github.com/dubinc/dub
• https://github.com/tapexyz/tape
• https://github.com/ixahmedxi/orbitkit
• https://github.com/chroxify/feedbase

[Zoomelectrico]

@isabel-asenjo responde: Creo que es importante tener los paquetes ya 100% configurados, para que los devs solo importen/exporten lo que necesiten. Ha pasado varias veces que según la persona que lo configure termina siendo inconsistente su uso/config.
Sobre los paquetes, @Lstanislao entiendo que Components tendría lo que actualmente tiene UI (que son los componentes básicos que terminamos llevando a la librería) y UI pasaría a ser cosas como el formulario de sign in, el de password recovery, etc., no? Si es así, me parece bien tener las cosas separadas. En SLF los muchachos tienen en UI ambas cosas juntas y en parte me pareció super agregar los flujos compartidos pero por otra parte siento que hay demasiadas cosas (porque es eso, están los componentes base y los componentes más complejos).
Sobre Services, en SFL lo estamos implementando así también y me parece full buen plan.
También se me ocurre que podríamos actualizar "avilatek-utils" para importar de ahí lógica súper común que seguramente se use en la mayoría de los proyectos (validaciones con regex, capitalize, formatear números de teléfono/currencies, etc).

[Zoomelectrico]

Pregunta: Cuál será la estructura que usaremos para mantener múltiples arquitecturas (graphql + mongodb, graphql + prisma, rest + mongodb, rest + prisma) dentro de un mismo repositorio?

[Zoomelectrico]

@andrespd99 Respuesta: La idea del CLI es brutal. De todas formas, si es muy costoso en temas de tiempo podrían optar por tener un monorepo con templates de todas las arquitecturas estándar separado en carpetas (creo que @lesanpi mencionó esta misma idea en el L10). De esa forma, a medida que pase el tiempo y cambien las arquitecturas, van agregando mas templates al repositorio, deprecando templates obsoletos y actualizando templates actuales según las necesidades y mejoras del equipo (aunque para entonces, ya sería seguro que habrá un CLI que se encargue de eso)

[Zoomelectrico]

@Lstanislao Respuesta: En definitiva creo que el primer paso es crear las 4 opciones en un solo repo para asegurar la mantenibilidad. En primera instancia podemos hacerlos de una vez en el example folder y hacer un tutorial de que se debe seleccionar los proyectos a utilizar copiarlos de example folder y eliminar esta carpeta al iniciar un nuevo proyecto. En un segundo paso realizar la CLI que seria brutal, mucho mas practico, fácil de mantener y delegar la creación de proyectos (ojo desconozco de CLIs) pero creo que para que quede bien, es decir que al crear se cree con las últimas versiones disponibles va llevar mas tiempo, por lo tanto lo llevaría por partes.

[Zoomelectrico]

En el repo de next hay un paquete que se llama create-next-app, que podemos usar como guía para hacer el CLI https://github.com/vercel/next.js/tree/canary/packages/create-next-app , sin embargo, lo lógico seria empezar por tener la parte de example y capaz el cli solo clone los repos por ti.

[Zoomelectrico]

@ManuelMendozaa Respuesta: Sorry por llegar tarde, pero la opción de 4 opciones en un solo repo no creo que deba ser la primera opción, deberíamos intentar primero con cuatro repos diferentes y si la experiencia lo indica, centralizarlos. Empezar con la opción donde todo está centralizado puede hacer que nos enredemos sin necesidad.

[Zoomelectrico]

Entiendo @ManuelMendozaa tu punto de vista (y siempre nos bienvenidos los comentarios) este "patrón" lo estamos sacando de los example de proyectos como next.js la verdad es que si solo tenemos un repo del cual preocuparnos para que se mantenga al idea creo que será mas facil de mantener.

[Zoomelectrico]

Cuales son las librerías y/o frameworks a utilizar a nivel del frontend?

[Zoomelectrico]

Tenemos que pensar en la parte de autenticación a mas profundidad. Yo intente montar un keycloack para clabe y la verdad que fue terrible la experiencia. Yo estaba revisando ory pero la versión opensource no es tan completa como la otra. Estuve revisando varias alterntivas y me encontre con el paper de zanzibar que es el motor de auth de google y vi esta implementación https://openfga.dev/ la cual esta bien compleja, creo que podemos revisarlo con todo el back en general

@Lstanislao Responde: pudiste ver la de supertokens @Zoomelectrico ? Se ve cool. Vere la que comentas

No la he podido ver @Lstanislao

[Zoomelectrico]

@isabel-asenjo responde: en este doc estoy recopilando las dependencias que tenemos en los proyectos actualmente Dependencias comunes tengo que terminar de formatearlo y revisar más proyectos como para llegar a una conclusión.

[Zoomelectrico]

@Leopgf responde: Responde: Clerk es muy fácil de usar y de lo único que te debes preocupar es de hacer un par de configuraciones de los JWT y llamar a los endpoint con los secrets correspondientes . Tiene varios planes divididos con enfoques para usuarios y para empresas. En su versión pro más económica para usuarios te permite manejar todo lo relacionado con incicio de sesión, recuperar contraseña, black/white list y duración de las sesiones. Luego tienes add ons que aumentan considerablemente el costo de la solución y permite tener MFA, device tracking, sesiones en simultaneo, SAML authentication (comúnmente conocido como incio por redes sociales), user impersonation (útil para prestar soporte) y un mejor manejo de roles.

[Zoomelectrico]

@isabel-asenjo responde: en este doc estoy recopilando las dependencias que tenemos en los proyectos actualmente Dependencias comunes tengo que terminar de formatearlo y revisar más proyectos como para llegar a una conclusión.

Quevedo Thanks @isabel-asenjo esta idea del doc para estandarizar las dependencias que comentas, me parece excelente lugar para que consolidemos las opiniones sobres algunas librerías de nuestro stack, como por ejemplo, la autenticación!

[Zoomelectrico]

@Leopgf responde: Responde: Clerk es muy fácil de usar y de lo único que te debes preocupar es de hacer un par de configuraciones de los JWT y llamar a los endpoint con los secrets correspondientes . Tiene varios planes divididos con enfoques para usuarios y para empresas. En su versión pro más económica para usuarios te permite manejar todo lo relacionado con incicio de sesión, recuperar contraseña, black/white list y duración de las sesiones. Luego tienes add ons que aumentan considerablemente el costo de la solución y permite tener MFA, device tracking, sesiones en simultaneo, SAML authentication (comúnmente conocido como incio por redes sociales), user impersonation (útil para prestar soporte) y un mejor manejo de roles.

Thanks! @Leopgf por los insights de clerk, estabamos pensando en algo más opensource por el tema de costos, pero en todo caso me gusta presentarlo como una opción a los clientes a nivel de costos de infraestructura

[Zoomelectrico]

Cuales son las librerias y/o frameworks a utilizar a nivel del backend?

[Zoomelectrico]

Acabamos de migrar a fastify y me parece que hemos explotado todos los beneficios de la herramienta por el desconocimiento. Deberíamos considerar esto.

[Zoomelectrico]

@Lstanislao Respuesta: esto me parece otro issue, yo he tratado de hacer frente al desconocimiento de Next por parte del equipo con charlas, post entre otras cosas, sin duda hay que ser más fuerte en este apartado porque son nuestro core. En este caso acabamos de migrar pero hay que hacer un plan para capacitar a la gente.

[Zoomelectrico]

@lesanpi Repito respuesta anterior en Frontend: Veo valioso empezar a utilizar Axiom, que es un servicio logs management, dado a que han ocurrido muchas situaciones en las que necesitamos conocer los logs de una app web, api, app mobile, webhook, etc... (Sin caer en los console logs del servidor) Adicionalmente esta herramienta te ofrece configuracion de alertas al recibir un log de error.

[Zoomelectrico]

Agree vamos a mover esta discusión al documento de Dependencias comunes que creo @isabel-asenjo @Leopgf vamos a pasar tu contribución a ese doc (se omitio en esta discusión)

[Zoomelectrico]

Que opciones tenemos para implementar los features flags?

[Zoomelectrico]

@Lstanislao Respuesta:

1. Firebase Remote Config: practicamente gratis, la inetgración con react es medio chimba porque es REST y hay que armarla todo uno (ojo esto se haria y quedaria en el template) pero basicamnete hay que estructurar los hooks y todo nosostros
2. Flagsmith: Descarte por precio
3. OpenFeature: sencillo, gratis, buena integración pero no tiene otras funcionalidades que podriamos usar a futuro.
4. GrowthBook: este es que me gusta más, full funcionalidades opción selfhosted (proyectos ilimitados) creo que podemos ir escalando acá
5. Posthot: Demasiadas funcionalidades que podemos porbar a futuro. Tier gratis y barato absurdo perooo limitación de 7 proyectos. Si queremos ir con algo mas robusto que le saquemos mas provecho a futuro este es el camino.
   Consideraciones:

• Hay que hacer un plan para integrar esto en todos los proyectos, no solo en las nuevas y que todos empecemos a desarrollar de esa forma este año.
• Hay que tomar en cuenta varias cosas. Si vamos a integrar este tipo de herramientas de una vez deberiamos de plantearnos el tema de las metricas de producto y ver su integracion con estas herramientas

[Zoomelectrico]

@lesanpi Responde:
Growthbook y Posthog son mis opciones.
GrwothBook propongo usar growthbook como un basico de los proyectos y Posthog si esos proyectos les interesa la parte de analytics, eventos, estadisticas, etc...

[Zoomelectrico]

Ok creo que llegamos a un acuerdo de utilizar Growthbook y/o Posthog dependiendo del proyecto! Creo que podriamos hacer el patrón proxy para lograr cambiar la implementación de growthbook o posthug sin cambia mucho el uso del código.

[Zoomelectrico]

@ManuelMendozaa Responde: voy a llegar con mi propuesta impopular de que esto es algo que podemos desarrollar nosotros mismos.

[Zoomelectrico]

@ManuelMendozaa Responde: voy a llegar con mi propuesta impopular de que esto es algo que podemos desarrollar nosotros mismos.

@ManuelMendozaa estoy de acuerdo contigo, y creo que seria un buen proyecto interno, sin embargo, por un cuestión de tiempo y de funcionalidad inmediata es mejor "comprar" una herramienta, este pensamiento viene orientado del midset "buy vs build" hay artículos al respecto, sin embargo, el mejor resumen, es que para nuestro time to market no tenemos la posibilidad de build

[Zoomelectrico]

Que opciones tenemos para implementar logging?

[Zoomelectrico]

@lesanpi Responde: La herramienta que investigue con mejor calidad/precio es Axiom.

[Zoomelectrico]

@andrespd99 Responde: Conozco Winston, la usé una vez pero no le saqué el jugo ni nada. Entiendo que es bastante popular y full customizable. Sidenote: Si considero importante que los todos los tools se implementen siguiendo el patrón adaptador (o plugin), de forma que si el día de mañana quieren cambiar la librería no requiera un cambio masivo.

[Zoomelectrico]

En efecto podemos usar wiston o pina. Ambos funcionan bien para generar los logs, pina esta por defecto en fastify y Axiom sería el log drain a donde centralizamos todos los logs.

[Zoomelectrico]

Que opciones tenemos para implementar telemetría o que deberiamos dejar listo para agregar herramientas de telemetría?

[Zoomelectrico]

@lesanpi Responde: Mencionando herramientas open source, deberíamos implementar Prometheus en cada droplet/instance/servidor que tengamos y a su vez tener un servicio de Grafana que permita conocer el status del servidor.

[Zoomelectrico]

@lesanpi Responde: Mencionando herramientas open source, deberíamos implementar Prometheus en cada droplet/instance/servidor que tengamos y a su vez tener un servicio de Grafana que permita conocer el status del servidor.

@lesanpi Pero entiendo que igualmente necesitamos prometheus para obtener los datos de la telemetría y poder visualizarlos con grafana no?

[Zoomelectrico]

@lesanpi Responde: Si, aunque grafana funciona con varios proveedores el más común es Prometheus+Grafana. Tengo la idea de que podríamos tener nuestro hosting de grafana.avilatek.com y que ahí apuntemos a cada servidor que tengamos que tenga el servicio de prometheus. Incluso hay un plugin de lark para grafana https://www.larksuite.com/hc/en-US/articles/360048487953-use-the-grafana-connector

[Zoomelectrico]

Creo entonces que la conclusión es usar Prometheus+Grafana