Principios para Escalar el Desarrollo de Aplicaciones Frontend

Rate this content
Bookmark

Después de pasar más de una década en Google, y ahora como el 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 guía para liderar una gran infraestructura de software.

Malte Ubl
Malte Ubl
26 min
02 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla discute la escalada de aplicaciones front-end 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, la aceptación de la falta de conocimiento y la eliminación de 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 está todo el mundo? Esta es realmente mi primera conferencia, de vuelta de un descanso. Solía construir grandes aplicaciones en JavaScript, 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 producto para resolver problemas comunes. Anunciamos Versell Spaces para implementar los conceptos discutidos.

¿Cómo está todo el mundo? Sí, gracias por hablar de JSConf y esas cosas. Tomamos la sabia decisión de no tener un evento en 2010 porque de todos modos no habría ocurrido, esta es realmente mi primera conferencia, al menos si cuentas las conferencias de la community, de vuelta de este gran descanso en la vida de todos. Vengo de San Francisco. En realidad estaba en Alemania antes, todavía un poco desfasado por el jet lag 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 muy grandes en JavaScript. Todavía estaba en Google en ese momento y estaba asumiendo una especie de rol ejecutivo. Así que en realidad no estaba construyendo cosas yo mismo, pero aprendí algunas cosas y así que pensé que sería una buena idea dar una charla sobre ello. Pero eso fue entonces. He vuelto. De hecho, he vuelto a construir cosas en JavaScript, aplicaciones muy grandes. Obviamente, nadie hoy en día realmente hace eso. Son aplicaciones de TypeScript y aquí estamos.

Otra diapositiva de esa charla fue que pensaba que React era bueno. Y el contexto allí era que hace diez años, construí un framework de JavaScript en Google llamado Wiz y estaba pensando en si abrirlo al público o no y justo en ese momento, sale React y parece realmente bueno y pienso que el mundo no necesita esto. Voy a guardarlo para nosotros. Creo ahora que fue un poco un error porque hubo algunas buenas contribuciones en torno a la scalability de las aplicaciones que podrían haber sido realmente valiosas para el ecosystem incluso si solo se hubieran mostrado. Pero ahora que estoy en Brasil, puedo ayudar un poco a impulsar React y creo que con las cosas en torno a los componentes del servidor, etc., algunas de esta situación que pensamos en Google en su día, ha vuelto y ahora está disponible para todos, lo cual es increíble. Genial. Muy bien.

Así que me uní a Brasil, hablé con todos los equipos y descubrí que tenemos un equipo interno de Dex. Y entonces hablé con ellos, sabes, ¿qué estáis haciendo? Me explicaron lo que estaban haciendo. Creo que parece una muy buena idea. Y luego hablo con los clientes. nuestros clientes me están diciendo 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 producto y realmente lo hacemos disponible para todos para que no todos tengan que ir una y otra vez, resolviendo los mismos problemas. Ahora, esto es de alguna manera relevante porque la charla que di en su día, era tan teórica, porque, ya sabes, no tenía nada de código abierto. Solo podía decir a la gente, esto es lo que he aprendido. Pero tienes que averiguar cómo convertir este aprendizaje en 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. Escalando Aplicaciones Front-end

Short description:

Así que vamos a enviar 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 hacemos software, vamos a cometer errores con el tiempo, y tenemos que lidiar con ese hecho de manera profesional. El resto de esta charla es 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 que hacen que todo el equipo sea mejor. Quiero hablar sobre los principios para escalar aplicaciones front-end. Tengo seis. Comencemos con este: derribando las barreras.

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

Como ciertamente, no tenemos, ya sabes, dinero infinito, tú no tienes dinero infinito. Creo que Google ya no tiene dinero infinito. Así que eso no es realmente, no es un buen mantra. Pero creo que esto es realmente cierto, la velocidad de iteración resuelve todos los problemas conocidos. Lo que quiero decir es que cuando hacemos software, y de hecho la primera charla de hoy tenía un punto similar, vamos a cometer errores con el tiempo, ¿verdad? Lo único que sabemos es 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. Así que con eso, pensemos un poco en nuestro papel en esto, y para el resto de esta charla.

