Construyendo una Base de Código Sostenible con FP

Rate this content
Bookmark

Como ingenieros de software siempre estamos tratando de ser más productivos, de entregar un código mejor y de tener una retroalimentación de desarrollo más rápida. En esta charla, exploraremos cómo la programación funcional, las pruebas y la arquitectura hexagonal pueden funcionar muy bien juntas para apoyar una base de código mantenible para cientos de ingenieros y servicios. Profundizaremos en cómo podemos aprovechar la arquitectura hexagonal con el rechazo de dependencias para desacoplar las decisiones de los efectos, lo que resulta en un código más fácil de razonar, componer y probar. La base de código no es la única que se beneficia de esto, sino también los desarrolladores. Ayuda a que todos se sientan más cómodos y comprometidos con el mantenimiento de buenas prácticas.

20 min
20 Jun, 2022

Video Summary and Transcription

La charla de hoy se centra en la construcción de una arquitectura sostenible a través de la programación funcional, las pruebas y la arquitectura hexagonal. Se enfatiza la importancia de maximizar la programación funcional y la inmutabilidad para mejorar la calidad y mantenibilidad del código. La charla también destaca la importancia de las pruebas para la precisión y velocidad, y discute los beneficios de la arquitectura hexagonal en la separación de la lógica de negocio de las preocupaciones técnicas. Se explora el concepto de aislamiento y encapsulación en la programación funcional, junto con las ventajas de usar funciones puras. En general, la charla proporciona ideas sobre el diseño e implementación de una base de código sostenible y eficiente.

Available in English

1. Introducción a la Arquitectura Sostenible

Short description:

Hoy estoy aquí para hablar sobre cómo puedes construir una arquitectura sostenible. Los temas principales son la programación funcional, las pruebas y la arquitectura hexagonal. La programación funcional se trata de funciones puras, pero también necesitamos lidiar con funciones impuras y efectos secundarios. Necesitamos estructurar cuidadosamente nuestra base de datos para no interferir con ella.

Hoy estoy aquí para hablar sobre cómo puedes construir una arquitectura sostenible. Primero, me voy a presentar. Mi nombre es Karolina Pascal Campos. Soy de Brasil. Soy una ingeniera de software que trabaja en Briza. Y aquí puedes seguirme en mis redes sociales. Y me encantan los libros, el café y correr. Así que vamos a la presentación ahora.

Los temas principales de los que voy a hablar hoy son la programación funcional, las pruebas y la arquitectura hexagonal. Así que empecemos con la programación funcional. Sabemos que la programación funcional se trata de funciones puras, ¿verdad? Entonces, dadas sus entradas, siempre vamos a obtener la misma salida y no vamos a tener efectos secundarios. Así que cuando hablamos de efectos secundarios, podría ser como guardar en una base de datos y enviar un correo electrónico, algo así. Pero es importante tener en cuenta que también necesitaremos lidiar con funciones mejoradas porque sabemos que para tener una base de código útil, necesitamos tener funciones mejoradas. Entonces nuestros programas necesitan tener entrada y salida. Queremos poder interactuar con ellos. Y esas interacciones siempre ocurren en funciones puras. Así que después de escribir en tu base de datos, por ejemplo, vamos a cambiar su estado. Entonces, cuando vayamos a leer de la base de datos, después de guardar en ella, el resultado va a ser diferente. ¿Y cómo vamos a manejar eso? Así que necesitamos hablar sobre los efectos secundarios. Cuando estamos en la programación funcional, nos encanta hablar de las cosas puras. Pero también necesitamos hablar de los efectos. Y ese es un tema realmente importante a discutir, cómo lidiar con ellos. Así que debemos tener mucho cuidado con las funciones impuras porque cambian estados. Entonces, si ejecuto algo hoy, mañana los resultados pueden ser diferentes. Esta es la parte difícil de gestionar, pero necesitamos gestionarla. Por eso necesitamos estructurar cuidadosamente nuestra base de datos para no interferir con ella. Aquí tienes un ejemplo. Imagina que tienes una función impura dentro de una ejecución pura. Entonces ya no tienes una función pura.

2. Maximizando la Programación Funcional

Short description:

