El Futuro es Componible: Por dónde Empezar en la Construcción para Él

Hola, soy Henry Smith y soy un ingeniero de soluciones senior en Netlify. Hoy quiero hablarles sobre el futuro de la web y la composabilidad, y dónde comenzar a construir para ello. Una de las ventajas de mi trabajo es que puedo hablar con cientos de clientes diferentes que han emprendido este viaje hacia la composabilidad. Lo que pensamos hacer hoy es recopilar algunos de sus pensamientos y tips y trucos que hemos aprendido en el camino para ayudarte en tu viaje hacia la composabilidad.

Cuando hablamos de composabilidad en la web moderna, también debemos pensar en dónde hemos estado. Ahora, las aplicaciones monolíticas aún constituyen la gran mayoría de las aplicaciones web en este momento. Por monolítico nos referimos a una serie de aplicaciones interdependientes desde nuestra capa de data hasta un servidor web que lo envía a una CDN y finalmente llega a las solicitudes en el navegador. Esto está bien y nos ha servido durante muchos años. Pero tan pronto como intentamos construir sobre esto o cambiar cosas en esta estructura monolítica puede ser un verdadero dolor de cabeza extraer y cambiar la funcionalidad e introducir cosas nuevas en ella. Porque efectivamente todo está interdependiente. Así que tenemos que verificar en cada capa que no esté rompiendo nada o haciendo cambios que rompan algo allí.

Entonces, kubectl, o arquitectura componible, o JAMstack, tiene muchos términos diferentes. Pero me gusta verlo en términos de esta especie de arquitectura de tiempo de construcción versus runtime. Entonces, lo que estamos viendo en el tiempo de construcción es tomar nuestra base de código de nuestro proveedor de Git y luego tomar todas esas fuentes de backend data. Entonces nuestro CMS, nuestro sistema PIM, nuestras bases de datos, etc. Y llevar todo eso a un generador de sitios estáticos. Esto nos permite construir nuestro sitio y construir todos esos activos y luego darnos una experiencia preconstruida que luego podemos distribuir globalmente en nuestra red Edge o nuestra CDN. Esto nos lleva ahora a la fase de runtime, por lo que los clientes pueden ir y buscar esa data en caché, esa versión en caché del sitio. Y para cualquier aspecto dinámico que queramos en nuestro sitio, podemos hacer solicitudes a servicios de terceros desde el cliente, o podemos iniciar funciones sin servidor y realizar varias tareas de lógica dentro de ellas.

Entonces, ¿por qué la gente se está inclinando hacia esta ruta más componible? Bueno, en primer lugar, te permite elegir las mejores herramientas para todos estos diferentes bloques de construcción, y esto puede ser realmente poderoso. Significa que puedes protegerte para el futuro al poder cambiar entre diferentes proveedores, pero también significa que no tienes que administrar tantos de estos servicios tú mismo, y muchas veces no hacer un trabajo tan bueno como alguien que se dedica a eso. Además, esta idea de empaquetar estáticamente tu sitio y enviarlo a una CDN tiene varios beneficios en términos de SEO, porque tenemos HTML preconstruido que es fácil de rastrear. También es mucho más rápido, y esto se nota en un sitio JAMstack o Componible. La velocidad es increíble. Además, el aspecto de security es que ahora ya no tenemos una única fuente de verdad a la que tenemos que acceder para todas nuestras solicitudes. Esto significa que nuestra superficie de ataque ha aumentado drásticamente, y por lo tanto nuestro sitio se vuelve más seguro por defecto. Y finalmente, este tipo de arquitecturas escalan de manera excelente. Debido a que tenemos réplicas de nuestra aplicación almacenadas en todo el mundo, significa que puede manejar altos niveles de tráfico y no tenemos que usar mucha computación y renderizar y extraer páginas. Esto simplemente se escala según sea necesario.

Ahora hay una especie de Instagram versus realidad cuando se trata de la Composabilidad, y esto es realmente

