Arquitecturas de Software Descontroladas

Hola a todos. Mi nombre es Jamie-Maria Schauven y soy cofundadora de Deity. Hoy voy a hablar sobre las arquitecturas de software y va a ser increíble, así que ponte unas gafas de sol.

Antes de comenzar, quiero dar crédito a la obra de arte. Es de James Booker y se llama Random Galaxy Art, es realmente increíble. Si quieres saber más, habla conmigo o síguenos. Mi Twitter se encuentra en la esquina izquierda. Por favor, tuitea y hazme cualquier pregunta que desees.

Ok, empecemos. Primero que nada, es 2021. Y mientras salvábamos al mundo en 1944 yendo a la batalla, hoy lo hacemos quedándonos en casa y usando nuestro teléfono. Y la mayoría de nosotros realmente lo hacemos. Y eso se refleja en el tráfico de Internet. El tráfico de Internet está creciendo como loco. Aquí está el uso de Internet que ocurrió en la primera parte de 2020 hasta abril. Como puedes ver, se está duplicando y es una locura. Y no solo el uso de Internet. Tenemos lo mismo en el mundo del e-commerce. Todos gastamos un total de 82.5 mil millones en línea en mayo de 2020, lo que representa un crecimiento del 77 por ciento año tras año. Si observas el gráfico en la esquina derecha, eso es solo hasta abril. El 27 por ciento de todas las ventas minoristas se realizaban en línea en los Estados Unidos. Y como también puedes ver, el crecimiento ha sido masivo. Hemos estado haciendo esto y dicen que el crecimiento ha sido de casi seis años. Lo que se proyectaba está sucediendo ahora mismo.

Para sobrevivir y básicamente para sobrevivir en nuestro sitio web, ya que muchos sitios web están luchando con esta cantidad de tráfico y esta cantidad de pedidos que llegan, vamos a necesitar algunos fuegos en nuestro sitio web. ¿Qué quiero decir con el principio de los fuegos? Bueno, en realidad, si quieres sobrevivir en estos tiempos y si quieres asegurarte de que tu sitio web esté listo para el crecimiento futuro, vas a necesitar un sistema de software que sea flexible para que puedas construir lo que tu negocio necesita ahora y en el futuro. También vas a necesitar tener un sistema que sea integrable para que puedas integrarte con cualquier fuente de datos, sin importar de dónde provenga. Y también, vas a necesitar ser confiable. Tu sitio web necesita asegurarse de que pueda manejar todo el tráfico a medida que creces y avanzas. Obviamente, también necesitas ser escalable.

Los mercados están cambiando muy rápido y necesitas poder adaptar nuevas características, nuevas tecnologías, nuevos mercados de manera muy rápida. Y necesitas poder extender tu software sin agregar ninguna complejidad. Y por último, pero no menos importante, necesitas ser escalable para que puedas escalar tu negocio de manera ilimitada tan pronto como tu tráfico aumente o tan pronto como estés creciendo.

Desafortunadamente, la flexibilidad de la mayoría de los sitios web es realmente, realmente mala. Es más como vodka que como yoga. Y todo esto tiene que ver con las arquitecturas. Entonces, ¿cómo se construyen los sitios? Las arquitecturas de software son básicamente el comienzo de cómo construyes tu sistema, y estás haciendo un plano de cada elemento que debe estar en tu sitio y en el sistema en su conjunto. No solo necesito envío, precios y una imagen, sino también cómo se correlacionan entre sí, qué sistema tiene que comunicarse con qué en el backend y en el frontend.

