Principios para el Desarrollo de Aplicaciones Frontend a Escala

Spanish audio is available in the player settings
Rate this content
Bookmark

Después de pasar más de una década en Google, y ahora como CTO de Vercel, Malte Ubl no es ajeno a ser responsable de la infraestructura de software de un equipo. Sin embargo, estar a cargo de definir cómo las personas escriben software, y a su vez, construir la infraestructura que están utilizando para escribir dicho software, presenta desafíos significativos. Esta presentación de Malte Ubl revelará los principios rectores para liderar una gran infraestructura de software.

26 min
02 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla discute la escalabilidad de las aplicaciones frontend a través de principios como derribar barreras, compartir código en un monorepo y facilitar la eliminación de código. También enfatiza la migración incremental, abrazar la falta de conocimiento y eliminar la complejidad sistemática. La charla destaca el uso de la automatización en la migración de código y la importancia de eliminar barreras para permitir una migración de código más fluida.

Available in English

1. Introducción y Antecedentes

Short description:

¿Cómo les va a todos? Esta es en realidad mi primera conferencia, después de un descanso. Solía construir aplicaciones JavaScript grandes, ahora es TypeScript. React ha evolucionado y ahora está disponible para todos. Me uní a Brasil y encontré un equipo interno de Dex. Lo convertimos en un equipo de productos para resolver problemas comunes. Anunciamos Versell Spaces para implementar los conceptos discutidos.

¿Cómo les va a todos? Sí, gracias por hablar sobre JSConf y cosas así. Tomamos la sabia decisión de no tener un evento en 2010 porque de todos modos no habría sucedido, esta es en realidad mi primera conferencia, al menos si estás contando conferencias de la community, después de este descanso más largo en la vida de todos. Vengo de San Francisco. En realidad estaba en Alemania antes, todavía un poco desfasado, pero estoy tratando de animar un poco el ambiente aquí.

Así que en este sentido de recordar un poco, hace cinco años en JSConf Australia, di una charla y comencé con esta frase, Hola, solía construir aplicaciones JavaScript muy grandes. Todavía estaba en Google en ese momento y estaba asumiendo un papel ejecutivo. Así que en realidad no estaba construyendo cosas yo mismo, pero aprendí algunas cosas y pensé que sería una buena idea dar una charla al respecto. Pero eso fue entonces. Estoy de vuelta. En realidad estoy de vuelta construyendo cosas en JavaScript, aplicaciones muy grandes. Obviamente, nadie hoy en día realmente hace eso. Son aplicaciones TypeScript y aquí estamos.

Otra diapositiva de esa charla fue que pensé que React era bueno. Y el contexto era que en aquel entonces, hace 10 años, construí un framework JavaScript en Google llamado Wiz y estaba pensando si hacerlo de código abierto y justo en ese momento, sale React y se ve realmente bien y pienso que el mundo no necesita esto. Nos lo vamos a quedar para nosotros. Creo que ahora fue un poco un error porque había algunas buenas contribuciones en cuanto a la escalabilidad de las aplicaciones que podrían haber sido realmente valiosas para el ecosistema aunque solo se mostraran. Pero ahora estoy en Brasil, puedo ayudar un poco a impulsar a React y creo que con las cosas relacionadas con los componentes del servidor, etc., parte de esta situación en la que pensamos en Google en aquel entonces, ha vuelto y ahora está disponible para todos, lo cual es increíble. Genial. Muy bien.

Me uní a Brasil, hablé con todos los equipos y descubrí que tenemos un equipo interno de Dex. Así que hablé con ellos, ¿qué están haciendo? Me explicaron lo que están haciendo. Me parece una muy buena idea. Y luego voy a hablar con los clientes. Nuestros clientes me dicen que sus problemas son los problemas que nuestro equipo interno de Dx está resolviendo. Y entonces pensé, ¿por qué no convertimos esto en un equipo de productos y lo hacemos disponible para todos para que no todos tengan que resolver los mismos problemas una y otra vez? Ahora, esto es relevante de alguna manera porque la charla que di en aquel entonces, era tan teórica porque, ya sabes, no tenía nada de código abierto. Solo podía decirles a las personas, esto es lo que aprendí. Pero tienes que descubrir cómo llevar este aprendizaje a algo real por ti mismo. Ahora, voy a estar haciendo cosas similares hoy y más poder para ti si quieres construir tú mismo. Sabes, anunciamos un producto llamado Versell Spaces hace unas semanas que intenta implementar algunas de las cosas de las que voy a hablar de una manera reutilizable.

