Principios para Escalar el Desarrollo de Aplicaciones Frontend

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

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.

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.

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.

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.

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.

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.

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.