Básicamente, tenemos tres arquitecturas principales. Tenemos la arquitectura monolítica. Tenemos la arquitectura desacoplada y tenemos la arquitectura orientada a servicios. Voy a comenzar con la arquitectura monolítica. Bueno, la arquitectura monolítica es la antigua y dorada en el monolito. Todo está fuertemente acoplado. La capa de interfaz de usuario, la capa de datos, los procesos y todo está muy entrelazado. Y se ve así. ¿En mis diapositivas? Sí. En la arquitectura monolítica, como puedes ver, la capa de presentación está muy unida a la lógica empresarial y a la interfaz de datos en el diseño de capas. Encuentras estas diferentes capas, pero aún están muy cerca entre sí. Si algo sucede en el lado de la presentación, tu lógica empresarial va a tener problemas. Y si algo sucede en la lógica empresarial, tu capa de presentación va a tener problemas. Además, cuando quieres cambiar algo en tu sitio web, tendrás que cambiarlo realmente dentro de la capa. Así que dentro de la lógica, todo está ahí. Búsqueda, imágenes, precios, stock. Todo está dentro de esa lógica. Si quieres cambiar tus precios, si quieres cambiar el servicio de stock, tendrás que abrirlo y reconstruirlo desde dentro. Como puedes imaginar, si creces, será una masa muy grande. Será muy, muy complejo tan pronto como agregues más características a eso. Así que hay algunos beneficios de los monolitos. Básicamente, un monolito es muy, muy bueno ya que la aplicación se empaqueta e implementa como una sola entidad.

Es simple desarrollar. Es simple implementar. Es simple probar. Es simple mantener. Pero solo si mantienes esta aplicación muy simple.

Algunos inconvenientes del monolito, y no estoy seguro de por qué hay otro pequeño salto, pero los monolitos pueden fallar en grande. ¿Y qué puede suceder? Por ejemplo, este es un ejemplo de lo que sucedió en Magento. Tenemos un usuario administrador. Y cuando el rol de este usuario administrador estaba haciendo algo, como iniciar sesión o cambiar un producto, etc. Se reconstruía toda la caché. Así que imagina que eres un propietario de negocio y solo estás intentando iniciar sesión. Tu sitio web completo literalmente podría caer debido a este monolito, debido a esta estructura. Pero esta capa de lógica empresarial está muy, muy fuertemente acoplada con la capa de presentación.

Algunos inconvenientes del monolito. Esto me lleva a los inconvenientes del monolito. Es obvio que los monolitos son muy difíciles de ampliar y mantener. Los monolitos no son flexibles y no son confiables. Y aún así, la mayoría de internet moderno es desafortunadamente un monolito. Para evitar esto, tienes que volverte loco. Y esto lo llamamos volverse loco y tienes que ir headless. Eso es lo que está sucediendo ahora. Un gran hype en este momento. Todos están yendo headless. ¿Qué significa eso? Significa que el front-end está desacoplado del back-end y se conecta a través de APIs. La clave aquí literalmente es desmontar el front-end y desacoplarlo del back-end. Se ve algo así, donde la capa de presentación ya no está conectada a la lógica empresarial. De esta manera, la capa de presentación puede funcionar como una aplicación independiente y muchas veces se construye como una aplicación JavaScript. Que renderiza la salida de esta API en HTML. Los data que obtienes de la lógica empresarial, como los datos de stock, las imágenes y todo lo que obtienes de allí. Así que lo único que tienes que hacer es asegurarte de que los data estén disponibles desde la lógica empresarial.

Sin embargo, tu lógica empresarial sigue estando muy estrechamente acoplada. Algunas ventajas de ir sin cabeza... Los front-ends ya no dependen de los procesos del back-end. Tenemos ventajas de rendimiento en el front-end. Tenemos una alta escalabilidad y confiabilidad en tu front-end, ya que puedes escalar y ser confiable en tu front-end en su totalidad. Y puedes ser muy flexible e integrable en tu front-end. Y los desarrolladores pueden trabajar en equipos separados. Tienes tu equipo de front-end y tienes tus equipos de back-end.

Sin embargo, aún necesitas asegurarte de que todo sea accesible a través de la API. Algunas desventajas de ir sin cabeza, por lo tanto, son realmente que los datos que vienen a través de la API pueden ser muy, muy lentos. Y necesitas exponer todos los datos a través de la API. Los backends existentes no están listos. Cuando tienes, por ejemplo, Magento o Shopify, son bastante buenos. Pero aún hay mucho trabajo personalizado que debe hacerse para asegurarse de que tus datos se expongan en el front-end. Y comenzar desde cero, comenzar toda esta capa desde cero, llevará mucho tiempo. No solo tienes que construir tu equipo de front-end, sino que también debes asegurarte de que todos los datos estén allí y debes pensar en todos los aspectos de SEO. Como SEO, no estoy seguro de por qué esta diapositiva siempre se salta, pero hay problemas de SEO con aplicaciones de página única, especialmente cuando se utilizan front-ends de JavaScript.