2. Scaling Front-end Applications

Short description:

Entonces, vamos a lanzar software como Google o Vercel porque es 2023. Pero creo que esto es realmente cierto, la velocidad de iteración resuelve todos los problemas conocidos. Lo que quiero decir es que cuando creamos software, vamos a cometer errores con el tiempo, y tenemos que lidiar con ese hecho de manera profesional. El resto de esta charla trata sobre cómo puedes escalar más allá de ti mismo, pero a través del software que has construido y a través de los mecanismos que estableces en tus equipos para mejorar a todo el equipo. Quiero hablar sobre los principios para escalar aplicaciones front-end. Tengo seis. Comencemos con este: derribar las barreras.

De acuerdo. Entonces, vamos a lanzar software como Google o Vercel porque es 2023. Pero al hablar de Google, había este tipo llamado Eric Schmidt, él fue el CEO durante mucho tiempo y, al menos internamente, tal vez esté filtrando algo, lo siento, siempre solía decir que los ingresos resuelven todos los problemas conocidos. Básicamente, decía que si simplemente ganas más dinero, realmente no importa qué más estés haciendo. Y creo que eso está mal.

Ciertamente, no tenemos, ya sabes, dinero infinito, tú no tienes dinero infinito. Creo que Google ya no tiene dinero infinito. Entonces, eso no es realmente un buen lema. Pero creo que esto es realmente cierto, la velocidad de iteración resuelve todos los problemas conocidos. Lo que quiero decir es que cuando creamos software, y de hecho, la primera charla de hoy tenía un punto similar, vamos a cometer errores con el tiempo, ¿verdad? Eso es lo único que sabemos, que el futuro es incierto y tenemos que lidiar con ese hecho de manera profesional. Y la forma en que haces eso de manera profesional es siendo capaz, en el momento en que cometes ese error, de react a él e iterar y hacerlo bien la segunda vez. Entonces, con eso, pensemos un poco en nuestro papel en esto, y para el resto de esta charla.

Entonces, el ingeniero senior, o lo que realmente quiero decir es el ingeniero senior en minúsculas, ¿verdad? Hemos estado aquí por un tiempo. ¿Qué hacemos, ¿verdad? Puede que haya una sesión más tarde hoy sobre consejos profesionales, y podrían decirte algo como, ya sabes, si quieres tener más impacto, necesitas escalar más allá de ti mismo, y lo que la gente generalmente asocia con esto es algo a lo largo de las líneas de tener responsabilidad de gestión o al menos decirle a otras personas qué hacer. Es algo relacionado con las personas, ¿verdad? Y por lo tanto, el resto de esta charla es algo muy diferente a eso. Se trata de cómo puedes escalar más allá de ti mismo, pero a través del software que has construido y a través de los mecanismos que estableces en tus equipos para mejorar a todo el equipo, pero a través del software que estás construyendo. Y así, para el resto de estas diapositivas, considérate como el hipotético líder del hipotético equipo de plataforma para tu hipotético equipo de ingeniería de 12, 50, 100 personas, ¿verdad? Eres esa persona y tu trabajo es hacer que ese equipo escale mejor. Genial. Esa fue una introducción larga. De todos modos, quiero hablar sobre los principios para escalar aplicaciones front-end. Tengo seis. Tengo uno adicional, pero creo que soy demasiado lento. Así que haré seis. De acuerdo. Comencemos con este. Derribar las barreras. Esto es algo que en realidad no estaba claro para mí qué tan grande sería su efecto. Como mencioné, estuve en Google durante mucho tiempo. No estaba usando las herramientas que todos los demás estaban usando, pero estaba haciendo esta conferencia, JSConf. Iba a estos encuentros yo mismo y escuchaba a las personas en el escenario estar increíblemente emocionadas por los pequeños modules, ¿verdad? Y había una empresa llamada NPM, Shouter NPM, que creó algo llamado modules privados.

