Priorizando la Arquitectura Sobre el Framework en el Desarrollo Web

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

¿Qué pasaría si la arquitectura de nuestras aplicaciones web no se tratara únicamente de elecciones tecnológicas? Muchas prácticas de arquitectura backend podrían ser relevantes en el frontend pero permanecen subutilizadas. Estas prácticas capitalizan cómo funciona nuestro cerebro para mejorar la eficiencia. Dado que pasamos más del 70% de nuestro tiempo leyendo código, desarrollar la capacidad de leer de manera más eficiente, alcanzable a través de prácticas de arquitectura sólidas, sería ventajoso.

This talk has been presented at React Summit 2025, check out the latest edition of this React Conference.

Alexandre Rivest
Alexandre Rivest
17 min
17 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Alexandre Rivet enfatiza la prioridad de la arquitectura sobre los frameworks en el desarrollo web para la eficiencia y el mantenimiento del proyecto. Aprovechar la memoria a largo plazo mejora la comprensión y la velocidad del código. Las aplicaciones efectivas de React requieren un nombramiento claro de componentes y precaución con el uso del estado global. Las estrategias para un desarrollo eficiente de React incluyen separar la lógica para el DOM y los componentes inteligentes, reducir las dependencias del estado global y crear clientes API independientes para flexibilidad.

1. Analizando la Importancia de la Arquitectura

Short description:

Alexandre Rivet discute la priorización de la arquitectura sobre los frameworks en el desarrollo web, enfatizando la importancia de la eficiencia y enfocándose en la arquitectura para evitar desafíos de mantenimiento de proyectos. Comparte ideas de su experiencia con proyectos de React y destaca el impacto de la arquitectura en la mantenibilidad del proyecto y la facilidad de incorporación de nuevos miembros al equipo. Alexandre también hace referencia a una presentación de Filiane Hermann, vinculando la función de la memoria con la competencia en programación.

Hola a todos. Mi nombre es Alexandre Rivet, y bienvenidos a mi charla sobre valorar la arquitectura sobre el framework en el desarrollo web. Un poco sobre mí, soy canadiense. Vivo en la ciudad de Quebec, así que soy francés. Y soy un desarrollador front-end senior en NextApp desde hace nueve años. NextApp es una empresa constante, así que he visto muchos proyectos usando diferentes lenguajes, bibliotecas, herramientas, frameworks, lo que sea. Debido a eso, tuve que aprender formas de ser eficiente en mi trabajo sin enfocarme demasiado en tecnologías específicas. Y una de las formas de lograr esto es enfocándome en la arquitectura. Por eso es mi tema de hoy.

Por lo que he visto en los múltiples proyectos de React en los que he trabajado para mis clientes, mucha gente tiende a pensar solo en React y las nuevas herramientas que acaban de salir. Sin embargo, si solo te enfocas en tecnologías, terminarás con el proyecto difícil de mantener. Bueno, tal vez no para ti, pero tal vez porque lo diseñaste. Pero lo será para los recién llegados al proyecto. Y esa es básicamente mi situación en muchos proyectos.

Así que, el año pasado, me pregunté por qué teníamos tantas dificultades trabajando en STEM que no diseñamos nosotros mismos. Comencé a buscar en línea por qué la verdadera razón detrás de esto, y me encontré con una presentación llamada Cómo Leer Código Complejo. Fue una charla dada por Filiane Hermann, quien es de Ámsterdam. Aprendí recientemente. Ella también escribió un libro llamado El Cerebro del Programador. Y Filiane establece un vínculo entre el funcionamiento de nuestra memoria y cómo ayudarnos a ser mejores en programación.

Para explicar mi punto sobre la arquitectura, voy a tomar prestado uno de sus ejercicios. Voy a mostrarles brevemente símbolos. Traten de recordar tantos símbolos como sea posible, lo suficiente como para poder dibujarlos. Va a ir muy rápido. ¿Están listos? Tres, dos, uno. Eso fue muy rápido, ¿verdad? ¿Serían capaces de reproducir toda la serie? Probablemente no, y eso es normal. La gente tiende a recordar alrededor de tres símbolos cuando se los muestro. Cuando vemos algo, la información pasa por nuestra memoria a corto plazo.