Necesitamos separar lo que construimos. Nuestro objetivo es maximizar la programación funcional y minimizar las funciones impuras. Si una función podría ser pura y no lo es, lo estamos haciendo mal. Intentemos refactorizar esto.

Por eso necesitamos tener cuidado al estructurar nuestro código. Queremos maximizar las funciones puras que tenemos. Por lo tanto, no podemos llamar a una función impura dentro de una ejecución pura porque la hemos perdido. Así que necesitamos separar lo que construimos. Necesitamos los efectos de las funciones puras. Los efectos pueden infectar todo. Y nuestro objetivo aquí es maximizar nuestra programación funcional y minimizar y aislar las funciones impuras, el código imperativo. Por lo tanto, lo que siempre debemos tener en cuenta es que si una función podría ser pura y no lo es, lo estamos haciendo mal. Así que intentemos refactorizar esto.

3. Programación Funcional e Inmutabilidad

Short description:

Otra cosa poderosa de la programación funcional es la inmutabilidad versus la mutabilidad. La inmutabilidad nos permite observar el estado de un objeto en un cierto punto en el tiempo, mientras que la mutabilidad pierde la noción del tiempo y mezcla el estado y la identidad. Las funciones puras y la inmutabilidad hacen que las funciones sean más fáciles de razonar y depurar, ya que la salida siempre es la misma y los cambios se representan mediante nuevos objetos. Al enfocarnos en los datos, los cálculos y las funciones, en lugar de las clases y el código repetitivo, podemos escribir un código más claro y eficiente. Las pruebas son importantes para una base de código sostenible, ya que brindan confianza y sirven como documentación.

Otra cosa poderosa de la programación funcional es cuando hablamos de la inmutabilidad versus la mutabilidad. Comencemos con la imagen que tenemos a la izquierda. Tenemos un libro con muchas páginas. Este libro es la identidad. Cuando quieres cambiar algo en el dibujo, simplemente pasas la página y dibujas una nueva cosa al final. Entonces, el acto de pasar las páginas representa el estado del dibujo a lo largo del tiempo. Por lo tanto, si te detienes en una página, puedes observar el estado en un cierto punto del tiempo.

Pero si miramos ahora a la derecha, tenemos un ejemplo mutable donde el libro es solo una página. Entonces, si quieres hacer un cambio, necesitamos borrar cosas y volver a dibujar. Así que aquí hemos perdido la noción del tiempo. Y el estado y la identidad ahora están mezclados. Así que cuando hablamos de inmutabilidad aquí, tenemos la animación. Conoces todos los pasos que ha dado tu dibujo para llegar al final. Conoces toda la historia.

Entonces, al hablar de funciones puras más inmutabilidad, vamos a tener funciones que son fáciles de razonar y más fáciles de depurar. Esto es lo que queremos. Porque con funciones puras, sabes que dado un valor de entrada, la salida siempre es la misma. Así que es muy fácil razonar sobre ello. Y también con la inmutabilidad, siempre tienes nuevas páginas cuando cambias algo. Por lo tanto, no necesitas profundizar en el código para entender qué función está mutando la página. Así que queremos tener en cuenta las cosas que queremos, que son funciones puras e inmutabilidad al desarrollar, para poder buscarlas. Porque esta combinación va a dar a los desarrolladores mucho poder y velocidad. Genial.

Entonces, cuando la programación es funcional, queremos enfocarnos en los datos, los cálculos, las funciones y no en las clases, interfaces y código repetitivo. Así que la intención de nuestro código es clara y puedes probar cosas nuevas más rápido. Por lo tanto, lo que queremos aquí es ser lo más funcional posible para poder avanzar más rápido y con confianza. Ahora hablemos un poco sobre las pruebas, porque si queremos una base de código sostenible, necesitamos pruebas. Las pruebas son importantes porque brindan a los desarrolladores confianza para cambiar, extender o cambiar nuestro código. Entonces, al tratar de entender, por ejemplo, un código que no escribimos, podemos verificar las pruebas para entender qué se esperaba de ese código cuando se escribió. Así que también es como documentación.

4. Precisión de las pruebas y Diseño para la Mantenibilidad

Short description:

Si cambiamos el código, necesitamos cambiar las pruebas, de lo contrario se volverían obsoletas. Lo que queremos aquí son funciones realmente granulares, cuanto más granulares sean, más precisión se puede obtener. También se trata de velocidad. Cuanto más rápido encontremos una prueba fallida, antes podremos identificar el problema y menor será su impacto. Aquí utilizamos pruebas de contrato para garantizar que la comunicación entre los servicios funcione. Así que con eso, podemos tener precisión, velocidad y confiabilidad. Ahora, voy a hablar sobre cómo diseñar un registro. Lo que queremos es una alta mantenibilidad con una baja deuda técnica. Necesitamos que sean simples y fáciles de trabajar.

Si cambiamos el código, necesitamos cambiar las pruebas, de lo contrario se volverían obsoletas, pero no lo hacen, porque es una documentación en vivo. Pero ¿cómo sabemos y verificamos si nuestro programa está haciendo lo que se espera que haga? ¿Cómo podemos verificar la calidad de esta retroalimentación? Y aquí no voy a hablar del 100% de cobertura.

Así que empecemos con la precisión. Si tus pruebas fallan, ¿puedes determinar exactamente qué parte del código ha fallado? ¿Cuánto tiempo te lleva saber dónde falló? Así que lo que queremos aquí son funciones realmente granulares, cuanto más granulares sean, más precisión se puede obtener. Por lo tanto, es mucho más rápido si tienes funciones pequeñas sin dependencias del mundo exterior, así que recuerda las funciones puras.

También se trata de velocidad. Cuanto más rápido encontremos una prueba fallida, antes podremos identificar el problema y menor será su impacto. Así que lo que necesitamos aquí son pruebas que sean simples de escribir y mantener, y también que sean rápidas de ejecutar. Si tenemos mucho código complejo con muchas dependencias del mundo exterior, nos llevará mucho tiempo mantener estas pruebas. Y también necesitamos pruebas que sean confiables. Necesitamos confiar en el resultado de nuestras pruebas. Si el resultado cambia de una ejecución a otra, si no cambiamos el código, las configuraciones o las dependencias, ¿por qué mantener este tipo de pruebas? Porque no confiamos en ellas, así que no tiene sentido mantenerlas.

Aquí generalmente estamos hablando de pruebas de extremo a extremo. Las pruebas de extremo a extremo son un problema porque no caminas nada, realmente guardas cosas en la base de datos. Es muy común que fallen por razones oscuras, como la latencia, la recolección de basura, operaciones asíncronas. Así que necesitamos pensar de manera diferente. Aquí necesitamos pensar un poco más grande. Sabemos que las pruebas unitarias cubren los niveles de función, las pruebas de integración cubren los flujos, y necesitamos garantizar que la conversación entre los servicios funcione. Por lo general, usamos las pruebas de extremo a extremo para eso, pero podemos pensar un poco más grande y probar la conversación entre dos servicios a la vez, por ejemplo. Así que aquí usamos pruebas de contrato.

Cada prueba de contrato va a tener un servicio proveedor y un servicio consumidor, y para cada comunicación entre ellos, necesitamos definir una interfaz clara llamada contrato. Así que ahora tenemos pruebas automatizadas que aseguran que los datos generados por el proveedor pueden ser consumidos por el consumidor. Y si cambiamos algo, el contrato se romperá. Así que es importante tener en cuenta que esto no es un reemplazo uno a uno de las pruebas de extremo a extremo, pero la mayoría de los errores que las pruebas de extremo a extremo capturan, estas pruebas también pueden capturarlos. Así que con eso, podemos tener precisión, velocidad y confiabilidad. Y eso es lo que queremos.

Ahora, voy a hablar sobre cómo diseñar un registro. Porque está bien, tenemos la programación funcional, tenemos las pruebas, pero ¿cómo diseñar el código para aprovechar esto? Lo que queremos es una alta mantenibilidad con una baja deuda técnica, porque queremos que las aplicaciones que se utilizan para realizar mantenimiento tengan una baja deuda técnica. Necesitamos que sean simples y fáciles de trabajar. Y esto es difícil porque la mantenibilidad es un concepto a largo plazo porque al principio, es realmente fácil.

5. Arquitectura Hexagonal y Separación de Responsabilidades

Short description:

Tu proyecto acaba de comenzar y, a medida que crece, la mantenibilidad se vuelve crucial. Inicialmente intentamos utilizar una arquitectura hexagonal simple, separando el modelo de dominio, el controlador y las capas de IO. La capa de IO permite funciones impuras y mutación de datos, mientras que la capa de dominio se centra en funciones puras. El objetivo es separar la lógica de negocio de las preocupaciones técnicas y probar en aislamiento utilizando simulación e inyección de dependencias. Con la arquitectura hexagonal, podemos aislar y controlar los efectos secundarios en la capa de IO.

Tu proyecto acaba de comenzar, tenemos unas pocas líneas de código, tres personas trabajando en él. Así que solo tenemos un par de dependencias. Pero a medida que tu equipo y tu código crecen, las cosas se vuelven más difíciles. Y un error puede resultar en una refactorización completa de la arquitectura. Por eso es necesario pensar en la mantenibilidad desde el principio.

Lo que vamos a decir aquí. Entonces, el primer intento que tuvimos fue intentar utilizar una arquitectura hexagonal. Así que aquí tenemos una arquitectura hexagonal simple. El modelo de dominio donde tenemos la implementación de nuestro dominio. Aquí vamos a tener las funciones puras y los datos mutables. Por eso está en verde. Después de eso, tenemos la segunda capa donde tenemos el controlador que se encarga de conectar los puertos con los adaptadores en la lógica, el dominio. Aquí se trata de coordinación. Pero aquí ya tenemos algunas funciones que son impuras, ¿verdad? Y algunos datos mutables. Así que no son todas, pero algunas de estas son blancas, amarillas. Y en la tercera capa, aquí es donde tenemos lo que se llama IO o puertos. Y aquí interactuamos con el mundo exterior. Así que aquí vamos a hacer llamadas a otros servicios, vamos a hacer llamadas a la base de datos a APIs de terceros. Así que aquí está bien tener funciones impuras y mutación de datos, esperamos eso en la capa de IO.

Entonces, lo que queremos lograr con la segunda arquitectura hexagonal es separar la lógica de negocio de la IO. Queremos estructurar el código de manera que protejamos el dominio de las cosas técnicas. Podemos definir cuáles son las reglas de negocio, cuáles son las reglas educativas y cuál es el código de infraestructura y ¿cómo probamos esta arquitectura? Queremos probar en aislamiento con simulación porque no queremos depender de una base de datos externa o APIs externas. Realmente queremos simular y aislar las cosas para eso. Utilizamos inyección de dependencias. ¿Verdad? Estas dependencias aquí se pasan como argumentos. Así que cuando se ejecuta en producción, usamos la base de datos real y para las pruebas, por ejemplo, podemos usar un archivo codificado en duro, pero ¿cuál fue el primer descubrimiento con esta arquitectura? Así que recuerda que en la arquitectura hexagonal, tenemos nuestras funciones en los límites, ¿verdad? En la capa de IO, las que generan efectos secundarios. Así que es bueno darse cuenta de que en esta arquitectura podemos aislar y controlar los efectos secundarios en esta capa. Así que tenemos los límites aquí, como podemos ver.

6. Understanding Isolation and Encapsulation

Short description:

El aislamiento es cuando toda la información que una función tiene del mundo exterior se pasa a través de argumentos. La encapsulación significa que el objeto tiene un estado y el mundo exterior no sabe nada al respecto a menos que se haga explícitamente disponible a través de getters y setters. Las funciones aisladas son muy fáciles de probar y se obtienen de forma gratuita al usar programación funcional. Lo mínimo esperado de un buen diseño funcional es tener funciones puras. ¿Por qué la arquitectura hexagonal en FPP es natural? Uno de los lenguajes que ayudó a entender eso es Haskell, porque Haskell es un lenguaje funcional que espera que todas las funciones sean puras.