3. Sharing Code and Monorepo

Short description:

Si quieres esa dosis de adrenalina, migra a un monorepo. Realmente vale la pena. Fomenta la colaboración y reduce las barreras para colaborar. Los propietarios de código de GitHub abordan los problemas de escalabilidad. Como parte de nuestro producto Spaces, estamos lanzando algo llamado owners, que básicamente es como los propietarios de código pero mejor.

Y así, la gente solía compartir código en su empresa publicando módulos en NPM. Ahora me uno a VerCell y veo que eso sucede, donde un equipo dice: 'Tienes un código genial, ¿puedes publicarlo en NPM para que pueda usarlo?' Y luego tengo que actualizar mi archivo package JSON a tu nueva versión. Tal vez alguien me ayude, tal vez lo haga automáticamente. Es un proceso increíblemente malo y a gran escala, si tienes un equipo grande, realmente duele. Así que mi consejo extraño pero efectivo, si aún no lo has hecho y quieres esa dosis de adrenalina, migra a un monorepo. Realmente vale la pena. Ahora, obviamente, tiene sus compensaciones. Todo en ingeniería de software tiene sus compensaciones. Después de unos meses, te darás cuenta de que todos pueden cambiar todo, tal vez esa no sea la mejor idea del planeta. Pero es bueno tener una base que fomente y reduzca las barreras para la colaboración y puedas lidiar con los problemas que surjan en el camino. Y hay ciertos problemas de escalabilidad que, por ejemplo, los propietarios de código de GitHub abordan. Ahora, eso es un producto extraño y no muy bueno en comparación con otras cosas en GitHub que son realmente buenas. Así que como parte de nuestro producto Spaces, estamos lanzando algo llamado owners, que es básicamente como los propietarios de código pero mejor. Así que échale un vistazo.

4. Making it Easy to Delete Code and Data Fetching

Short description:

Facilitar la eliminación de código es esencial para gestionar bases de código grandes. Alentar a los ingenieros a tener la menor cantidad de código posible, incluida la eliminación de código innecesario, nos permite mantener una aplicación más eficiente y escalable. El uso de herramientas como Tailwind o bibliotecas CSS-in-JS permite eliminar fácilmente el código, ya que el CSS está colocado junto con el código. De manera similar, la obtención de datos dentro de los componentes, como en Next.js 13, reduce el código innecesario y mejora el rendimiento. Este enfoque, a pesar de cierto escepticismo, se ha implementado con éxito en aplicaciones más grandes de Google, demostrando su escalabilidad y efectividad.

De acuerdo, para el segundo principio, lo llamo facilitar la eliminación de código. Porque hay una verdad sobre cualquier base de código grande, y es que se volverá más grande. Y eso, de alguna manera, es bueno, ¿verdad? Como nuestro trabajo es escribir código, vamos a escribir código, no hay nada que podamos hacer al respecto. Pero podemos, nuevamente, como líderes de plataforma, gestionar y alentar profesionalmente a nuestros ingenieros a agregar tener la menor cantidad de código posible, y eso incluye eliminar código.