2. Optimizing Memory for Coding

Short description:

Cuando codificamos, nuestra memoria de trabajo interpreta la información, influyendo en la retención de la memoria. La memoria a largo plazo ayuda a la memoria de trabajo a reconocer patrones, mejorando la comprensión y velocidad del código. Reconocer conceptos familiares rápidamente en el código indica la utilización de la memoria a largo plazo para una comprensión eficiente.

Así que, a pesar de esto, si muestro un símbolo nuevamente, será más fácil para él recordarlo. Eso es porque después de ver la información, nuestro cerebro comienza a interpretarla. La interpretación la realiza nuestra memoria de trabajo. Analiza la información y decide qué hacer con ella. Sin embargo, si toma demasiado tiempo, la información se perderá en la memoria a corto plazo para nueva información. Cuando estás agotado después de un largo día de trabajo codificando, la mayoría de las veces es porque tu memoria de trabajo ha sido sobrecargada.

En francés, decimos que estamos sin jugo de cerebro. Una cosa importante que decir es que la memoria de trabajo no depende solo de la memoria a corto plazo. Para probar eso, vamos a hacer el mismo ejercicio pero con un pequeño giro. Voy a mostrarte un símbolo. Trata de recordar tanto como sea posible en el corto período de tiempo. ¿Listo? Tres, dos, uno. Si te pido que escribas lo que viste, sería más fácil, ¿verdad? Eso es porque reconocemos esos símbolos. Eran letras.

Eso es porque nuestra memoria a largo plazo apoya a nuestra memoria de trabajo en el análisis de lo que hemos visto. Hemos entrenado nuestra memoria a largo plazo toda nuestra vida para reconocer estas letras. El mismo principio se puede aplicar en programación. Si digo public void if else, use state props para React-specific. Todos esos son conceptos que hemos aprendido a reconocer rápidamente porque los hemos visto muchas veces, y creamos memoria a largo plazo sobre ellos. Así que no tenemos que preguntarnos, ¿qué significa? Simplemente lo sabemos. Nos hace leer el código más rápido.

3. Leveraging Long-Term Memory for Coding

Short description:

Comprender las limitaciones de la memoria a corto plazo y aprovechar la memoria a largo plazo. Agrupar información ayuda a la retención de memoria y a la formación de conceptos. Utilizar la memoria a largo plazo mejora la memoria de trabajo para una interpretación eficiente.

No es suficiente encontrar fácilmente nuestro camino en el código y entender rápidamente lo que está sucediendo. Incluso si línea por línea, tuviéramos información para entenderlo, nuestra memoria a corto plazo se vuelve insuficiente. Como dije, de dos a seis elementos como máximo a la vez. No estoy seguro si ya estaba en el libro, pero este es un punto interesante en relación con esta métrica. ¿Por qué somos capaces de entender palabras de más de seis letras si nuestra memoria a corto plazo es tan limitada?

Haremos una última versión del mismo ejercicio. Así que, aún los símbolos, trata de recordar tanto como puedas. ¿Listo? Tres, dos, uno. ¿Captaste lo que estaba escrito? Cuando doy esta charla frente a una multitud, hago que toda la audiencia diga cats love cake al mismo tiempo. Es mágico. ¿Por qué fue tan fácil? Bueno, porque era el mismo número de letras en el mismo ejercicio, pero ahora, ¿lograste recordar todo? La solución es bastante simple.

Nuestro cerebro es excelente agrupando o fragmentando información. Nuestro cerebro puede asociar un conjunto de letras, crear un concepto único. Cuando ves las letras CAT, no piensas en esas tres letras. Se convierten en uno con el concepto de un gato porque creaste memoria a largo plazo sobre esos siendo el animal. Los cerebros humanos son excelentes para reconocer patrones. Crear asociaciones en nuestra memoria a largo plazo ayuda enormemente a nuestra memoria de trabajo a interpretar la información rápidamente.