Así que el ingeniero senior, o realmente lo que quiero decir es como el ingeniero senior en minúsculas, ¿verdad? Hemos estado alrededor por un poco. ¿Qué hacemos, verdad? Puede que haya, hay una sesión más tarde hoy alrededor de career advice, y pueden decirte algo como, ya sabes, si quieres tener más impacto, necesitas scale más allá de ti mismo, y lo que la gente suele asociar 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 una cosa de personas, ¿verdad? Y así que el resto de esta charla es sobre algo muy diferente a eso. Se trata de cómo puedes scale 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 que hacen que todo el equipo sea mejor, pero a través del software que estás construyendo. Y así que para el resto de estas diapositivas, básicamente, considérate como el líder hipotético del equipo de plataforma hipotético para tu equipo de ingeniería hipotético, no sé, 12, 50, 100 personas, ¿verdad? Eres esa persona y tu trabajo es hacer que ese equipo scale mejor. Genial. Esa fue una larga introducción. De todos modos, quiero hablar sobre los principios para scaling aplicaciones front-end. Tengo seis. Tengo uno extra, pero creo que soy demasiado lento. Así que haré seis. Muy bien. Comencemos con este. Derribando las barreras. Así que esto es realmente algo que no estaba claro para mí cuán grande sería el efecto que tendría. 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. Yo iba a estos meetups yo mismo y escuchaba a la gente en el escenario estar increíblemente emocionada por los pequeños modules, ¿verdad? Y había una empresa llamada NPM, Shouter NPM, que creó algo llamado modules privados.

3. Compartiendo Código y Monorepo

Short description:

Si quieres obtener esa inyección de adrenalina en el brazo, migra a un monorepo. Realmente vale la pena. Fomenta la colaboración y pone una barrera baja a la colaboración. Los propietarios de código de GitHub abordan problemas de escalabilidad. Como parte de nuestro producto de espacios, estamos lanzando algo llamado propietarios, que es básicamente como propietarios de código pero bueno.

Y así la gente iría y en su empresa compartiría code a través de la publicación de modules a NPM. Así que me uno a VerCell y veo que eso sucede donde como algún equipo dice bueno, tienes algo de code genial, ¿puedes publicarlo en NPM para que pueda usarlo? Y luego tengo que actualizar mi paquete JSON a tu nueva versión. Tal vez alguien me está ayudando, tal vez estoy haciendo esto automáticamente. Es un proceso increíblemente malo y a scale si tienes un equipo más grande realmente duele. Así que mi consejo de truco extraño, si aún no lo has hecho y quieres obtener esa inyección de adrenalina en el brazo, migra a un monorepo. Realmente vale la pena. Ahora obviamente viene con un compromiso. Todo en la ingeniería de software viene con un compromiso. Unos meses después te darás cuenta, oh, todos pueden cambiar todo, tal vez eso no sea la mejor idea en el planeta. Pero es bueno tener una base que fomente y ponga una barrera baja a la colaboración y puedes lidiar con los problemas que vienen en el camino. Y hay ciertos problemas de scalability que, por ejemplo, los propietarios de code de GitHub abordan. Ahora eso es un producto extrañamente no muy bueno entre las otras cosas en GitHub que son realmente buenas. Así que como parte de nuestro producto de espacios, en realidad estamos lanzando algo llamado propietarios, que es básicamente como propietarios de code pero bueno. Así que échale un vistazo.

4. Facilitando la Eliminación de Código y la Obtención de Datos

Short description:

Facilitar la eliminación de código es esencial en la gestión de grandes bases de código. Alentando a los ingenieros a tener la menor cantidad de código posible, incluyendo la eliminación de código innecesario, podemos mantener una aplicación más eficiente y escalable. El uso de herramientas como Tailwind o bibliotecas CSS-en-JS permite una fácil eliminación de código, ya que el CSS está colocado 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, ha sido implementado con éxito en aplicaciones de Google más grandes, demostrando su escalabilidad y eficacia.

Bien, para el segundo principio, lo llamo facilitar la eliminación de code. Porque hay una cosa cierta sobre cualquier gran base de code, es que se hará más grande. Y eso es de alguna manera bueno, ¿verdad?, es nuestro trabajo escribir code, vamos a escribir code, no hay nada que puedas hacer al respecto. Pero podemos, de nuevo, como líderes de la plataforma, gestionar profesionalmente y alentar a nuestros ingenieros a tener la menor cantidad de code posible y eso incluye eliminar code.