Ahora, si todos pensamos en nuestras bases de código, probablemente haya algo así allí, ¿verdad? Hay algún código que obviamente no debería estar allí, ya saben, de 2017 o algo así. Y tal vez eso originalmente era un componente React y nos deshicimos de ese componente React, ¿verdad? Teníamos un archivo CSS que también contribuía a nuestro mensaje de Feliz Año Nuevo de 2017. ¿Y quién sabe si ese selector se puede eliminar, verdad? Eso realmente es casi un problema de detención, tipo de problema y así se queda por ahí. Por otro lado, si estás usando algo como Tailwind o CSS, como bibliotecas en JS, porque tienes la colocación del CSS junto con el código, puedes simplemente eliminar todo con alta confianza, deshacerte de ello. Y nuevamente, este es el tipo de pensamiento que debes tener como líder para decir que eso es por qué estoy tomando esta decisión de usar algo como Tailwind, porque realmente facilita la eliminación de código. Otro buen ejemplo de este tipo de pensamiento, creo, es la obtención de datos dentro de componentes en Next.js 13. Entonces, en este ejemplo, tenemos un componente Tweet, ¿verdad? Y solo pasamos el ID, el componente Tweet obtiene sus propios datos. Ahora, si eliminamos ese componente Tweet, todo desaparece. ¿Recuerdas cómo funcionaba esto en versiones anteriores de Next.js o algo así como cargadores de remix? La obtención de datos se eleva a la parte superior de la ruta. Entonces, si elimino algo que está muy abajo en mi árbol de renderizado de React, debo recordar también eliminar el código de obtención de datos. Y si tienes un equipo grande, algunos olvidarán algunas veces y no solo hará que tu aplicación sea más grande y tenga cosas innecesarias, sino que también la hará considerablemente más lenta. Entonces, para la obtención de datos, puedes introducir costos porque estás llamando a algún sistema backend que realmente no necesitas llamar. Nuevamente, es un poco la misma idea de CSS en JS, pero para la obtención de datos en JS. Y sé que algunos dicen, wow, eso no escala, blah, blah, blah. Uno de mis logros en Google del que estoy más orgulloso fue introducir exactamente esto. Entonces, cualquier aplicación grande de Google que hayas estado usando en los últimos ocho años más o menos está utilizando esta técnica donde la obtención de datos se realiza en el árbol de renderizado en lugar de obtener datos de alguna manera pseudoescalable en la parte superior.

5. Migración Incremental y Estándares de Aplicación

Short description:

Siempre migra de forma incremental. Planifica la migración incremental desde el principio. Utiliza el enrutador de aplicaciones Next.js13 como ejemplo. Migra una sola ruta a la vez. Un reconocimiento al equipo de Next.js. Principio número cuatro: siempre mejora y nunca empeores. Introduce reglas de lint para garantizar los estándares de la aplicación. Los comentarios pueden servir como un registro de deuda técnica.

De acuerdo. Principio número tres. Siempre migra de forma incremental. Estaba bromeando en Twitter el otro día diciendo que básicamente hay dos tipos de migraciones. Están las migraciones incrementales y las fallidas. Ahora, a veces comienzas con un gran plan y dices, como, vamos a hacer todo de una vez. Pero creo que más a menudo que no, tal vez llevas tres meses y tu jefe viene y dice que todo está bien, pero no podemos esperar seis meses más para demostrar que esto va a funcionar, necesito lanzar algo la próxima semana o el próximo mes, ¿verdad? Y así, algo que comenzó como potencialmente, ya sabes, una migración de tipo big bang, típicamente eventualmente se convierte en algo que haces incrementalmente, por lo que es mejor planificarlo desde el principio. Es solo un ejemplo de, ya sabes, el tipo de pensamiento que se necesita en el diseño de API para hacer posible la migración incremental. Creo que otro buen ejemplo es una vez más el enrutador de aplicaciones Next.js13 donde puedes ir y migrar una sola ruta a la vez, levantándola y trasladándola al nuevo mundo, ¿verdad? Nadie te obliga a decir, API antigua o API nueva, puedes tener esa página en esta API, esta página en esa API, y trabajarla a través del código. Y aún más abajo en ese proyecto, ya sabes, aquí tenemos algo como obtener servicio en props, legado. ¿Debería decir legado? No sé. Lo que sea. API antigua, ¿verdad? Que perfectamente puedes seguir usando. Pero, ya sabes, así es como se veía y luego puedes hacer el primer paso de migración. Ten en cuenta que esta es una migración trivial. ¿Verdad? Nada realmente cambió. Simplemente tomamos ese código que estaba en obtener servicio en props y lo colocamos en nuestro componente de nivel superior. Ahora, ¿es mejor que antes? No, no lo es. ¿Verdad? Pero es un paso incremental. Donde no tuviste que reescribir todo tu árbol de renderizado para aprovechar algunas de las nuevas capacidades. Y nuevamente, solo un ejemplo de cómo hacer APIs que se puedan migrar de forma gradual en lugar de hacer todo de una vez. Y obviamente, un reconocimiento al equipo de Next.js que hizo un buen trabajo en esto, creo. Genial. Pasando al principio número cuatro. Que es siempre mejorar y nunca empeorar. Esto en realidad, de alguna manera, está relacionado con el tema de la migración incremental, pero un poco más general. Un buen ejemplo de cómo asegurarte de que tu aplicación tenga ciertos estándares sería introducir reglas de lint, ¿verdad? Que digan, en mi aplicación debes hacerlo de esta manera, no de otra manera. Ahora, a veces sucede algo que no es tan bueno, algo como esto, que por cierto copié y pegué al azar desde la supersecreta base de código interna de Brasel, así que lamento si hay algo interesante ahí. Las partes realmente interesantes son los comentarios, que básicamente deshabilitan las reglas de lint en todas partes, ¿verdad? Y en realidad creo que eso es bueno. Hablaré sobre por qué esta es la forma correcta de hacerlo, pero obviamente es molesto llenar tu base de código con estos comentarios que no agregan valor, ¿verdad? Pero de alguna manera, estos comentarios son ahora este registro de deuda técnica, ¿verdad? La deuda técnica suele ser algo muy abstracto.