Entonces algunas de las principales plataformas están adoptando sin cabeza. Tenemos BigCommerce, tenemos Magento, tenemos Shopify y también WordPress y otras aplicaciones se están preparando para este movimiento sin cabeza. Se aseguran de que todo el contenido y el comercio estén disponibles a través de la API. Por lo tanto, puedes agregar tu capa de API a eso y puedes comunicarte con esa capa y construir tu propio front-end allí. Hay muchas mejoras importantes en marcha para avanzar hacia esta estructura sin cabeza en oposición a esta estructura monolítica. Pero, ¿qué pasa con PWA? Muchas veces, cuando hablo de sin cabeza, la gente me pregunta sobre PWA. PWA es el matrimonio entre una aplicación nativa y un sitio web receptivo. Puedes funcionar sin conexión, tener notificaciones push, etc., etc. Como todos sabemos, el 53% de los usuarios abandonará una página cuando tarde más de tres segundos en cargarse. Y eso es, obviamente, muy extraño cuando lo pongo en una situación de la vida real, donde veo que cuando estoy esperando en la caja registradora, en 3.2 segundos, me voy. Desafortunadamente, el tiempo promedio de carga de una página web móvil en 3G es de 19 segundos. Y no es mucho mejor en 4G, donde tenemos 14 segundos. Si sabemos que 3.2 segundos hacen que nuestro cliente se vaya, todavía tenemos estos resultados que creo que son realmente malos.

Entonces, PWA realmente puede ayudar con esto. Tenemos a Tinder que lo ha estado utilizando. Se aseguran de que su sitio web sea 7.22 segundos más rápido que su aplicación cuando usan PWA, y por lo tanto, un 90% más pequeño, y tenían más mensajes, más deslizamientos y sesiones más largas. Además, Uber lo intentó y pudieron cargar en solo tres segundos en redes 2G. Con eso, estaban abriendo un mercado fórmula ya que podían ofrecer sus servicios en una red 3G en tres segundos. Otra cosa genial que puedes hacer con una aplicación web progresiva es enviar notificaciones push, y pronto podremos tener este tipo de cosas provenientes de sitios web.

Entonces, ¿qué es una aplicación web progresiva? Bueno, según nuestros amigos de Google, una aplicación web progresiva es progresiva, receptiva, independiente de la conectividad, similar a una aplicación, fresca, segura, descubrible, recompensable, instalable, y enlazable. Estos son todos tipos de características. Quiero decir, estas son todas cosas que describen un comportamiento, pero no una tecnología. ¿Qué es exactamente una aplicación web progresiva? Bueno, una aplicación web progresiva, básicamente, técnicamente hablando, son tres cosas. Es un trabajador de servicio, es un manifiesto web y es HTTPS. Literalmente, podemos agregar una PWA a cualquier cosa. No tiene nada que ver con la arquitectura, y cuando lo veo en una descripción general, así es como se ve, y no sé por qué la siguiente diapositiva, por qué no se está cargando. Y luego es así. En la arquitectura monolítica, la PWA puede existir, pero también en la arquitectura sin cabeza, la PWA puede existir. Por lo tanto, la PWA es completamente independiente de lo que está sucediendo en tu arquitectura. Desafortunadamente, la PWA no te da flexibilidad. No es necesariamente flexible. Puede ser más confiable, pero no se integra con todo. Debes agregarlo a la capa, pero te brinda un poco más de confiabilidad, accesibilidad, no realmente, y escalabilidad, no realmente. Por lo tanto, PWA no es una solución para estos sitios web que realmente necesitan crecer más.