4. Developing Effective React Applications

Short description:

Crear componentes significativos de React con nombres claros. Tener cuidado con las dependencias excesivas, especialmente el uso del estado global. La dependencia del estado global puede llevar a un enredo del código y dificultad en la identificación de problemas.

Para hacer grandes aplicaciones de React que sean fáciles de trabajar, necesitamos formas de crear memorias a largo plazo útiles que puedan ayudar a nuestra memoria de trabajo. Ahora, ¿cómo hacemos eso en React? Voy a darte un par de consejos. El primero, usa componentes. Esto es básicamente el rasgo más conocido de los cuatro. Puede sonar obvio para algunos, pero he trabajado en proyectos donde cada página era un solo componente, un solo archivo de dos mil quinientas líneas de código. Así que, incluso después de trabajar meses en este archivo, todavía me perdía. Así que, crear componentes con nombres que representen lo que realmente hace. Es el mismo principio que dar nombres y variables a variables o funciones.

Y es más útil crear memoria a largo plazo sobre los nombres de los componentes que qué línea de código contiene qué tiempo de código contiene lo que estás buscando. Los mismos consejos, cuidado con demasiadas dependencias. Digamos que tienes una gran aplicación y has creado muchos componentes, bueno, nombre y todo. Pero todavía tienes problemas para encontrar lo que estás buscando en la base de código. ¿Por qué es eso? Una de las razones que veo en muchos proyectos es por la dependencia externa utilizada en el componente. Digamos, por ejemplo, que quieres tener un estado global en tu aplicación. Puedes usar el context API o Redux o Xtend, tú lo nombras. No es importante. Esas herramientas te permiten acceder a estados en cualquier componente que desees. En teoría, esta es una gran característica que previene problemas.

En la práctica, puede ser bastante peligrosa. Al requerir un valor, se vuelve fácil simplemente agregar un nuevo selector al componente y listo, tienes acceso al valor. Sin embargo, si repites esta acción una y otra vez, podrías obtener algo como esto, donde la mayoría de tus componentes se vuelven dependientes de tu estado global. Ya no reciben props. Simplemente van a la información por sí mismos. Necesito ser claro sobre algo. Esto no es culpa de la biblioteca que estás usando. Esto es una ley de arquitectura. Dado que tienes un problema relacionado con el estado global, ¿cómo puedes saber cuál es el culpable? Y si eres nuevo en tu proyecto, buena suerte encontrando el problema por ti mismo.

5. Strategies for Effective Component Architecture

Short description:

Desarrollar memoria a largo plazo con lógica separada para componentes DOM e inteligentes, reduciendo las dependencias del estado global y asegurando la independencia de la API para aplicaciones de una sola página eficientes.

Estarás aquí por un tiempo. Entonces, ¿qué podemos cambiar en nuestra arquitectura para desarrollar una memoria a largo plazo de nuestro código y encontrar problemas más rápido? Bueno, antes de la llegada de los hooks en React en los viejos tiempos, había un patrón desarrollado por la comunidad para separar la lógica de la aplicación de la lógica de renderizado. Había dos nombres para ello. El componente versus contenedor o el componente DOM versus componente inteligente. El componente DOM recibe props y renderiza HTML. Eso es todo. No hay dependencias externas, excepto las props. Los componentes inteligentes se encargan de obtener información, manejar el estado y dar datos al componente DOM como props. No hacen mucho renderizado excepto alimentar información. Los componentes inteligentes suelen estar en la raíz de un árbol de conceptos. Una pieza que puede ser directamente independiente del resto de la página, el resto de la aplicación. Y normalmente, al aplicar este patrón, obtendrás principalmente componentes DOM en tu aplicación y unos pocos componentes inteligentes.