Entonces hablemos de este concepto. ¿Qué significa aislamiento? El aislamiento es cuando toda la información que una función tiene del mundo exterior se pasa a través de argumentos. Así que podemos concluir que cada función par es aislada. Entonces una función par es un subconjunto de funciones aisladas. No todas las funciones aisladas son puras, pero todas las ejecuciones pares son aisladas. Y el aislamiento es el dual de la encapsulación. Entonces la encapsulación significa que el objeto tiene un estado y el mundo exterior no sabe nada al respecto a menos que se haga explícitamente disponible a través de getters y setters. Entonces el aislamiento significa que una función no sabe nada sobre el mundo externo a menos que se le ingrese. Así que es el dual, ¿verdad? Y las funciones aisladas son muy fáciles de probar y se obtienen de forma gratuita al usar programación funcional. Pero en la programación orientada a objetos, son un problema debido al principio de encapsulación. Entonces, al desarrollar con código orientado a objetos que se va a probar, necesitamos encontrar la intersección entre el aislamiento y la encapsulación. Y eso es realmente difícil porque es mucho más fácil trabajar en un subconjunto que en una intersección, ¿verdad? Así que es difícil mantener el equilibrio entre el aislamiento y la encapsulación al tratar con programación orientada a objetos. Pero con la programación funcional, no hay ningún problema en absoluto. Lo mínimo esperado de un buen diseño funcional es tener funciones puras. Y son un subconjunto de las aisladas. Así que si estás haciendo algo puro, lo estás haciendo aislado y obtienes la facilidad de la prueba de forma gratuita. Y queremos tener tantas funciones puras como sea posible para obtener todos esos beneficios, porque sabemos que si tienes funciones puras que causan una ejecución impura, también sería impura. Entonces, ¿por qué la arquitectura hexagonal en FPP es natural? Uno de los lenguajes que ayudó a entender eso es Haskell, porque Haskell es un lenguaje funcional que espera que todas las funciones sean puras. Y cuando estamos programando en Haskell, el compilador te ayuda en esa función, verificando si esa función es pura o no. Porque si escribiste una función impura y olvidaste declarar su tipo como IO, te lanzará un error. Entonces, para tener tantas funciones puras como sea posible, empujas la función impura hacia los límites. Entonces, las funciones impuras pueden llamar a la cadena de funciones puras, pero una función pura nunca puede llamar a una impura, de lo contrario obtendrás un error del compilador. Así que vamos a tener una cáscara de códigos impuros. Esto es un recordatorio de la arquitectura hexagonal. Por eso Haskell es un lenguaje que te ayuda a descubrir eso porque espera que todas las funciones sean puras. Y un buen diseño de programación funcional puede ser un deporte electrónico y adoptado. Y este es un gran descubrimiento. Pero recuerda que al principio dije que queremos aprovechar al máximo la programación funcional. Y como te mostré, todavía tenemos controladores con código imperativo y efectos secundarios.

7. Arquitectura Hexagonal y Rechazo de Dependencias

Short description:

¿Por qué no queremos eso? Permíteme mostrarte un ejemplo. Tengo una llamada funcional llamada bloquear, y estoy pasando una tarjeta, una base de datos y un productor. Cuando veo esta llamada, no tengo idea de cuál es el resultado. Es más difícil componer con código imperativo. Entonces, probemos otro enfoque. ¿Qué tal si usamos la arquitectura hexagonal con rechazo de dependencias? Ahora, cuando llamo a bloquear, solo paso la tarjeta y obtengo un objeto de retorno con datos de hechos y un mensaje de hechos.

Entonces, ¿por qué no queremos eso? Aquí voy a mostrarte un ejemplo. Imagina que tengo esta llamada funcional llamada bloquear. Y estoy pasando una tarjeta, una database y un productor. Entonces, cuando veo esta llamada funcional, no tengo idea de cuál es el resultado. Podría ser verdadero. Y si es verdadero, ¿qué significa eso? Bien, entremos en la función tratando de entender eso. Como puedes ver, tengo la tarjeta. Estoy haciendo cierta lógica en ella. Y luego llamo a la actualización en la database. Y después de eso, llamo al productor de cambios de estado de la tarjeta aquí, ¿verdad?

