¿Sabías que los micro frontends pueden ser mucho más rápidos que sus contrapartes monolíticas? ¿Qué tal los rollbacks de características específicas? En esta charla escucharás y verás 8 ejemplos de cosas que no solo te enseñarán un poco sobre los micro frontends, sino también en qué casos son más útiles.
This talk has been presented at React Summit US 2024, check out the latest edition of this React Conference.
Bienvenido a la sesión sobre microfrontends. Los microfrontends permiten implementaciones independientes y desarrollo local. Es posible desarrollar e integrar microfrontends localmente utilizando un emulador y lograr actualizaciones automáticas. La afinación de módulos y la experiencia del usuario se pueden realizar utilizando un servicio de descubrimiento. Se pueden crear reglas en el servicio de descubrimiento para cargar selectivamente microfrontends para navegadores específicos. La IA se puede aprovechar para generar variantes mejoradas por IA y compararlas con la implementación original. Los microfrontends son altamente portátiles y se pueden utilizar en diferentes aplicaciones. El aislamiento de código y el rendimiento mejorado son consideraciones importantes en los microfrontends. Los beneficios de los microfrontends incluyen mejoras en los cambios de nombres de archivos y la sobrecarga de rendimiento. La aplicación de Netflix es un estudio de caso para los microfrontends. En general, los microfrontends ofrecen diversos beneficios y oportunidades para discusiones arquitectónicas.
Bienvenidos a todos a la sesión, 8 Cosas que No Sabías que los Microfrontends Pueden Hacer. La sesión está dirigida a personas con poco o ningún contacto con los microfrontends. El orador, Flo, es un arquitecto de soluciones especializado en aplicaciones web distribuidas y microfrontends. Él proporcionará una definición general de los microfrontends, explicando su representación técnica de un subdominio empresarial y el patrón organizativo detrás de ellos.
Bienvenidos a todos a la sesión, 8 Cosas que No Sabías que los Microfrontends Pueden Hacer. La sesión está dirigida principalmente a personas que han tenido muy poco o incluso ningún contacto con los microfrontends, así que si te consideras un experto en microfrontends, asumiría que ya conoces una o dos cosas de esto, pero espero poder enseñarte, digamos, una variedad de cosas que deberían ser posibles.
Antes de sumergirnos en el tema, unas palabras sobre mí. Hola, mi nombre es Flo, soy un arquitecto de soluciones de una empresa más pequeña llamada SmartPio. Estamos ubicados en Múnich, Alemania, y nos ocupamos principalmente de plataformas de IoT, aplicaciones modulares, auditorías de seguridad y demás. Yo mismo estoy especializado en aplicaciones web distribuidas y microfrontends. También imparto talleres, hago revisiones de código y, por supuesto, ayudo a los equipos a escalar el desarrollo del frontend. Así que si algo de lo que acabo de decir tiene sentido para ti y quieres ponerte en contacto y potencialmente discutir cómo podemos, digamos, mejorar tu arquitectura, solo envíame un mensaje. El enlace de LinkedIn también está escrito en la parte inferior de todas las diapositivas. Muy bien, pero no tenemos mucho tiempo y hay ocho cosas que debemos cubrir, así que vamos a entrar directamente en el tema, y lo que quiero hacer es comenzar con una definición general, digamos, de los microfrontends, porque hay varias definiciones por ahí y es posible que estés un poco inseguro de qué son los microfrontends. Los microfrontends son la representación técnica de un subdominio empresarial. Lo que ya puedes, digamos, saber de esa definición es que no hay restricciones y tampoco directrices sobre qué debes hacer para una implementación técnica. Todo lo que he dicho aquí es que es más o menos un patrón organizativo que surge aquí que, por supuesto, está orientado hacia
2. Implementación y Desarrollo Local
Short description:
Los microfrontends permiten implementaciones independientes con la misma o diferente tecnología. Se pueden considerar como una extensión o el siguiente paso después de los microservicios, abarcando tanto el frontend como el backend. El objetivo es tener equipos autónomos, cada uno con microfrontends aislados. Un enfoque de implementación es el desarrollo local y sin conexión, utilizando herramientas de compilación y un emulador para trabajar en los microfrontends localmente. Esto permite actualizaciones automáticas e integración de otros microfrontends.
resolviendo un problema técnico. Ahora, si quieres profundizar un poco más, por supuesto, entonces necesitarías seguir leyendo porque permiten implementaciones independientes con la misma o diferente tecnología, lo que significa que puedes, por supuesto, usar, no sé, React para escribir tus componentes, pero también podrías usar algo más. Así que un poco de las promesas que ya conoces de los microservicios. En general, los microfrontends se pueden considerar como una extensión o, digamos, el siguiente paso después de los microservicios y también afectan al frontend. No necesariamente tienen que ser exclusivos del frontend. Ellos también pueden tener una parte del backend y las mejores soluciones escalables, digamos, son realmente full stack, lo que significa que hay, por supuesto, un fragmento de UI que se entrega, pero también hay fragmentos del backend que se entregan aquí desde estos equipos. Ahora, lo que deberían hacer para lograr eso es minimizar el código compartido, al igual que ya haces con tu backend. Y, por supuesto, no quieres, digamos, tener áreas entrelazadas con otros subdominios, es decir, otros equipos que también están creando microfrontends. Al final, el objetivo es tener equipos autónomos aquí. Entonces, un equipo también puede tener múltiples microfrontends, pero la parte realmente importante es que no haya un microfrontend compartido entre diferentes equipos. Por lo tanto, los microfrontends también representan realmente una unidad aislada de la que hablas. Ahora, como dije, hay varias cosas que puedes hacer para implementarlos. Esta no será una charla en la que repase todas estas cosas. Simplemente usaré, por supuesto, implementaciones de muestra para mostrarte las ocho cosas que puedes hacer en su lugar. Así que comencemos de inmediato con el desarrollo local y sin conexión. Muy a menudo, cuando te adentras en el área de los microfrontends, la gente dice, bueno, entonces necesitamos tener un entorno de agregación, y solo en ese entorno, ¿puedes decir, dejar que tus microfrontends se ejecuten? Siempre tendrás esa especie de sensación extraña de que simplemente no estás desarrollando algo. Ni siquiera sabemos cómo se ve cuando se integra y se utiliza realmente por los usuarios finales. Y eso no es realmente bueno. Entonces, en lugar de eso, y lo que siempre animamos a la gente a hacer es, tenemos una herramienta de compilación que, por supuesto, inicia tu sesión de desarrollo localmente contra tu microfrontend, pero también tiene en cuenta otras fuentes. Y muy a menudo estas fuentes ya se pueden instalar de antemano, por ejemplo, en forma de paquetes NPM pero también pueden residir en algún lugar en línea. Y luego, cuando inicias tu sesión de desarrollo, simplemente se obtiene o no, ¿verdad? Si ya tienes algo localmente, se podría utilizar la versión en caché, pero esto te permite actualizarlo automáticamente. Entonces ahora ejecutas un microfrontend de estudio, pero ahora se ejecuta en el contexto de esto, a lo que normalmente nos referimos como emulador. El nombre se eligió porque es la misma idea que tienes, por ejemplo, cuando desarrollas, por ejemplo, una aplicación Android, tampoco lo haces directamente en tu teléfono. No haces la integración, sino que trabajas contra este emulador. Y esto, por supuesto, puede darte algunos consejos útiles. Ahora, mirando este escenario aquí, tenemos un microfrontend, es solo un proyecto estándar de Node o NPM. Entonces, basado aquí, por supuesto, en React, y ves que ya tenemos muchas dependencias de desarrollo instaladas, pero la base de código es bastante pequeña. Si miras en las dependencias en profundidad, también tienes esta extraña, que es nuestro emulador. Ahora, si simplemente inicias esto, entonces, por supuesto, nuestro microfrontend se ejecutará, pero se ve bastante vacío, pero ya está en algo donde no vemos parpadeos. Así que esa es la demostración detrás. Tenemos esta estructura de Netflix, pero está bastante vacía porque estamos desarrollando de forma aislada, ¿verdad? Pero lo que puede hacer a través de una extensión del navegador, por ejemplo,
3. Desarrollo e Integración de Microfrontends
Short description:
Puedes desarrollar e integrar microfrontends localmente utilizando un emulador. La recarga en caliente de microfrontends permite actualizaciones automáticas en el navegador. La aplicación puede escuchar un servicio de descubrimiento para actualizar y recargar microfrontends. Es fácil de activar, pero se recomienda recibir comentarios de los usuarios. Los rollbacks son más fáciles con microfrontends modulares.
es incorporar otros microfrontends. De repente, comenzaste solo desarrollando tu microfrontend, ya lo ejecutas en el emulador. Y ahora esto incluso te permite hacer la integración localmente. Y así, el microfrontend favorito que estamos desarrollando aquí para la función de lista de seguimiento es el pin 14. Muy bien. Así que bastante genial, ¿verdad? Puedes seguir adelante como lo harías normalmente con tu monolito, e incluso puedes incorporar otros microfrontends según la demanda, pero incluso puedes ir un paso más allá. Incluso puedes aplicar el mismo enfoque que tienes en el desarrollo local donde las actualizaciones, por supuesto, se insertan automáticamente en el navegador utilizando una recarga de modelo en caliente, por ejemplo. Puedes aplicar eso y hacer en lugar de HMR, HMFR, es decir, recarga de microfrontend en caliente. Así que fue una actualización en tiempo real. Entonces tu aplicación puede escuchar un servicio de descubrimiento que es como el intermediario aquí. Entre tu desarrollo y, por supuesto, la aplicación final, esta cosa sabe qué microfrontend está actualmente activo en el sistema. Entonces, cuando envías una nueva versión, como la versión 2 de tu microfrontend, la aplicación puede escuchar este cambio y simplemente decir, ey, desactiva la versión 1 actual, recarga o carga la versión 2 que ahora tenemos, y listo. Acabas de actualizar en caliente tu aplicación. Considera este ejemplo. Aquí tenemos el microfrontend de navegación y digamos que solo cambiamos cómo se llama el enlace, lo cambiamos a `vista general` en este ejemplo, restáuralo. Pero hasta ahora no ha pasado nada, ¿verdad? No lo hemos publicado. Así que publiquémoslo ahora en el servicio de descubrimiento que usamos para verlo. Por supuesto, normalmente se haría a través del sistema CI/CD. Lo haremos solo para fines de demostración en la pantalla. Ahora que lo hemos publicado, veamos la página y también debería actualizarse en cualquier momento. Vamos allá. Una vez allí, la navegación cambió a `vista general`. Muy bien. Y acabamos de tener una actualización en tiempo real y no se necesita ningún esfuerzo adicional para introducir eso. El sistema ya sabe cómo hacer eso normalmente. Lo único es que tendrás que optar por ello. Por lo general, recomendamos no hacerlo porque, bueno, quiero decir, al menos tendrías un poco de retroalimentación de los usuarios, no solo cambiar algo. Hay otros problemas potenciales, pero sí, si quieres hacerlo, es bastante fácil de activar. Lo mismo, por supuesto, se puede decir ahora si ya tienes algo allí arriba, pero por alguna razón quieres hacer un rollback. Anteriormente, en un monolito, por supuesto, necesitarías revertir todo y eso puede ser, bueno, no tan agradable siempre. Pero ahora, por supuesto, dado que ya somos bastante modulares, tenemos todos estos microfrontends que, por supuesto, traen ciertos
4. Ajuste fino de módulos y experiencia de usuario
Short description:
Podemos utilizar un servicio de descubrimiento para cambiar entre diferentes versiones de microfrontends, lo que permite actualizaciones fáciles y rollbacks parciales. El servicio de descubrimiento también puede adaptar la experiencia para diferentes usuarios finales según criterios como la región o el navegador. Un microfrontend llamado 'random' es responsable del botón 'sorpresa' en nuestra aplicación de Netflix.
componentes. Lo que podemos hacer es un escenario como este donde decimos que tenemos la versión tres de un cierto microfrontend. Y ahora simplemente intercambiamos en nuestro servicio de descubrimiento que la versión actualmente seleccionada debería ser una anterior, como la versión dos. Así que mismo concepto. Aquí vemos la UI de un servicio de descubrimiento y vemos que de este microfrontend de navegación tenemos la versión más antigua. Y ahora la vista general está activa. Así que si retrocedemos, vemos, oh, ahora es navegación de nuevo. Así que simplemente lo cambiamos y sobre la marcha, acabamos de hacer una actualización en tiempo real nuevamente. Y en este caso fue un rollback parcial. Así que solo esta área que se vio afectada ha cambiado. Bastante bueno.
Ahora, por supuesto, puedes adivinar lo que viene a continuación porque teniendo este servicio de descubrimiento y todos los módulos. Y vemos que los módulos ahora se pueden ajustar de manera muy precisa, por ejemplo, eligiendo una versión anterior o una versión que esté disponible en el futuro. Por supuesto, podemos pensar en tener una forma determinista de implementar módulos en general. Entonces lo que podríamos hacer es hablar desde la aplicación con el servicio de descubrimiento y para el primer usuario, el usuario rojo aquí, el servicio de descubrimiento dice, oh, genial. Estos son los tres microfrontends que se deben usar ahora para este usuario. Genial. Entonces la aplicación simplemente integra esos tres y listo. Tenemos el púrpura, tenemos el naranja, tenemos el rojo. Pero llega otro usuario, ahora somos el usuario azul. Y si el usuario azul pregunta al servicio de descubrimiento, dirá, oh, pero vienes, no sé, de una región diferente o tienes un navegador diferente o cualquier criterio que se esté utilizando. El servicio de descubrimiento ahora elegirá un conjunto diferente de microfrontends. Por ejemplo, del naranja, elige una versión diferente. Así que eso es como una prueba A/B. El púrpura es igual. Y luego el rojo, que debería ser exclusivo para el usuario rojo. En cambio, ahora tenemos un microfrontend azul para el usuario azul. Así que genial, el servicio de descubrimiento ya nos permite adaptar la experiencia para el respectivo usuario final. Un ejemplo que podemos ver aquí, nuevamente, estamos en nuestra aplicación de Netflix. Tenemos Firefox abierto, tenemos Chrome abierto. Ahora vemos que el botón 'sorpresa' proviene de
5. Creación de reglas para la carga basada en el navegador
Short description:
Podemos crear reglas en el servicio de descubrimiento para distinguir entre navegadores y cargar selectivamente microfrontends para navegadores específicos.
un microfrontend llamado random. Entonces, lo que podemos hacer, por ejemplo, aquí, es crear una nueva regla. En este caso, configuramos la regla para distinguir entre los navegadores. Entonces, en este momento, solo se carga en Firefox. Pero si decimos que solo en Chrome, voilà, ya no está allí. Lo mismo, por supuesto, se aplica a Chrome. Ahora está allí. Si intercambiamos la bandera y decimos, hey, en lugar de ser exclusivo para Chrome, tal vez seamos exclusivos para Firefox. Y si configuramos eso, por supuesto, ahora lo implementamos en Firefox. Así que aquí está, el botón de sorpresa nuevamente. Y, por supuesto, tendría una página detrás. Y lo mismo es, por supuesto, cierto para Chrome, ¿verdad? Ahora esto ya no lo carga y hemos terminado.
6. Aprovechando la IA para la Generación de Variantes
Short description:
Tenemos el poder de adaptar la experiencia del usuario escribiendo módulos detrás del sistema desacoplado. Un caso de uso interesante implica el uso de IA generativa, donde el servicio de descubrimiento selecciona microfrontends y el servicio de IA genera variantes mejoradas por IA. Esto nos permite comparar la implementación original con la versión mejorada por IA y analizar la retención y atractivo del usuario. Las pruebas A-B con mejora por IA son accesibles a través del intercambio de información del servicio con otro servicio.
Muy bien, ya puedes ver dónde radica el poder porque tenemos este sistema desacoplado donde ahora podemos escribir todos estos módulos detrás. Ahora tenemos la posibilidad de adaptar realmente la experiencia del usuario. Y ya no necesitamos hacerlo en el código porque tenemos esta cosa en medio del servicio establecido. Y puedo hacer incluso un poco más. Así que puedo, digamos, obtener muchas más cosas ahí fuera. Pero uno de los casos de uso bastante de moda es también potencialmente involucrar IA generativa aquí. Entonces, lo que podrías hacer es solo un ejemplo, y hay startups que están haciendo eso, como Atomic AI, es una de ellas, tienes tu servicio de descubrimiento en el medio, y como antes, selecciona, por supuesto, un conjunto de microfrontends.
Ahora, cada vez que publicas un microfrontend, el servicio de descubrimiento se comunica con un servicio específico y coloca este microfrontend en el servicio. Entonces, el servicio de IA que está detrás generará una nueva versión de este microfrontend. Por lo general, podríamos llamar a esto una variante del microfrontend o, digamos, una sugerencia. Y así tenemos para todos los microfrontends disponibles otra variante, o digamos una variante mejorada por IA. Entonces, ahora para un grupo de usuarios específico, podríamos enviar todas las variantes que hemos derivado. Y de esta manera podemos comparar cuál es nuestra implementación original versus cuál es la forma mejorada por IA. Y lo que, por supuesto, queremos ver al final es si hay más clientes potenciales que puedan surgir, o si la IA es más atractiva para el usuario final. Entonces, ¿cuál es la retención del usuario aquí, y qué podemos decir al respecto? Es bastante bueno tener este tipo de experimento o pruebas A-B ya con una mejora por IA. Y puedes hacerlo fácilmente porque, nuevamente, el servicio recibe toda la información. Puede trabajar fácilmente con otro servicio. Y luego, por supuesto,
7. IA y Portabilidad de Microfrontends
Short description:
En un monolito, sería más problemático involucrar IA debido a la necesidad de enviar todo el código base. Los microfrontends no se limitan a aplicaciones de una sola página y pueden ser altamente transportables. Pueden ejecutarse en diferentes aplicaciones y filtrarse utilizando un servicio de descubrimiento. Las pruebas A-B se pueden combinar con el concepto para experimentación adicional. Pasemos a una demostración.
hace un bucle de la variante. Esto es algo que puedes hacer bastante fácilmente. Ahora podrías decir, oh, esto también podría hacerlo potencialmente en un monolito. Pero en un monolito, sería mucho más problemático porque tendrías que enviar todo tu código base al servicio de IA. Necesitaría saber mucho más. Además, por supuesto, no puede simplemente instalar y usar nuevas dependencias, mientras que aquí, por supuesto, se utiliza el intercambio de dependencias y todas estas cosas. Por lo tanto, tiene un sistema mucho más, digamos, flexible por debajo. Y puede aprovecharlo fácilmente. La siguiente cosa que podrías mirar es, oh, microfrontends, ¿no es solo para X? Y no me refiero a Twitter aquí. Lo que quiero decir aquí es una plataforma específica, como una aplicación de una sola página, por ejemplo. Muy a menudo, la gente piensa, oh, esto es realmente todo, no sé, aplicaciones de una sola página. Pero eso no es realmente el caso. El microfrontend en sí mismo debería ser, si se hace correctamente, bastante transportable. Puede haber, por supuesto, algunas reglas especiales. Por ejemplo, podrías escribir un microfrontend que solo consista en componentes donde digas, bueno, asumo que solo se renderizan en el navegador o en el servidor. Eso podría suceder. Pero muy a menudo, deberías pensar más allá de eso. Y si lo haces, tu microfrontend en sí mismo es bastante portable. Eso significa que podría ejecutarse en diferentes aplicaciones. Por ejemplo, en una aplicación, eso es una aplicación de una sola página. Y en otra, eso es una aplicación web renderizada en el lado del servidor. Nuevamente, podrías tener un servicio de descubrimiento en medio. Pero para este punto, no es realmente necesario. Aún así, podría ayudarnos, porque el servicio de descubrimiento podría usarse para filtrar ciertas cosas. Por ejemplo, para la aplicación uno, aún entrega azul y naranja. Para la aplicación dos, entrega naranja y rojo. ¿Por qué no entrega azul? Tal vez azul tiene una bandera especial solo para navegadores. Y rojo solo tiene una bandera especial solo para servidores Node.js o algo así. Entonces, con esta información, por supuesto, ya entregaría algo que sería, digamos, utilizable con el sistema objetivo. Ahora, puede haber otras cosas. Y podrías combinarlo, por supuesto, con pruebas A-B y así sucesivamente, que, por supuesto, es componible con el concepto anterior. Así que veamos una demostración sencilla
8. Aplicación de Netflix y Microfrontends
Short description:
La aplicación de Netflix es una aplicación de una sola página que depende en gran medida de JavaScript. Si JavaScript está desactivado, la aplicación estará vacía. Sin embargo, otras aplicaciones que utilizan los mismos microfrontends pueden renderizarse perfectamente incluso sin JavaScript, gracias a su diseño progresivo. Hay algunas excepciones, como la barra de búsqueda, que solo está disponible en la aplicación renderizada en el lado del cliente cuando JavaScript está activo.
demostración. Estamos de vuelta en nuestra aplicación de Netflix y eso es básicamente solo una aplicación de una sola página. Como consecuencia, si desactivas JavaScript aquí, bueno, la experiencia del usuario será mala, más o menos, ¿verdad? Así que no hay nada. Bueno, está vacío. Claro, podríamos haber extendido la demostración y podría haber un poco más de información, como que necesitas tener JavaScript para que funcione. Pero sí, esa es la experiencia que obtienes aquí. Así que todo se hace en el navegador. Ahora, esta cosa también utiliza los mismos microfrontends, pero es una aplicación diferente. Y esta aplicación, si desactivas JavaScript, aún se renderiza perfectamente. Y aunque esta es una aplicación renderizada en el lado del servidor, simplemente utiliza los mismos microfrontends. Incluso se comporta como debería, ¿verdad? Porque los microfrontends se han escrito, digamos, de manera progresiva. Pero hay algunas excepciones a esta regla. Por ejemplo, no sé si lo notaste, pero está la barra de búsqueda. La barra de búsqueda solo está disponible cuando se renderiza en el cliente. Así que no es solo exclusivamente disponible en la aplicación de una sola página, sino que solo se renderizará correctamente en la aplicación renderizada en el lado del servidor cuando JavaScript está activo. Pero quiero decir, eso es
9. Aislamiento de código y rendimiento mejorado
Short description:
El aislamiento de código es un tema importante, especialmente cuando se trata de información sensible en el servidor. Ejecutar microfrontends en contextos aislados con variables globales dedicadas puede aumentar la seguridad y la resistencia. Además, mejorar el rendimiento en microfrontends implica utilizar módulos más pequeños e implementar estrategias efectivas de almacenamiento en caché para minimizar los cambios y mejorar la experiencia del usuario.
algo que aún puedes hacer. Muy bien, dado que el tiempo se acerca al final, no hay más demostraciones para los próximos dos, pero aún quiero mencionarlos. El primero es el aislamiento de código. Ese también es un tema que traté en mi charla en la reciente JS Nation US. Así que si estuviste allí, genial. Si no, supongo que la charla estará en línea en algún momento en el futuro, siempre activo allí y obtén tu pase para tener acceso a todas las charlas. Ahora, lo que puedes hacer con el aislamiento de código se explica de manera bastante simple en el navegador. Es un tema muy difícil porque, bueno, no puedes realmente aislar diferentes archivos JavaScript. Puedes hacer algunas cosas en iframes, pero eso siempre es difícil desde un punto de vista de diseño. Puedes hacer, por ejemplo, workers, web workers, pero luego necesitas interceptar ciertas cosas y eso también se vuelve muy complicado. Así que normalmente no lo hago. Pero en el servidor, es factible y potencialmente deberías hacerlo porque en el servidor, de todos modos hay mucha más información sensible. Por ejemplo, todas tus variables de entorno. Entonces, lo que puedes hacer es ejecutar tus microfrontends en contextos aislados que tienen variables globales dedicadas, por ejemplo, no el require estándar, y generalmente no deberían tener acceso a ninguna variable de entorno. Entonces, simularías el proceso de ENV en un servidor Node.js, por ejemplo. Y realmente deberías hacerlo porque no solo aumentará la seguridad, sino que también te permitirá dormir mucho mejor por la noche, ¿verdad? Entonces no tienes que preocuparte por lo que podría suceder ahora. Incluso si confías en todos los participantes del sistema, tiene sentido. Además, por supuesto, si uno de los microfrontends falla, si de todos modos se está ejecutando en un contexto aislado, tu aplicación principal habitual automáticamente no fallaría. Así que esto ya es, en mi opinión, bastante bueno en cuanto a la parte de resistencia. Muy bien. El último punto que quiero mencionar es el rendimiento mejorado. Y trataré de ser rápido en este. Hay varias cosas que se pueden decir al respecto, pero vamos a tener el siguiente argumento. En una aplicación monolítica, realmente necesitas hacer grandes esfuerzos para evitar que si haces un cambio, todo cambie. Y generalmente aún hay bastante cascada allí. Y así, incluso si tienes una estrategia de almacenamiento en caché prolongada, la gente siempre verá que todo ha cambiado, ¿verdad? Tal vez no los activos, como las imágenes, pero en cuanto a JavaScript, bueno, aquí tienes un gran problema. Por otro lado, en una aplicación monolítica, si realmente tienes los módulos más pequeños, generalmente son solo unos pocos kilobytes. Bueno, si algo cambia y tienes buenas estrategias de almacenamiento en caché, todo sigue siendo lo mismo excepto la pequeña parte que realmente cambió. Y hay una diferencia, por supuesto. Entonces lo harías
10. Beneficios de los Microfrontends y Conclusiones
Short description:
Los Microfrontends ofrecen mejoras en términos de cambios de nombres de archivos y sobrecarga de rendimiento. Además, brindan la oportunidad de discusiones arquitectónicas y acceso a una versión de prueba gratuita o una versión comunitaria del servicio de descubrimiento en TED.
aún, por supuesto, en el caso monolítico, tenemos la carga perezosa y demás. Pero estas cosas están aún limitadas, por ejemplo, por el nombre del archivo. Entonces cualquier tipo de, digamos, valor hash que cambie en el nombre del archivo tiene una cascada que se produce y ese no es el caso aquí. Así que es una mejora considerable.
Hay otras áreas, por supuesto, donde se podría decir que en realidad podrías ser aún mejor con una solución de microfrontends en comparación con una solución monolítica. Siempre hay, por supuesto, un inconveniente de que necesitamos tener los scripts de orquestación allí y eso generalmente implicará un poco de sobrecarga, pero puedes compensarlo y generalmente te brindan otros beneficios.
Muy bien, eso es todo por mi parte. Como ya se mencionó, ponte en contacto. Tenemos un sitio web donde también puedes reservar sesiones arquitectónicas gratuitas si deseas discutir ciertos temas. Y finalmente, también queremos animarte, si te gusta el servicio de descubrimiento en TED, siempre puedes obtener una versión de prueba gratuita o acceder a la versión gratuita community en línea. Simplemente escanea el código QR y listo. Muchas gracias y disfruta de la conferencia.
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
This Talk explores React's internal jargon, specifically fiber, which is an internal unit of work for rendering and committing. Fibers facilitate efficient updates to elements and play a crucial role in the reconciliation process. The work loop, complete work, and commit phase are essential steps in the rendering process. Understanding React's internals can help with optimizing code and pull request reviews. React 18 introduces the work loop sync and async functions for concurrent features and prioritization. Fiber brings benefits like async rendering and the ability to discard work-in-progress trees, improving user experience.
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
Today's Talk discusses building flexible, resilient, and future-proof React components using composition and configuration approaches. The composition approach allows for flexibility without excessive conditional logic by using multiple components and passing props. The context API can be used for variant styling, allowing for appropriate styling and class specification. Adding variants and icons is made easy by consuming the variant context. The composition and configuration approaches can be combined for the best of both worlds.
This Talk introduces the Remix architecture patterns for web applications, with over 50% of participants using Remix professionally. The migration from single page applications to Remix involves step-by-step refactoring and offers flexibility in deployment options. Scalability can be achieved by distributing the database layer and implementing application caching. The backend for frontend pattern simplifies data fetching, and Remix provides real-time capabilities for collaborative features through WebSocket servers and Server-SendEvents.
En esta masterclass, discutimos los méritos de la arquitectura sin servidor y cómo se puede aplicar al espacio de la IA. Exploraremos opciones para construir aplicaciones RAG sin servidor para un enfoque más lambda-esque a la IA. A continuación, nos pondremos manos a la obra y construiremos una aplicación CRUD de muestra que te permite almacenar información y consultarla utilizando un LLM con Workers AI, Vectorize, D1 y Cloudflare Workers.
Next.js es un marco convincente que facilita muchas tareas al proporcionar muchas soluciones listas para usar. Pero tan pronto como nuestra aplicación necesita escalar, es esencial mantener un alto rendimiento sin comprometer el mantenimiento y los costos del servidor. En este masterclass, veremos cómo analizar el rendimiento de Next.js, el uso de recursos, cómo escalarlo y cómo tomar las decisiones correctas al escribir la arquitectura de la aplicación.
Remix Conf Europe 2022
React Advanced 2022
React Summit 2022
DevOps.js Conf 2024
React Summit US 2024
Comments