una buena visión de cómo debería ser la Composabilidad. Tenemos todos nuestros servicios dispares. Esto es para un sitio de comercio electrónico componible. Todos ellos son interdependientes y aislados en diferentes áreas, y luego nuestra fuente de datos se alimenta de eso, y finalmente nuestro front-end desacoplado lo sirve y se lo entrega a nuestros usuarios finales. Pero la realidad una vez que comienzas a construir este tipo de productos componibles puede ser un poco diferente. Comienzas a construir enlaces y dependencias entre los diferentes servicios y los productos de datos y todas esas cosas, y lo que terminas haciendo en realidad es construir un monolito componible. Todos estos diferentes bloques de construcción que ahora son interdependientes entre sí. Así que vamos a repasar algunos consejos y trucos rápidos sobre cómo evitar eso y construir experiencias componibles realmente increíbles. Entonces, el primero es federar tu capa de contenido y esto es realmente muy importante. Si te aseguras de tener una abstracción frente a toda tu capa de contenido y todo se alimenta y se conecta a ella, esto significa que cuando quieras sacar algo y reemplazarlo, lo cambias en una sola capa y todo lo que está arriba y debajo de eso no se ve afectado. Y esto puede ser realmente poderoso en términos de futurizar tu aplicación pero también en términos de asegurarte de que sea fácil para los desarrolladores cruzar datos entre diferentes fuentes sin tener que tener todos estos conectores diferentes en una capa inferior en la capa de datos. Mi siguiente consejo es mantenerlo simple. Trata de comenzar con un proyecto realmente pequeño. Aún puedes ejecutar tu sistema heredado junto a él y quitar algo simple, el carrito o el blog o algo así. Comienza a construir eso como una arquitectura componible y luego construye gradualmente con el tiempo. La naturaleza de estos proyectos es que se vuelven más complejos a medida que se agregan más piezas pero si eres realmente inteligente al construir cuidadosamente y tienes un patrón de migración realmente claro en términos de migrar literalmente una página a la vez a veces, entonces puedes evitar meterte en este lío y en los detalles y construirlo realmente correctamente desde los cimientos hacia arriba. Mi siguiente consejo es sobre la orquestación en el front-end. Ahora, este es el clásico debate de construir versus comprar. Sí, puedes construir un flujo de CI/CD realmente increíble con tus entornos de desarrollo y puesta en escena, ya sabes, orquestación de infraestructura y luego implementarlo en clústeres de Kubernetes y ejecutar entornos de producción con conmutación por error y luego ponerlo todo detrás de una CDN y tener este tipo de contenido localizado a través de ella también. Pero la realidad es, es realmente difícil armar todo eso, te llevará mucho, mucho tiempo y en realidad, probablemente no obtendrás todas las características y funcionalidades que obtendrías de la herramienta de orquestación en el front-end. Y de eso estamos hablando, hay algunas frameworks súper increíbles que te brindan modos de renderizado increíbles y todas esas cosas, y para que todo eso funcione armoniosamente con cosas como funciones sin servidor y funciones en el borde es un verdadero dolor de cabeza. Entonces, definitivamente este es uno en el que iría a ver el mercado, ver qué se ofrece y ver qué herramienta de orquestación en el front-end te conviene. Uno de mis favoritos personales son las funciones sin servidor y las funciones sin servidor son tus amigos. Porque nuestro front-end se escala hacia arriba y hacia abajo con las solicitudes de manera tan fácil debido a la CDN, necesitamos lógica en el back-end que pueda hacer lo mismo, o también necesitamos construir conectores para esos sistemas en el back-end, y las funciones sin servidor pueden ser muy útiles para esto. Esto se debe a que podemos escalar hacia arriba y hacia abajo ese cómputo y podemos iniciarlos solo para solicitudes individuales y asegurarnos de que nunca nos encontraremos con este problema en el que las solicitudes provenientes del front-end simplemente no se pueden manejar. Mi último consejo es aprovechar el borde. Ahora, las funciones en el borde son algo realmente, realmente genial. Son lógica distribuida en el propio borde de la CDN y esto te brinda la capacidad de hacer cosas geniales en términos de personalización, localización, autenticación, cosas que antes eran típicamente más del lado del servidor o del lado del cliente. Ahora puedes moverlo todo a una función en el borde y esto significa que obtienes todos los beneficios de cosas como una transformación del lado del servidor de tu página, pero no pierdes velocidad. Esto puede ser realmente poderoso, especialmente en términos de esa parte de localización donde quiero redirigir o reescribir páginas o manipular el HTML en sí en el borde. Entonces, definitivamente comenzaría a mirar esto desde el principio y ver si puedes incorporarlo en tu proyecto. Así que ahí tienes mis cinco mejores consejos. Espero que esta haya sido una charla relámpago útil y hayas aprendido algo de eso. No dudes en contactarme y espero que tengas un excelente resto de tu conferencia. Muchas gracias.