Entonces, para hacer eso, debemos ir al siguiente nivel. Y para eso, lo llamamos la arquitectura orientada a servicios. Y lo que hacemos aquí es llevar estas características de una arquitectura sin cabeza donde tu capa de presentación está separada. También lo llevamos al backend. Por lo tanto, también desacoplamos el backend. Y eso brindará esta flexibilidad, accesibilidad, escalabilidad y confiabilidad tanto al frontend como al backend. ¿Cómo se ve eso? Se ve algo así. En la arquitectura orientada a servicios, como puedes ver, tenemos un middleware muy sólido. Y luego tenemos capas de presentación en la parte superior puede ser una, pueden ser dos, pueden ser 10.

Y tenemos servicios empresariales. Y todos estos servicios empresariales ya no están pegados entre sí. Todos son independientes. Se comunican directamente con el middleware con su propia database sin afectar al resto. El secreto de esta SOA es obviamente este middleware. El middleware conecta todos los puntos entre el backend y el frontend, pero también transfiere los data entre diferentes servicios de backend. Ya no es necesario integrarlos entre sí.

A diferencia de una arquitectura de microservicios, como puedes ver aquí, donde los microservicios se comunican directamente con la interfaz de usuario y entre sí. En la arquitectura SOA, hacemos eso a través del middleware. Entonces, en la SOA tradicional, usamos un orquestador de servicios y una herramienta ETL. Pero afortunadamente, ya no tenemos que hacer eso. Ahora tenemos GraphQL, que es perfecto y puede ayudarnos a hacer este tipo de trabajo sin construir algo muy complejo.

Entonces, si avanzo, me pregunto cuáles son las ventajas de adoptar SOA? Tenemos servicios manejables. Tenemos lenguajes de implementación y bases de datos separadas. Es altamente escalable y confiable. Es flexible e integrable, muy extensible sin agregar complejidad, ya que puedes ampliar tus backends, pero también cambiar tus backends y tus frontends sin tener que descomponer el sistema. Es una adopción rápida de nuevas características y tecnología. Y lo mejor es que puedes usar servicios existentes. Hay muchas cosas geniales disponibles para búsqueda, imágenes, stock, pedidos. Ya no tienes que construir todos los servicios tú mismo. Por lo tanto, SOA tiene ventajas. Tiene flexibilidad, integrabilidad, confiabilidad, extensibilidad y escalabilidad.

Obviamente, también hay algunos inconvenientes al adoptar SOA. Tenemos una complejidad para construir desde cero. Se necesita una arquitectura para su diseño y requiere más trabajo de configuración inicial. Pero eventualmente, es muy a prueba de futuro.

Pero ¿qué pasa si construimos una versión ligera de SOA? ¿Y si podemos asegurarnos de tener una versión ligera con la que todos puedan comenzar? Y eso es básicamente lo que hicimos en un proyecto. Y lo que hicimos fue asegurarnos de analizar, ¿qué necesitamos para construir esta versión ligera? Necesitamos un middleware, necesitamos un integrador de datos, una forma de integrar estos datos y necesitamos algunos servicios básicos. Y no sé por qué las diapositivas se están saltando de nuevo, pero necesitamos estas tres cosas para construir la versión ligera aquí. Y eso es lo que hicimos en nuestra empresa.

Entonces construimos un middleware muy sólido, que puede integrarse, como puedes ver en la parte inferior, con todos los diferentes socios de la industria. Por lo tanto, no construimos ningún servicio nosotros mismos. No hay pagos, hemos utilizado BigCommerce para el comercio, utilizamos SAP para los datos de stock, WordPress para el contenido, Algolia, etc. Realmente puedes armar un rompecabezas y utilizar los servicios que están disponibles. Incluso puedes crear tus propios servicios y utilizar lo que has construido. Y luego, obviamente, hay un equipo en el frontend que utiliza una plataforma web progresiva.