Ahora, si todos pensamos en nuestras bases de code, probablemente haya algo como esto en ellas, ¿verdad? Hay algo de code que obviamente no debería estar ahí, ya sabes, 2017 o lo que sea. Y tal vez eso era originalmente un componente de React y nos deshicimos de ese componente de React, ¿verdad? Teníamos un archivo CSS que también contribuía a nuestro mensaje de Feliz Año Nuevo 2017. Y quién sabe si ese selector puede ser eliminado, ¿verdad? Eso es realmente como casi un problema de tipo halting, y por lo tanto se queda por ahí. Ahora, por otro lado, si estás usando algo como Tailwind o CSS, como en las bibliotecas JS, porque tienes la colocación del CSS con el code, puedes simplemente eliminar todo el conjunto con alta confianza, deshacerte de él. Y de nuevo, este es el tipo de pensamiento que deberías tener como líder para decir que es por eso por lo que estoy tomando la decisión de usar algo como Tailwind, porque en realidad hace que sea más fácil eliminar code. Como otro buen ejemplo de este tipo de pensamiento, creo que es la obtención de data dentro de los 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 data. Ahora, si eliminamos ese componente Tweet, todo se ha ido. ¿Recuerdas cómo funcionaba esto en el legado en Next.js o algo como los cargadores de remix? La obtención de data se eleva a la parte superior de la ruta. Entonces, si elimino algo que está muy abajo en mi árbol de renderizado de React, tengo que recordar también eliminar el code de obtención de data. Y si tienes un equipo grande, algunos olvidarán algunas veces y no solo hará que tu aplicación sea un poco más grande y tenga cosas innecesarias en ella, sino que también la hará sustancialmente más lenta. Entonces, para la obtención de data, puedes introducir costos porque estás llamando a un sistema de backend que realmente no tienes que llamar. Entonces, de nuevo, es la misma idea de CSS en JS, solo que para la obtención de data en JS. Y sé que algunas personas dicen, vaya, eso no scale, blah, blah, blah. Uno de mis, creo, logros en Google de los que estoy más orgulloso fue introducir exactamente esto. Así que cualquier aplicación de Google más grande que hayas estado usando durante los últimos ocho años o así está usando esta técnica donde tienes la obtención de data en el árbol de renderizado en lugar de la obtención de data en alguna forma pseudo-escalable elevada.

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

Short description:

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

Muy bien. Principio número tres. Siempre migra de manera incremental. Estaba bromeando en Twitter el otro día que básicamente solo hay dos tipos de migraciones. Las incrementales y las fallidas. Ahora, a veces empiezas con un gran plan y vas a decir, como, vamos a hacer todo esto de una vez. Pero creo que más a menudo que no, quizás estás tres meses adentro y tu jefe viene y dice que todo está bien y bueno, pero no podemos esperar seis meses más para demostrar que esto va a funcionar, necesito enviar algo la próxima semana o el próximo mes, ¿verdad? Y entonces, algo que comenzó como una migración de tipo big bang típicamente eventualmente comienza a convertirse en algo que haces de manera incremental y por lo tanto es idealmente mejor planificarlo desde el principio. Es solo un ejemplo para, ya sabes, el tipo de pensamiento que se necesita para diseñar una API design para hacer posible la migración incremental. Creo que otro buen ejemplo es una vez más el enrutador de la aplicación Next.js13 donde puedes ir y migrar una sola ruta a la vez, levantándola y cambiándola al nuevo mundo, ¿verdad? Así que nadie te está obligando a decir, antigua API o nueva API, puedes tener esa página en esta API, esta página en esa API, y trabajar a través del código. Y aún más abajo en ese proyecto, ya sabes, aquí tenemos algo como get service at props, legacy. ¿Debería decir legacy? No lo sé. Lo que sea. Antigua API, ¿verdad? Que todavía puedes usar perfectamente. Pero, ya sabes, así es como se veía y luego puedes hacer el primer paso de migración. Nota que esta es una migración trivial. ¿Verdad? Realmente nada cambió. Solo tomamos ese code que estaba en get service at props y lo pusimos en nuestro componente de nivel superior. ¿Es eso 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 de nuevo, solo un ejemplo de cómo hacer APIs que puedes migrar en este paso a paso en lugar de hacer todo de una vez. Y obviamente, felicitaciones al equipo de Next.js que realmente hizo un buen trabajo en esto, creo. Genial. Pasando al principio número cuatro. Que siempre está mejorando y nunca empeorando. Esto es en realidad, de alguna manera, relacionado con el tema de la migración incremental, pero un poco más general. Entonces, un buen ejemplo de cómo asegurarte de que tu aplicación tiene un cierto estándar sería introduciendo reglas de lint, ¿verdad? Que dicen, ya sabes, en mi aplicación tienes que hacerlo de esta manera, no de la otra. Ahora, lo que a veces sucede, que no es tan genial, algo como esto, que por cierto acabo de copiar y pegar al azar de la base de code super secreta interna de Brasel, así que lo siento si hay algo interesante allí. Las partes realmente interesantes son los comentarios, que básicamente desactivan las reglas de lint en todas partes, ¿verdad? Y en realidad creo que eso está bien. Hablaré de por qué esta es la forma correcta de hacerlo, pero obviamente es una lata llenar tu base de code con estos comentarios, que no aportan valor, ¿verdad? Pero de alguna manera, estos comentarios son ahora este registro de deuda técnica, ¿verdad? La deuda técnica generalmente es algo super abstracto.