Así que, en tu árbol, tendrás menos dependencias de tu gestión de estado global, por lo que tendrás menos puntos de fallo en tu problema. Se vuelve más fácil crear memorias a largo plazo del estado global ya que hay menos componentes directamente impactados por él. Recibir esta información múltiples veces también crea la memoria, hace que la memoria sea más duradera. Si quieres tener aún más memoria a largo plazo sobre esto, incluso puedes dar nombre a los componentes inteligentes que haga más obvio que tienen esta lógica. Por ejemplo, tal vez podrías usar el añadir un sufijo al nombre de tus componentes. La descripción no es importante siempre que lo haga más claro, más obvio.

El tercer consejo para ti es hacer las APIs independientes. En aplicaciones de una sola página, una de las características más frecuentes que veo es que la aplicación necesita cargar contenido desde una API, desde un servidor. Hay algunas bibliotecas que te ofrecen manejar todo lo que gira alrededor de la llamada a la API. Un ejemplo de eso es un proyecto en el que trabajé donde decidimos usar GraphQL porque era algo nuevo y brillante. REST estaba muerto, larga vida a GraphQL. Así que, haremos la solicitud de esta manera. Crearemos, definiremos una consulta y usaremos el use query de la biblioteca que estamos usando para obtener la información y tener estado de carga, estado de error, y así sucesivamente. En mi ejemplo aquí, uso Apollo, pero no es el único que ofrece este patrón. Relay, Redux Toolkit, y muchos otros también lo hacen. Eso es solo para el ejemplo. En un momento, descubrimos que GraphQL nos estaba ralentizando más que usar una simple API REST para nuestro caso de uso. No era un caso de uso para nosotros.

6. Enhancing React Component Efficiency

Short description:

Creación de clientes API independientes para flexibilidad en la comunicación de componentes, extrayendo lógica no relacionada con la UI para una codificación eficiente en varias plataformas.

Pero, estábamos un poco atrapados allí, porque nuestros componentes de React dependían de las consultas de GraphQL. Como puedes ver en nuestro componente Pokemon sensors. ¿Qué deberíamos haber hecho en su lugar? Bueno, hoy en día tendemos a crear clientes que abstraen nuestro trabajo con la API. Esto nos da más flexibilidad en cómo nos comunicamos con el back end. Así que, por ejemplo, para este ejemplo, el cliente de Pokemon con la función get Pokemon, y ahí está mi consulta en él. Pero, en mi componente, puedo hacerlo de la manera que quiera. Podría usar el use hook para obtener la información con un suspense. Si quiero la misma funcionalidad que el use query de Apollo, por ejemplo, podría usar React query de 10 stack, que solo maneja la gestión. No tiene nada que ver con la API. Si decido que quiero usar esta llamada de API en un componente de servidor, podría simplemente llamar al get Pokemon en el mismo componente, en un componente de servidor de React. También podría usarlo en una aplicación React native, porque mi API es independiente de la UI. Hay muchas piezas de código que se pueden extraer de los componentes de React, y esta es la primera.

La segunda que puedo darte, este es el último paso de hoy, es la lógica de negocio. Esta lógica corresponde a toda la lógica de negocio de tu producto, el tipo de lógica que puedes discutir con alguien que no es programador. Alguien que no conoce React, bueno, es la lógica que gira en torno al modelo de negocio de tu producto. Por ejemplo, digamos que decides hacer un sitio web de compras donde tienes un carrito, puedes añadir artículos a tu carrito, y puedes finalizar la compra y comprar todo. Bueno, el carrito de compras tendrá lógica asociada a él. Por ejemplo, no puedes tener menos uno artículo en tu carrito. Eso simplemente no es posible. Para cada artículo, solo puedes tener una cantidad positiva. Cuando abres este sitio web, el carrito debería estar inicialmente vacío. Si la cantidad de artículos cambia a cero, podría querer eliminar el artículo del carrito. Toda esta lógica se puede implementar sin la UI. Esto es pura lógica de negocio. Cuando la lógica podría ser exactamente la misma en una aplicación de una sola página, renderizado del lado del servidor, en un backend de express, en una aplicación React Native, entonces no debería estar en un componente o un hook. Debería ser extraída. Así que, además, al extraerla, puedes nombrar todo este comportamiento, y puedes incluso facilitar las pruebas automatizadas. ¿Cómo se vería como código en un componente? Podrías crear una simple clase de JavaScript que represente tu carrito con todos estos métodos que representan cómo puedes manipular el carrito. En este ejemplo, puedes actualizar la cantidad de artículos, puedes eliminar un artículo, puedes contar la cantidad total de artículos, e incluso tenemos un método para crear un carrito vacío. Luego, en tu componente, bueno, tendrás toda la lógica de UI, la lógica de estado de la aplicación.