Entonces, aquí necesité entrar en la función para entender qué está haciendo. Y aquí no estoy devolviendo nada. Así que no tengo idea de lo que sucede antes de entrar en la función. También es más difícil componer cuando tengo código imperativo. Entonces, aquí imagina que llamo a bloquear para 10 tarjetas. Imagina que en la tercera tarjeta falla. Ahora he llamado al debate para actualizar el productor y enviar mensajes, pero solo para tres tarjetas. Así que no puedo simplemente volver a ejecutar las cosas porque duplicaría los efectos. ¿Cómo manejaría esta composición? Es difícil porque estoy haciendo las cosas sobre la marcha. Y lo que tenemos aquí no es el permiso que queremos. Tenemos un permiso que tiene más integración que pruebas unitarias porque, como puedes ver en mi controlador, tengo ese tipo de funciones que llaman al debate, que llaman al productor. Así que esto no es lo que queremos. Esas funciones no son puras. Las pruebas no son tan fáciles y la manejabilidad no será buena. Así que probemos otro enfoque para eso.

¿Qué tal si usamos la architecture hexagonal con rechazo de dependencias? ¿Qué significa eso? Que separamos el acoplamiento, las decisiones, de los hechos. Desacoplamos la intención de la ejecución. Entonces, la misma función, pero ahora cuando llamo a bloquear, solo paso la tarjeta. No paso la database ni el productor. Y como puedes ver, tengo un retorno. Y mi retorno es un objeto que tiene una clave llamada datos de hechos, y tiene su valor y una clave llamada mensaje de hechos, y tiene su valor.

8. Entendiendo las Funciones Puras

Short description:

Aquí solo estoy llamando a la lógica que es una función pura. ¿Qué quiero hacer? ¿Cuál es mi decisión? Quiero actualizar la tarjeta y enviar un mensaje. Esta función es pura, por lo que puedo probarla usando pruebas unitarias. Es fácil de razonar y componer.

Ahora sé lo que hace la función. Pero claro, puedo entrar para entender mejor. Y como puedes ver, aquí solo estoy llamando a la lógica que es una función pura, y simplemente estoy creando. ¿Qué quiero hacer? ¿Cuál es mi decisión? Y quiero actualizar la tarjeta, y tengo los data que necesito para eso. Y también quiero enviar un mensaje. Tengo los data que necesito para eso, pero no estoy haciendo nada. Esta función es pura. Por lo tanto, puedo probarla usando pruebas unitarias, por ejemplo. Es realmente fácil de razonar. Además, será fácil de componer, porque antes estábamos iterando y guardando cosas en la database y produciendo mensajes. Pero ahora, no estoy haciendo eso. Solo estoy creando un objeto. Mencionamos las 10 tarjetas. Eso va a tener un array con las 10 tarjetas. Y lo que quiero hacer es intentar hacer eso solo una vez, no durante el proceso. Eso sería más difícil de recuperar. Así que lo que tenemos aquí es que ahora tenemos operaciones atómicas, y tenemos los data como ciudadanos de primera clase. Y eso es realmente poderoso, porque como pudiste ver, vimos el data pasando, porque estamos devolviendo un objeto con lo que queríamos hacer. Antes, solo estábamos haciendo cosas, y no teníamos idea de lo que estaba sucediendo. Y cuando tienes los data como ciudadanos de primera clase, obtenemos este poder para entender mejor lo que nuestro código está haciendo. Y también, ahora nuestros controladores son puros. Solo estamos haciendo los efectos secundarios en la IO. Eso es lo que queríamos desde el principio, pero no pudimos hacerlo con la inyección de dependencias. Así que ahora solo estamos ejecutando el código InPure en la capa de IO, y tenemos los controladores puros. Por eso también está en verde. Así que eso es todo, tenemos controladores sin efectos secundarios. Y ahora somos más expresivos. Nuestro código nos cuenta mejor la historia de lo que estamos haciendo. Entonces, lo que queríamos para tener una base de código sostenible era tener tantas funciones puras como fuera posible, lo logramos. Queríamos poder tener pruebas que sean, que tengan precisión porque tenemos muchas funciones puras. Podemos tener mantenibilidad porque cuando tenemos pruebas unitarias, es mucho más fácil mantener las pruebas de integración, ¿verdad? Y también con inmutabilidad, también es más fácil entender las cosas. También es mucho más fácil debug. Con esta arquitectura, podemos obtener todas esas cosas. Eso es todo. Gracias por su atención. Aquí están nuevamente mis redes sociales y también Brisa, la empresa para la que trabajo está contratando. También puedes seguirme en Twitter, así puedo twittear este enlace. Será más fácil para ti, pero eso es todo, gracias por su atención.

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.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
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
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.

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
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
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