Voy a mostrarte un ejemplo de cómo funciona esto. Aquí, a la izquierda, tengo una tienda de demostración donde estoy utilizando BigCommerce y Algolia. No hay una integración directa entre los dos, ni siquiera existe. Luego, a la derecha, está mi backend de BigCommerce, donde voy a cambiar el precio de un producto. En la parte superior derecha, puedes ver lo que voy a hacer. Voy a ir a mi equipo de PWA, pedirle a mi servidor un resultado de búsqueda, que a su vez le pregunta a Algolia. Luego actualizo los datos en BigCommerce, lo cual se hace enviando esta información al servidor, que inmediatamente la envía al otro servidor, BigCommerce o Algolia. Voy a buscar un reloj y el reloj cuesta 89 euros. Y voy a cambiar el precio a 99. Lo guardaré y no necesito reconstruir ningún índice. Ni siquiera tengo que ir a Algolia. Regreso al frontend, que es una aplicación de una sola página, y simplemente vuelvo a realizar la búsqueda y el precio ha cambiado. Por lo tanto, los datos pasan por diferentes backends hasta el frontend de manera muy rápida. Los resultados son que tenemos un tiempo de procesamiento de 300 milisegundos y el tiempo de comercialización para construir cosas así es de solo dos a tres meses. Y podemos tener flexibilidad ilimitada para agregar cualquier servicio allí y construir lo que tu negocio necesite. Entonces, en resumen, tenemos tres arquitecturas principales.

Tenemos un monolito, tenemos una arquitectura desacoplada y tenemos una arquitectura orientada a servicios. ¿Cuál es la mejor? Bueno, esa es básicamente una pregunta difícil porque realmente depende de lo que estés tratando de construir. Para un bloque simple, una arquitectura monolítica podría ser perfecta. Para una tienda web, B2C, área de presentación con lógica empresarial menos compleja, está bien. Pero si tienes ambiciones de crecimiento y quieres ir hacia múltiples X, múltiples idiomas, múltiples tiendas, múltiples backends, múltiples ubicaciones de stock, lo que sea, lo que quieras hacer. Para tu tienda web multi-X realmente vas a necesitar tener una arquitectura orientada a servicios para avanzar en el futuro. Si estás utilizando arquitecturas headless para eso, pronto te quedarás atascado ya que tu lógica empresarial estará sobrecargada.

Decidir lo que tu negocio necesita es realmente una de las tareas más difíciles. Tómate tu tiempo para hacer esto y enfócate en tu negocio y en tus ambiciones, no en lo que necesitas hoy. Muchas veces veo a las personas construyendo en base a lo que necesitan hoy y sin pensar en lo que necesitarán mañana. Eso es realmente una lástima porque si estás invirtiendo tiempo y esfuerzo para hacerlo bien ahora, ¿por qué no hacerlo bien? Inmediatamente, no acumularás ninguna deuda técnica.

Esa fue mi presentación. Si quieres leer más sobre estas arquitecturas, sobre estas diferencias, escribí un blog en dev.to al respecto. Puedes seguir el enlace aquí o escanear el código QR y lo encontrarás. Si tienes alguna pregunta, por favor pregúntame. Estoy listo en la sesión de preguntas y respuestas para ti y estaré encantado de responder cada una de tus preguntas. Muchas gracias.

Antes de pasar a las preguntas de la audiencia para Jamie, por supuesto, vamos a ver los resultados de su pregunta de la encuesta. Así que si no viste la pregunta o la olvidaste, te la recordaré. La pregunta que Jamie hizo para ti es, la arquitectura que estoy utilizando actualmente para mi proyecto reciente es, y el ganador es la arquitectura de Microsoft con un 39% de los votos. Bueno, eso es mucho. Si aún no has votado, todavía puedes hacerlo, por supuesto. Y Jamie podrá hacer algo con estos resultados.