6. Listas de Permitidos y Aceptación de 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 nuevo código. Acepta la falta de conocimiento y codifica la información de la base de código de manera legible por máquina. Ejemplo: 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 cosas que quieres arreglar. Ahora, de nuevo, esto es desagradable para tu code base, por lo que para nuestro producto Spaces estamos utilizando estas listas de permitidos externas que no ensucian tu code base. 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 code base de tu equipo es un gráfico como este. Estas son las violaciones con el tiempo. Quieres que esto disminuya con el tiempo y luego ves estos escalones hacia arriba. Eso en realidad no está mal, eso es cuando introduces una nueva regla. Permites todas las violaciones existentes y luego, a medida que este code realmente se toca, mejora con el tiempo. Quiero animar a todos a permitir esto. No es realmente importante migrar todo y ponerlo en el nuevo estado. La razón es que, y esto es algo que no me resultaba obvio al principio de mi career en absoluto, que si tienes algo como una regla sobre tu aplicación, el valor marginal de esa regla es drásticamente mayor en el nuevo code que en el antiguo code, porque tu antiguo code ha sido probado en batalla. Pasó por QA, pasó por interrupciones de producción, pasó por usuarios teniendo ideas creativas sobre qué es un nombre. Ya arreglaste todas estas cosas, ¿verdad? Y por lo tanto, 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 de inmediato, hey, estás cometiendo un error, ve a arreglarlo ahora, ¿verdad? Donde también es realmente barato hacerlo. Y por eso es tan importante incorporar rápidamente estas opiniones en tu code base para el futuro code, y no es importante ahora tomar un mes de tu vida para migrar todo lo que ya tienes a un nuevo estado.

Así que hablé un poco en términos abstractos 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á asociada con el estilo de code y cosas así. Llegando al principio, ya sabes, acepta la falta de conocimiento. De nuevo, eres el líder de este equipo más grande, va a haber personas que son nuevas en tu equipo, va a haber personas que son más junior, van a tener algún contexto sobre esa code base que les falta, que no pueden saber o que perdieron, ya 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 intentar codificar tantas de estas cosas que sabes sobre tu code base de alguna manera legible por máquina. Tengo un ejemplo aquí de lo que eso significa. Y de nuevo, esto va más allá del linting pero más hacia las opiniones de diseño de aplicación. Esta regla, de nuevo, tomada de nuestra code base interna. Y así usamos el middleware de Next.js que es una herramienta muy poderosa, ¿verdad? Se ejecuta en casi todas las solicitudes que estamos sirviendo. Y eso significa que si nuestro middleware es lento, nuestro sitio va a ser muy lento, ¿verdad? Y una forma de hacer que tu middleware sea realmente lento es obteniendo 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, por defecto, hacer este cambio requiere la aprobación de alguien que realmente tiene el contexto para tomar la decisión de si en este contexto esta es la idea correcta. Y esto combina la idea de una lista de permitidos externa al code junto con el mecanismo de propietarios que tenemos, donde el propietario de la lista de permitidos no es el mismo persona que está escribiendo el code, y respectivamente, puedes hacer cumplir fácilmente que tu arquitecto o, ya sabes, líder del equipo de plataforma tipo de persona para echar un segundo vistazo y validar que en este caso sí, es un uso OK. Y luego, de nuevo, esto no es como la regla de lint donde eventualmente probablemente quieres tener una code base y una code base uniforme. Aquí, simplemente 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 en la construcción de aplicaciones escalables. Un problema común es la desviación 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, introdujimos un producto sin servidor que sirve diferentes versiones del sitio, asegurando que el cliente y el servidor siempre estén sincronizados. Esto elimina el problema por completo y facilita la construcción de aplicaciones a 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 qué son estas cosas con las que la gente, como, lucha todo el tiempo e intentar deshacerse de ese problema de una vez por todas al introducir algún tipo de abstracción que lo haga posible simplemente no preocuparse más por ello.