6. Listas de Permitidos y Abrazar la Falta de Conocimiento

Short description:

Para nuestro producto Spaces, utilizamos listas de permitidos externas para evitar ensuciar la base de código. El valor de las reglas es mayor en el código nuevo. Abraza la falta de conocimiento y codifica la información de la base de código de manera legible por máquina. Ejemplo: el middleware de Next.js y el uso de listas de permitidos para garantizar la aprobación de cambios específicos de contexto.

Pero aquí tienes una lista. Una lista de tareas de cosas que quieres arreglar. Ahora, nuevamente, esto es un poco desagradable para tu base de código, por eso para nuestro producto Spaces lo que estamos utilizando son estas listas de permitidos externas que no ensucian tu base de código. Básicamente tienes un archivo JSON que dice que hay algunas reglas aquí, y en este archivo está bien violar las reglas.

Ahora, volviendo al tema de mejorar y no empeorar, lo que realmente quieres ver para la base de código de tu equipo es un gráfico como este. Estas son violaciones a lo largo del tiempo. Quieres que esto disminuya con el tiempo y luego ves estos incrementos. Eso en realidad no es malo, eso es cuando introduces una nueva regla. Permites todas las violaciones existentes y luego, a medida que este código realmente se toca, mejora con el tiempo. Quiero animar a todos a permitir esto. En realidad, no es importante migrar todo y ponerlo en el nuevo estado. La razón es que, y esto en realidad no era obvio para mí al principio de mi career en absoluto, es que si tienes una regla sobre tu aplicación, el valor marginal de esa regla es drásticamente mayor en el código nuevo que en el código antiguo, porque tu código antiguo ha sido probado en batalla. Pasó por pruebas de calidad, pasó por interrupciones en producción, pasó por usuarios que tenían ideas creativas sobre lo que es un nombre. Ya arreglaste todas estas cosas, ¿verdad? Y es probable que en realidad no encuentres nada interesante. La razón por la que existen estas reglas es que cuando escribes algo nuevo, en ese momento te dice, hey, estás cometiendo un error, arréglalo ahora, ¿verdad? Donde también es realmente barato hacerlo. Y por eso es tan importante incorporar rápidamente estas opiniones en tu base de código para el código futuro, y no es importante ahora dedicar un mes de tu vida para migrar todo lo que ya tienes a un nuevo estado.