Entonces, Jamie, hola, gracias por unirte a nosotros. Gracias. ¿Qué piensas? ¿Es algo que esperabas? ¿Como un tercio, 40% de la arquitectura de Microsoft? En realidad no. También veo un porcentaje muy alto de arquitecturas monolíticas. Así que eso es algo que esperaba ya que todavía hay muchos proyectos que son monolíticos. Pero creo que también depende del tipo de proyectos que la gente esté haciendo. Creo que si fuera muy comercio electrónico, por ejemplo, muy orientado al comercio electrónico, entonces sería mucho más monolítico. Si es más orientado a empresas, con más personas de empresas, probablemente más en la arquitectura de microservicios de Microsoft o en una arquitectura orientada a servicios. Perdón, no Microsoft, microservicios. Todos te entendimos. Es un error honesto. No te preocupes. Sí. Y también, supongo que es la audiencia objetivo de nuestra conferencia hoy, ¿verdad? Así que tenemos ingenieros de DevOps a los que les gusta hacer posible esta arquitectura. Sí, diría que sería divertido hacer esta pregunta de nuevo en una conferencia de JavaScript o de React o de Angular. Entonces los resultados serían muy diferentes, supongo. Creo que habría muchas arquitecturas desacopladas. Sí, bueno, solo lo sabremos si te postulas para otra conferencia de Git Nation, Jamie. Y puedes hacer la misma pregunta de nuevo. Genial. Si me lo permites, lo haré de nuevo. Increíble.

Entonces vamos a pasar a las preguntas de la audiencia y déjame verlas. Entonces, Jamie, cuando te encuentras con un gran monolito en un cliente, ¿cuál sería tu enfoque para descomponer este monolito en pequeños fragmentos, en piezas un poco más pequeñas, y eventualmente en una aplicación de microservicios? ¿Cuál es un buen enfoque para dividir un monolito? Para mí, eso es básicamente parte de por qué nos metimos en este negocio. Muchas personas estaban luchando con esta misma pregunta y se preguntaban, `oye, ¿necesito empezar desde cero de nuevo?` En muchos casos, la respuesta era sí. Hicimos muchos proyectos grandes donde en realidad la respuesta era sí, pero queríamos hacerlo de una manera mejor para no tener que reiniciar y reconstruir todo desde cero. Por eso llegamos a lo que estamos haciendo ahora. Así que digamos que es una versión ligera, un primer punto de partida de la arquitectura orientada a servicios. Lo que hacemos es utilizar los backends actuales o los sistemas ERP o lo que tengan en ese momento, para conectarnos a un middleware y comenzar a construir el nuevo frontend. A partir de ahí, utilizamos este patrón triangular. Entonces, vamos eliminando todas las características una por una. Por ejemplo, comenzamos primero con la gestión de autos, si es un comercio electrónico o con un blog, si no lo es, si es texto o lo que sea. Así que realmente, basados en este patrón triangular, vamos eliminando todas las características. Entonces, ya estás en vivo desde el primer día. Ya tienes las ventajas. Si agregas nuevas características o si quieres tener más escalabilidad, ya tienes las ventajas desde el primer día y luego comenzamos a descomponer todas las piezas hasta que al final tengas tantas piezas como necesites. Así que agrega un middleware al sistema actual, agrega un frontend y a partir de ahí elimina todas las características del backend.

Bueno, entonces, ¿dirías que simplemente lo superes, termines tu arquitectura con una gran característica o comiences con algo de bajo valor comercial o, por supuesto, todo en tu sitio web tiene algún valor comercial, pero menor riesgo que, por ejemplo, la función de pago en comercio electrónico? No creo que la función de pago sea de menor riesgo. Creo que es uno de los riesgos más altos porque obviamente es el camino crítico que debes seguir. Pero definitivamente diría, lo que a menudo vemos es que las personas están luchando con. A veces vemos, que las personas están tratando de obtener un sistema ERP en su empresa actual o tratan de convertir su backend actual en algo que no es, sistema de gestión de almacenes, algo así. Entonces, principalmente comenzamos por cuál es tu principal prioridad? ¿Cuál es tu punto de dolor? También tenemos algunas personas que, por ejemplo, comienzan con el pago porque necesitan diferentes monedas o diferentes métodos de pago que no están disponibles en el sistema actual, o comenzamos con proyectos que realmente quieren agregar nuevas características que no existen. Por ejemplo, el ejemplo que mencioné en la charla, cuando tienes BigCommerce y quieres agregar Algolia a eso, ese es tu primer punto de partida. Te conectas a BigCommerce, agregas Algolia ya que no existe la conexión directamente. Entonces, realmente, por dónde empezar depende del proyecto, depende de en qué están luchando, si es una nueva característica, si es algo con lo que están luchando. Definitivamente abordaría los puntos de dolor primero antes de pasar a hacer que todo el sistema sea más cómodo.