Un, creo, buen ejemplo para este tipo de problema es lo que, al menos en big tag, se llama desviación de versiones. Así que la desviación 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 estás equivocado. Como, estás haciendo el modo difícil, ¿verdad? Como, porque en un data center, controlas cómo se despliegan las cosas, ¿verdad? Sabes cómo funciona eso. Puedes poner reglas alrededor de eso. Por otro lado, cuando tienes un cliente web y un servidor, sabes, no estás en control de cuándo se vuelve a desplegar ese cliente web, ¿verdad? Así que, va a tu sitio, y podrían quedarse, ¿verdad? Ciertamente, por un tiempo. Mientras tanto, vuelves a desplegar tu servidor. Así que ahora, tienes este viejo cliente, nuevo servidor, y estás introduciendo un nuevo campo en tu API, y el cliente no tiene idea, ¿verdad? Y así, este es un problema que ahora tienes que gestionar.

Ahora, hay casi como un entero ecosystem alrededor de esto. Como por ejemplo, la biblioteca Zot para TypeScript o la capa TRPC encima de ella, que permite expresar expectativas alrededor de 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. Y así, estábamos viendo este problema en Vercel, y nos preguntábamos, ¿podemos, de nuevo, eliminar todo el problema sistemático? Y así que lo que hicimos fue decir, oye, tenemos este producto serverless, ¿verdad? Y no tenemos un servidor con la última versión. En realidad podemos servir otras versiones de tu sitio que no sean la última implementación. Y así, lo que tenemos ahora es una versión muy experimental, pero la estaremos 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 misma versión que el cliente tenía, lo que significa que puedes olvidarte de todo este problema por completo. Nunca más tendrás que preocuparte por ello. En particular, con las acciones del servidor, que ya son como llamadas a funciones, son realmente como 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. Va a ser exactamente eso. Y de nuevo, esto es solo un ejemplo del tipo de cosas que puedes hacer para facilitar la construcción de aplicaciones a scale.

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 quizás una o dos preguntas, así que vamos directo a ello.

8. Automatizando la Migración de Código y Eliminando Barreras

Short description:

La automatización de la migración de código utilizando ASTs 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 de manera incremental para evitar posibles errores. Este enfoque elimina barreras y permite una migración de código más fluida.

Hay una pregunta aquí que me parece realmente interesante, pero quiero expandirla un poco. La pregunta es, mencionaste que siempre debemos migrar de manera incremental, pero ¿qué pasa con el uso de ASTs para migrar automáticamente grandes cantidades de code? Y a eso, hablemos 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, todavía aplicaría 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 gestionará su aplicación en tu base de code 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. Topical, por supuesto, para las cosas de Roussell es ¿cuáles son tus pensamientos sobre los componentes del servidor? ¿Es el futuro, etcétera? ¿Cuáles son mis pensamientos sobre los componentes del servidor? Son el futuro. Lo que realmente me emociona son las acciones del servidor. Estoy emocionado por el crecimiento conjunto del cliente y el servidor. De alguna manera, esto se siente natural y sin fisuras y, como, un mundo en lugar de dos mundos. Y la última pregunta es para mí, que es ¿cuál era el séptimo principio? ¿Podemos volver atrás? El séptimo principio giraba en torno a cómo introducir cambios en las organizaciones asegurándose de que cuando realmente tienes una nueva idea, como esta versión skew stuff, no vengas desde tu torre de marfil y digas esto es lo que estás usando ahora, sino que tienes un cliente cero que lo prueba, luego tienes un cliente uno que lo prueba por sí mismo pero todavía tiene tu ayuda, y luego tienes un cliente dos que intenta hacerlo solo con sus perros, y así sucesivamente. Bueno, muchas gracias por tu tiempo. Malte estará en los stands de los oradores en la parte de atrás si tienes más preguntas o simplemente quieres tener un poco de tiempo uno a uno. Gracias de nuevo. Genial, 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

Don't Solve Problems, Eliminate Them
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.
Using useEffect Effectively
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.
Design Systems: Walking the Line Between Flexibility and Consistency
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 Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
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
TypeScript and React: Secrets of a Happy Marriage
React Advanced Conference 2022React Advanced Conference 2022
21 min
TypeScript and React: Secrets of a Happy Marriage
Top Content
TypeScript and React are inseparable. What's the secret to their successful union? Quite a lot of surprisingly strange code. Learn why useRef always feels weird, how to wrangle generics in custom hooks, and how union types can transform your components.
A Framework for Managing Technical Debt
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top Content
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 Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
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 Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
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.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
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 at Scale with Nx
React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Top Content
Featured WorkshopFree
Isaac Mann
Isaac Mann
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
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- 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