Así que hablé un poco de manera abstracta sobre reglas como esta, y di este ejemplo de regla de lint, pero en realidad creo que quiero hablar de algo un poco más alto nivel que una regla de lint, que está asociado con el estilo de código y cosas así. Llegando al principio, ya sabes, abraza la falta de conocimiento. Nuevamente, eres el líder de este equipo más grande, habrá personas nuevas en tu equipo, habrá personas más junior, tendrán algún contexto sobre esa base de código que les falta, que no pueden conocer o que se perdieron, ¿sabes, o donde no leyeron el memo, ¿verdad? Todo esto sucede. Y nosotros, como líderes de ese equipo, tenemos que aceptar que es posible que no tengan ese contexto. Y por eso es importante tratar de codificar tantas de estas cosas que sabes sobre tu base de código de alguna manera legible por máquina. Tengo aquí un ejemplo de lo que eso significa. Y nuevamente, esto va mucho más allá del linting, sino más bien a opiniones de diseño de aplicaciones. Esta regla, nuevamente, tomada de nuestra base de código interna. Y así utilizamos el middleware de Next.js que es una herramienta muy poderosa, ¿verdad? Se ejecuta en casi todas las solicitudes que servimos. Y eso significa que si nuestro middleware es lento, nuestro sitio será muy lento, ¿verdad? Y una forma de hacer que tu middleware sea realmente lento es al obtener algo de algún otro servicio, ¿verdad? Por otro lado, obtener algo de algún otro servicio podría ser exactamente lo que quieres hacer, ¿verdad? Porque así es como haces cosas interesantes, como llamar a servicios. Ahora, lo que significa que sí, a veces tienes que llamar a un servicio, pero no, a veces no es la idea correcta, ¿verdad? Y así, con un mecanismo de lista de permitidos como este, lo que puedes hacer es decir que, de forma predeterminada, hacer este cambio requiere la aprobación de alguien que realmente tenga el contexto para tomar la decisión de si en este contexto es la idea correcta. Y esto combina este concepto de una lista de permitidos externa al código junto con el mecanismo de propietarios que tenemos, donde el propietario de la lista de permitidos no es la misma persona que está escribiendo el código, y respectivamente, puedes hacer cumplir fácilmente que tu arquitecto o, ya sabes, el líder del equipo de la plataforma, revise y valide que en este caso sí, es un uso adecuado. Y luego, nuevamente, esto no es como la regla de lint donde probablemente eventualmente quieras tener una base de código y un código uniforme. Aquí, solo te aseguras de que sí, echamos un vistazo y esto es realmente lo que queremos hacer.

7. Eliminando la Complejidad Sistemática

Short description:

Eliminar la complejidad sistemática es crucial para construir aplicaciones escalables. Un problema común es la discrepancia de versiones en sistemas distribuidos, donde el cliente y el servidor no están en la misma versión. Esto puede causar problemas al introducir nuevos campos en la API. Para abordar esto, herramientas como la biblioteca Zot y la capa TRPC proporcionan soluciones, pero pueden ser complejas. En Vercel, hemos introducido un producto sin servidor que sirve diferentes versiones del sitio, asegurando que el cliente y el servidor siempre estén sincronizados. Esto elimina por completo el problema y facilita la construcción de aplicaciones a gran escala.

Genial. Pasando al último principio aquí, eliminando la complejidad sistemática. Una vez más, eres la persona que lidera el equipo de plataforma para tu organización y estás viendo cosas con las que la gente lucha. De vez en cuando, creo que es importante dar un paso atrás y hacer un catálogo de estas cosas con las que la gente lucha todo el tiempo y tratar de deshacerse de ese problema de una vez por todas mediante la introducción de algún tipo de abstracción que permita simplemente no preocuparse más por ello.

Un buen ejemplo de este tipo de problema es lo que, al menos en la jerga técnica, se llama discrepancia de versiones. La discrepancia de versiones es algo que ocurre en sistemas distribuidos cuando tienes un cliente y un servidor, y no están en la misma versión, ¿verdad? Ahora, podrías decir, sabes, soy un ingeniero de front-end, no escribo sistemas distribuidos, y estarías equivocado. En realidad, estás haciendo el modo difícil, ¿verdad? Porque en un centro de datos, controlas cómo se implementan las cosas, ¿verdad? Sabes cómo funciona eso. Puedes establecer reglas al respecto. Por otro lado, cuando tienes un cliente web y un servidor, ya sabes, no tienes control sobre cuándo se implementa ese cliente web, ¿verdad? Así que, va a tu sitio y puede quedarse, ¿verdad? Ciertamente, durante un tiempo. Mientras tanto, vuelves a implementar tu servidor. Ahora tienes este cliente antiguo, nuevo servidor, e introduces un nuevo campo en tu API, ¡y el cliente no tiene ni idea, ¿verdad? Y así, este es un problema que ahora tienes que gestionar.