Muy bien, genial. Gracias. Tengo una pregunta de Ronny. Dice buen libro, cursos y enlaces para comenzar a leer y adentrarse en este paradigma arquitectónico. Entonces, ¿cuáles son algunos buenos recursos para adentrarse en esto? Hay muchas cosas en línea sobre arquitectura de software, chicos. En realidad, escribí un blog sobre eso, eso es lo que compartí al final. Así que eso es de mi charla, pero también está el de Martin Fowler. No estoy seguro si expliqué bien el nombre. Martinfowler.com slash architecture realmente tiene una muy buena guía de arquitectura de software. Puedo compartir el enlace más tarde en la charla de DevOps.

Quiero decir, la arquitectura cambia, ¿verdad? Quiero decir, la arquitectura en sí no cambia realmente, pero la forma en que la aplicamos, la forma en que la usamos está cambiando. Quiero decir, cosas que al principio, sabes, cuando teníamos, si miras puramente la arquitectura orientada a servicios hace unos años, es muy diferente a lo que estamos haciendo ahora. Realmente tenemos cosas muy, sabes, cosas como buses de servicios empresariales y cosas muy complejas, herramientas de ETL, pero ahora podemos hacer eso con GraphQL. Entonces, estas arquitecturas más complejas se vuelven más accesibles debido a las nuevas herramientas. Así que realmente algunos libros con todas estas cosas nuevas y aún no las he encontrado. Obviamente, Twitter es una muy buena fuente, pero no hay muchas personas hablando de ello todavía, lo cual creo que es una lástima porque hay cosas realmente, realmente geniales ahí fuera. Y realmente ideas geniales para hablar. Y creo que deberíamos tener más charlas y conferencias sobre este tema y hacer que más personas realmente lo prueben y se adentren en él. Sé que es un poco difícil. Muchas personas están luchando, los gerentes de proyecto no cambian realmente la arquitectura tan fácilmente, pero creo que es realmente bueno hacerlo y abrir la conversación sobre cómo puede cambiar drásticamente tu enfoque para el futuro. Sí, por supuesto, obtener la aprobación para cambiar la arquitectura es realmente difícil porque generalmente es una gran inversión, ¿verdad? Así que realmente es un gran esfuerzo probar algo nuevo. Puedo imaginar que es algo grande, y escribir un libro sobre arquitectura cuando algunas cosas están cambiando tan rápidamente en nuestro campo, así que es difícil... Bueno, invertir como dos o tres años de tu vida para escribir un libro, y luego ya está obsoleto. Has escrito un libro obsoleto cuando se publica.

La siguiente pregunta es de Jonathan. ¿Cuáles son las diferencias clave con el facade? Parece que el facade podría actuar como el middleware del que hablaste, y enrutar las solicitudes al servicio apropiado. Bueno, creo que muy a menudo la combinación que estás haciendo son diferentes servicios en el backend, por lo que una sola solicitud, como lo que haces con esto, puede ser manejada únicamente por este servicio. Así que no creo que el facade pueda satisfacer todas tus necesidades. Hay muchas cosas diferentes que suceden desde diferentes servicios. Sí, creo que podría ser, pero lo haría más en el enfoque headless en lugar de realmente incorporarlo como un middleware.