7. Strategies for Efficient React Development

Short description:

Creación de una clara separación entre la lógica de UI y la lógica de negocio para una mejor comprensión y retención de memoria a largo plazo.

Así que, podríamos crear un estado local, un estado para un carrito donde el carrito esté inicialmente vacío. Usamos el método. En el renderizado, si queremos que se muestre la cantidad total de artículos, tenemos un método para eso. O, incluso, si queremos actualizar la cantidad de artículos, usamos nuestro carrito, y simplemente llamamos al método actualizar cantidad de artículos. Al hacer eso, simplemente creamos una gran separación de preocupaciones entre UI y lógica de negocio. La arquitectura de componentes, de esta manera, es mucho más sencilla de entender, porque se centran en lo que se supone que deben hacer, renderizar UI.

Hacerlo también ayuda a que el código esté más cerca de la forma en que los no programadores hablan contigo sobre la aplicación. Y, al hacerlo, crea una mejor memoria a largo plazo, porque no necesitas convertir lo que alguien está diciendo a cómo está hecho el código. Está más cerca de la realidad. Están más cerca el uno del otro.

Así que, te he dado cuatro trucos para ayudarte a ser más eficiente al desarrollar una aplicación React, para que puedas crear mejores memorias a largo plazo que podrían ayudarte a navegar el código más rápido. Pero, si recuerdas, al principio de la charla, dije algo sobre lo difícil que la arquitectura de aplicaciones puede ayudar a tus futuros compañeros de equipo a ponerse al día rápidamente. Porque, al final, tal como dijo Martin Fowler, cualquier tonto puede escribir código que una computadora pueda entender. Los grandes programadores escriben código que los humanos pueden entender. Gracias. Si estás interesado en lo que hago, lo que digo, y quieres aprender más sobre la práctica que acabo de contar, aquí hay algunos enlaces sobre un artículo en el blog que escribí. Gracias de nuevo.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Escalando con Remix y Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Escalando con Remix y Micro Frontends
Top Content
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.
Entendiendo la Arquitectura Fiber de React
React Advanced 2022React Advanced 2022
29 min
Entendiendo la Arquitectura Fiber de React
Top Content
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.
Componentes de Full Stack
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Componentes de Full Stack
Top Content
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.
Thinking Like an Architect
Node Congress 2025Node Congress 2025
31 min
Thinking Like an Architect
Top Content
In modern software development, architecture is more than just selecting the right tech stack; it involves decision-making, trade-offs, and considering the context of the business and organization. Understanding the problem space and focusing on users' needs are essential. Architectural flexibility is key, adapting the level of granularity and choosing between different approaches. Holistic thinking, long-term vision, and domain understanding are crucial for making better decisions. Effective communication, inclusion, and documentation are core skills for architects. Democratizing communication, prioritizing value, and embracing adaptive architectures are key to success.
Composición vs Configuración: Cómo Construir Componentes Flexibles, Resilientes y a Prueba de Futuro
React Summit 2022React Summit 2022
17 min
Composición vs Configuración: Cómo Construir Componentes Flexibles, Resilientes y a Prueba de Futuro
Top Content
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.

Workshops on related topic

IA a demanda: IA sin servidor
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
IA a demanda: IA sin servidor
Top Content
Featured WorkshopFree
Nathan Disidore
Nathan Disidore
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.
Masterclass de alto rendimiento Next.js
React Summit 2022React Summit 2022
50 min
Masterclass de alto rendimiento Next.js
Workshop
Michele Riva
Michele Riva
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.