Ahora, casi hay todo un ecosistema en torno a esto. Por ejemplo, la biblioteca Zot para TypeScript o la capa TRPC sobre ella, que permite expresar expectativas sobre tus APIs y manejar el problema si esas expectativas no se cumplen. Pero eso es mucha complejidad, ¿verdad? Hay muchas cosas que tienes que hacer. ¿Y qué haces si no obtienes el campo, ¿verdad? ¿Qué haces realmente? Es un problema difícil. Así que, veíamos este problema en Vercel y nos preguntábamos, ¿podemos, de nuevo, eliminar todo el problema sistemático? Y así fue como dijimos, tenemos este producto serverless, ¿verdad? Y no tenemos un servidor con la última versión. Podemos servir otras versiones de tu sitio además de la última implementación. Y así, lo que tenemos ahora es una versión muy experimental, pero la estamos implementando durante las próximas semanas, es que puedes optar por un modo en Next.js donde el servidor que responde a tu cliente siempre será exactamente la versión en la que estaba el cliente, lo que significa que puedes olvidarte por completo de todo este problema. Nunca más tendrás que preocuparte por ello. En particular, con las acciones del servidor, que ya son como llamadas a funciones, realmente son llamadas a funciones ahora, porque realmente sabes qué funciones estás llamando, ¿verdad? No es como una versión abstracta de algo llamado así, pero no sabes cuál. Será exactamente eso. Y así, una vez más, este es solo un ejemplo de las cosas que puedes hacer para facilitar la construcción de aplicaciones a gran escala.

Increíble. Eso es todo lo que tengo hoy. Esta es toda la lista. No tengo que repasarla de nuevo. Creo que tenemos preguntas y respuestas. Tal vez sea útil con preguntas y cosas así. Muchas gracias. Tenemos tiempo para una o dos preguntas, así que empecemos de inmediato.

8. Automatización de la Migración de Código y Eliminación de Barreras

Short description:

La automatización de la migración de código utilizando AST puede ser beneficiosa, incluso al realizar cambios a gran escala. El robot de Google, Rosy, automatiza el proceso convirtiendo un cambio de 15,000 líneas en múltiples cambios de una línea, aplicados incrementalmente para evitar posibles errores. Este enfoque elimina barreras y permite una migración de código más fluida.

Hay una pregunta aquí que encuentro realmente interesante, pero quiero expandir un poco sobre ella. La pregunta es, mencionaste que siempre es mejor migrar incrementalmente, pero ¿qué hay de usar AST para migrar automáticamente grandes cantidades de código? Y sobre eso, hablar un poco sobre cuándo vale la pena automatizar las cosas. ¿Es beneficioso? ¿Es una distracción? No, definitivamente vale la pena automatizar las cosas. Incluso si automatizas un cambio, seguiría aplicando el principio. En Google, hay un robot llamado Rosy, y tomará tu cambio de 15,000 líneas y lo convertirá en 15,000 cambios de una línea y lo aplicará a tu base de código de manera incremental para que no tengas que decir eventualmente, oh mierda, cometí un error, y tienes que revertir el cambio de 15,000 líneas. Se aplica de manera recursiva. Eso es realmente genial. Elimina las barreras, Google. Tema relevante, por supuesto, para las cosas de Roussell, ¿cuáles son tus pensamientos sobre los componentes del servidor? ¿Es el futuro, etc.? ¿Cuáles son mis pensamientos sobre los componentes del servidor? Son el futuro. Lo que realmente me emociona son las acciones del servidor. Me emociona que el cliente y el servidor crezcan juntos. De alguna manera, esto se siente natural y sin problemas, como un solo mundo en lugar de dos mundos. Y la última pregunta es para mí, ¿cuál fue el séptimo principio? ¿Podemos volver atrás? El séptimo principio se trataba de cómo introducir cambios en las organizaciones asegurándose de que cuando realmente tienes una nueva idea, como este problema de versiones, no vienes desde tu torre de marfil y dices que esto es lo que están usando ahora, sino que tienes un cliente cero que lo prueba, luego tienes un cliente uno que lo prueba por sí mismos pero aún tiene tu ayuda, y luego tienes un cliente dos que intenta hacerlo solo con sus perros, y así sucesivamente. Bueno, muchas gracias por su tiempo. Malte estará en los stands de los oradores en la parte de atrás si tienen más preguntas o simplemente quieren tener tiempo a solas. Gracias de nuevo. Increíble, muchas gracias.

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

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Featured WorkshopFree
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up