Es una solicitud única en un solo sentido. Lo que hacemos en el middleware del frontend es mucho más que eso, podríamos decir que es un backend del frontend antes de llegar al backend real. Y también es como un middleware inteligente. Por lo tanto, no solo transporta data y transforma los data, sino que también puede capturarlo tan pronto como se necesite. Cuando hay cambios en los datos en tiempo real, podemos utilizarlos para cosas como la IA, lo cual no es posible actualmente. Ahora lo vemos sucediendo en el comercio. Las personas quieren introducir tecnología de IA. No pueden hacerlo porque sus backends son backends tradicionales y los frontends del comercio son muy lentos. Con un middleware como este, que va en diferentes direcciones, que puede responder muy rápidamente entre los sistemas backend y los sistemas frontend, realmente podemos utilizarlo. Si solo usas un servicio de solicitud única, no creo que funcione. Pero para ser honesto, no lo he probado ni profundizado en eso. Pero desde lo que tengo en mente, esa no sería la dirección que tomaría.

Genial. La siguiente pregunta es de Mike. ¿Cómo organizar el entorno de QA cuando tienes tantas bases de datos backend? Si quieres hacer una prueba completa, obviamente cada equipo o cada servicio debe ser probado por separado. Pero si haces todo completo, quieres probar todo. Simular las respuestas podría ser una de las soluciones potenciales, pero eso requiere configurar todo el conjunto de cuentas para cada servicio y cada backend.

Creo que, sabes, hacemos QA, por lo que probamos ciertas cosas que esperamos en ciertos puntos. Obviamente no podemos, también tenemos que hacer QA, por ejemplo, ¿cuál sería el tiempo de respuesta de uno de los servicios o si obtengo el tiempo de respuesta esperado de uno de los servicios? Pero tan pronto como encuentres el problema, es bastante fácil de averiguar dónde está sucediendo porque sabes, en el frontend, los data se alimentan, ¿verdad? Viene de una fuente, por lo que sabes muy bien de dónde viene. En la tradición más monolítica, he visto cosas que suceden en el proceso de pago o en los carritos, que están relacionados con algo en la búsqueda o algo así, es muy difícil de averiguar. Así que, sabes, tiene sus pros, tiene sus contras. Quiero decir, obviamente es un poco más complejo porque no es tan fácil de probar como un monolito. Por otro lado, tan pronto como sabes dónde está sucediendo, es muy fácil encontrarlo. Sí, tienes que probar todas las soluciones individuales y obviamente probarlas como un todo y simular los data, simular las respuestas podría ser una de las soluciones que podrías usar. Y a menudo lo usamos.

De acuerdo, genial. Gracias. Así que tenemos tiempo para una pregunta rápida con una respuesta rápida. Y la pregunta es de Cesar. ¿Cuándo no elegirías una arquitectura de microservicios en lugar de un monolito convencional? Bueno, depende obviamente del objetivo. No hay una cosa que sea mejor que otra. Realmente depende de qué estás tratando de construir. Definitivamente no elegiría una arquitectura de microservicios o una arquitectura orientada a servicios cuando estoy construyendo algo para mostrar a mi familia cómo está creciendo mi hijo o cómo está mi perro. Quiero decir, definitivamente no es algo que haría. También cuando estás probando cosas rápidas, si estás en la fase de inicio, solo quieres ver, ya sabes, construir algunas páginas de destino y probar cosas. Esta no sería la primera dirección que tomaría. Optaría por el enfoque orientado a servicios tan pronto como tenga ambiciones más grandes. Y eso es lo que llamamos las tiendas multi-X. Las tiendas multi-X son muy buenas para lo que hacemos para el enfoque de microservicios como una arquitectura orientada a servicios. Si tienes múltiples backends, múltiples sistemas, múltiples lenguajes en el frontend, múltiples monedas, múltiples objetivos que quieres lograr desde tu sistema. Eso es lo que llamamos multi-X. Esa es la dirección a seguir. Si no eres un multi-X y no tienes mucho de eso, no tienes problemas de escalabilidad, como solo tienes a tus padres viendo cómo crece tu hijo, entonces definitivamente no optaría por el enfoque de microservicios.

Genial. Bueno, como dije, tenemos tiempo para preguntas en vivo, pero para todos los que quieran continuar la conversación con Jamie, Jamie estará en su sala de conferencias en SpatialChat. Encuentra el enlace a continuación en el horario. Jamie, muchas gracias por unirte a nosotros y por reírte. Muchas gracias. ♪ Música animada ♪ ♪ La música animada se desvanece ♪