Principios para el Desarrollo de Aplicaciones Frontend a Escala

¿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.

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.

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.

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.

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.

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.

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.

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.