La Nueva Frontera: Comercio Electrónico en el Edge

¡Hola! Mi nombre es Michael y hoy quiero hablarles sobre la nueva frontera, el comercio electrónico en el edge. He estado construyendo aplicaciones de comercio electrónico durante más de 15 años, desde el antiguo PHP 5.4 hasta ahora Node.js TypeScript y herramientas más modernas, y eso es de lo que quiero hablar hoy. Quiero contarles sobre el futuro del comercio electrónico que consta de dos tendencias principales que quiero cubrir hoy, una es headless y la segunda es el edge. Veamos qué quiero decir con esto.

Primero, headless. Aquí hay un gráfico de tendencias de Google para el comercio headless. Como pueden ver, cada vez más personas lo están buscando, hay mucho interés allí. Pero, ¿qué significa? Busquémoslo en Google y averigüémoslo. Cuando lo buscamos, veremos que la primera página está llena de anuncios. Si seguimos bajando y tratamos de averiguar qué significa en realidad, encontraremos, uno tras otro, publicaciones de blog de marketing de contenido. ¿Qué podemos deducir de esto? ¿Qué podemos deducir de esto? Es una palabra de moda, eso es lo que podemos deducir. Y si tratamos de leer esto y averiguar qué significa, nos perderemos en el argot y las palabras clave. Saltemos eso y les mostraré un diagrama para simplificarlo.

Queremos construir una aplicación de comercio electrónico basada en la web, una tienda en línea. ¿Qué necesitamos? Necesitamos un servidor. Vale, necesitamos una base de datos para almacenar nuestros productos, clientes y datos de pedidos. Necesitamos algo de lógica empresarial. Esto es lo que tomará esos datos, los colocará en algunas plantillas, aplicará cierta lógica empresarial y producirá el sitio web y toda su funcionalidad. Probablemente tengamos algunos servicios en la nube, alguna capa de caché, tal vez algunas API de terceros a las que llamar pero al final de todo eso, vamos a servir a nuestros clientes un poco de HTML. Ese producto data de la base de datos se ha colocado en una plantilla y el servidor está devolviendo HTML. Esto es lo que se conoce como una arquitectura monolítica, una arquitectura tradicional para una aplicación web. Ha existido durante mucho tiempo y seguirá existiendo durante mucho tiempo. Esto es bueno, pero no estamos hablando de eso ahora. Estamos hablando de headless. Headless es diferente. ¿Cómo pasamos de monolítico a headless? Bueno, es simple. Solo tenemos que quitar la cabecera así. Ahora, ¿qué está sucediendo? Ya no estamos sirviendo HTML desde el servidor. En su lugar, estamos sirviendo JSON a través de una API JSON. Eso podría ser una API REST o una API GraphQL.

El cliente es responsable de tomar esos data y convertirlos en HTML. Normalmente, eso sería un framework basado en JavaScript. Tomaríamos el JSON y lo colocaríamos en una plantilla. Esto no es algo nuevo. Lo hemos estado haciendo durante mucho tiempo. Solíamos llamarlo cosas como AJAX. Ahora se le llama Headless. Pero eso es todo lo que necesitas saber. Estoy seguro de que ya lo has hecho. Si has estado construyendo aplicaciones de una sola página, probablemente ya lo hayas estado utilizando. Nada nuevo. Pero eso es a lo que nos referimos cuando hablamos de headless. El comercio headless es esto aplicado a una aplicación de e-commerce. Veamos algunos ejemplos. Entonces, Headless realmente se hizo popular en el espacio de la gestión de contenido, en primer lugar. Probablemente hayas oído hablar de algunos de estos servicios y proyectos. WordPress es uno interesante. Este es como el antiguo sistema CMS monolítico original, el abuelo. Pero está aquí porque puedes usarlo como un CMS headless. Tiene una API REST y una API GraphQL. Entonces puedes usarlo así. En el espacio del comercio, hay muchos productos de software como servicio y productos de código abierto que puedes usar para construir de esta manera. Nuevamente, tienes ofertas headless puras como Commerce Tools y Venger. Y luego tienes empresas como Shopify, que es un sistema monolítico tradicional, pero que recientemente ha apostado muy fuerte por Headless. Y esto es fantástico. Probablemente hayas oído hablar del proyecto Hydrogen y probablemente también hayas oído que adquirieron Remix también. Esto muestra que un jugador importante como Shopify está apostando fuerte por el espacio del e-commerce. Y esto es una muy buena señal. Y esto es una señal de que esta es una tendencia que realmente está aquí para quedarse y que impulsará el futuro del e-commerce.

Entonces, hemos aprendido qué es Headless, pero ¿por qué a la gente le interesa? ¿Por qué es tan importante? ¿Por qué es el futuro? Veamos algunos de los beneficios. En primer lugar, vemos que es bastante fácil ahora que hemos separado el cliente del servidor. Ahora podemos servir a múltiples clientes a través de la misma API, una aplicación móvil, tal vez un sistema de punto de venta en la tienda e incluso un refrigerador conectado a Internet donde puedes pedir tus comestibles a través de la misma API.

Y ahora que hemos desacoplado la interfaz de usuario, significa que ya no estamos limitados por los sistemas de plantillas impuestos por un sistema monolítico, ya sea las plantillas de Magento que ves aquí o el sistema de plantillas estilo WordPress que se utiliza en WooCommerce o las plantillas líquidas utilizadas por Shopify. Una interfaz de usuario desacoplada significa que podemos utilizar absolutamente cualquier tecnología que queramos para construir nuestros front-ends. Y este es un punto clave porque en el e-commerce, no es raro que el servidor de la plataforma en sí tenga una vida útil muy larga. Es una gran inversión y durará cinco años, diez años, incluso más. Al desacoplar la interfaz de usuario, significa que ya no estamos limitados por la tecnología en la que se construye la plataforma de backend. Podemos construir el front-end con lo que queramos. Por ejemplo, Remix. Y eso nos lleva a las tooling. Tomemos como ejemplo Magento. Esta es una plataforma de comercio de código abierto muy grande. La última versión importante salió hace algunos años, tal vez hace unos siete años. Y en ese momento, tuvieron que elegir en qué construirían esa capa de interfaz de usuario. Entonces, las herramientas que estaban disponibles en ese momento se veían así. Y eligieron algunas de estas. Como Knockout, RequireJS. Y esa fue una buena elección en ese momento. Ahora, si fueras a comenzar un nuevo proyecto y alguien dijera elige la herramienta que quieras, es posible que no elijas estas. Yo personalmente no elegiría esas. Elegiría algo más como las que están en este lado. Y el punto clave aquí es que con una arquitectura headless, eres libre de hacerlo. No estás limitado por las opciones de tooling que se tuvieron que tomar hace una década. Puedes usar lo que tenga sentido ahora. Y eso es algo enorme en términos no solo de productividad del desarrollador, felicidad del desarrollador, sino también en los resultados que puedes obtener en términos de las experiencias que puedes crear para tus clientes. Y esto también resalta una fortaleza, una fortaleza masiva de el ecosistema de JavaScript node, esta increíble innovación, este ritmo de innovación. Algunas personas lo llaman fatiga de JavaScript. Pero en el lado positivo, tenemos una increíble variedad de herramientas que podemos usar, y hay una innovación continua. Y la innovación no solo está en los frameworks y

¿Qué queremos decir con el borde de una red? Bueno, en el centro de esta red, tenemos una región de nube, EU central uno. Ahí es donde alojamos nuestra aplicación de comercio electrónico. Tenemos usuarios de todo el mundo que quieren usarla. Y observa que no están accediendo directamente a la nube. Están pasando por un servidor intermedio que está cerca de ellos. Estos servidores son a los que nos referimos como el edge o servidores edge. Hagamos esto más concreto. Aquí está nuestra aplicación de nodo ejecutándose en Europa central. Aquí se ejecuta nuestra aplicación de remix, por supuesto, y estamos utilizando un backend de comercio headless. Y tenemos un posible cliente aquí en Sídney. Él ingresa la URL de nuestro sitio web en su navegador. Su navegador enviará un paquete hasta nuestro servidor en Europa central, y eso está a 16,000 kilómetros de distancia. Solo la latencia de la red para que ese paquete llegue será de más de 260 milisegundos. Una vez que llega al servidor, vamos a renderizar HTML. Este es un punto clave. Estamos hablando de comercio electrónico. Vamos a hacer renderizado en el servidor, ¿de acuerdo? El SEO es el rey, así que definitivamente vamos a hacer renderizado en el servidor, por lo que hay trabajo que hacer allí. Una vez que se ha renderizado el HTML, tenemos que enviarlo de vuelta, todo el camino de vuelta a Sídney. Nuevamente, latencia de 16,000 kilómetros, por lo que justo antes de que llegue el primer byte, nuestro cliente estará esperando un segundo, dos segundos. ¿Quién sabe? ¿Cómo se verá esto desde su punto de vista? Bien, él ingresa la URL. El paquete viaja 16,000 kilómetros. El HTML se está renderizando.

De acuerdo, el primer byte ha regresado. Tenemos algo de HTML. Eso es bueno. Ahora, el HTML está obteniendo algunos JavaScript, tal vez algunos activos. Está haciendo algunas solicitudes adicionales para obtener datos que no pudo servir en el renderizado, como datos específicos de la sesión. Ah, okay. El carrito de compras acaba de cargarse. Algunas solicitudes más en segundo plano. Mucha latencia en cada solicitud. Finalmente, aparece la imagen. El sitio web se ha cargado. No es una gran experiencia. ¿Cómo podemos mejorar esto?

Algo que hemos estado haciendo durante mucho tiempo es utilizar CDNs, Redes de Entrega de Contenido. Esto es en realidad una forma de computación en el edge. Almacena activos estáticos, como imágenes, archivos JavaScript, archivos CSS, en un servidor edge, por ejemplo, justo allí en Sídney. Cuando esos activos se requieren en el futuro, se obtienen localmente. En lugar de una latencia de 500 milisegundos, hay una latencia de 10 milisegundos. Eso resuelve parte del problema. Pero todavía tenemos que ir hasta el servidor de origen para obtener el archivo HTML y saber qué recursos debemos cargar posteriormente.

¿Cómo podemos resolver esto? Bueno, ¿qué tal si pudiéramos hacer el renderizado no solo en nuestro servidor de origen en Europa central, qué tal si pudiéramos renderizar justo allí en el edge como si hubiéramos dispersado nuestro servidor de nodo por todo el mundo? Eso sería genial. Eso es lo que podemos hacer ahora. Además de nuestro CDN estático, también podemos renderizar nuestra página justo allí en el edge con algo como el renderizado del lado del servidor de Remix Edge SSR. Una cosa realmente genial de Remix es que puede ejecutarse en cualquier entorno de ejecución de JavaScript. Todos conocemos Node.js, pero hay otros entornos de ejecución de JavaScript. Está Deno, está CloudFlare Workers, probablemente hay otros y probablemente habrá más en el futuro. Remix es muy inteligente. Abstrajo esa parte en adaptadores para que pueda ejecutarse en cualquier plataforma de JavaScript. En este caso, podríamos estar ejecutándolo en un CloudFlare Worker, por ejemplo, CloudFlare Pages, y Remix puede hacer el renderizado justo allí. Entonces, el HTML se genera allí en Sídney, a 10 milisegundos de distancia.

Entonces, por eso lo llamo la nueva frontera. Es realmente una revolución en la forma en que podemos servir aplicaciones y aumentar el rendimiento, aumentar la disponibilidad global y disminuir la carga que realmente tenemos que servir en nuestros servidores de origen. Entonces, esta nueva frontera, como dije, consiste en una arquitectura sin cabeza y computación en el edge. Ahora, ¿cómo se ve esto en la práctica? Tengo una demostración para ustedes. Permítanme presentarles a Venger. Venger es un proyecto de código abierto en el que he estado trabajando durante los últimos cuatro años. Es un marco de comercio electrónico. Permite a los desarrolladores construir aplicaciones de comercio electrónico personalizadas. Está construido en Node.js utilizando TypeScript, y es sin cabeza. Expone su funcionalidad a través de APIs de GraphQL. No solo eso, es altamente extensible. Puedes construir prácticamente cualquier cosa en él. Admite varios idiomas, varias monedas y tiene una comunidad activa y en crecimiento. Es utilizado por muchas empresas, desde Fortune 500 hasta startups Unicornio, startups respaldadas por Y Combinator, cadenas nacionales de supermercados y todo lo demás. Si quieres probarlo, puedes comenzar con un solo comando, npx at Venger slash create myshop. Admite SQLite, por lo que no necesitas tener una base de datos ejecutándose localmente, literalmente puedes estar en funcionamiento en cinco minutos. Pruébalo después de esta charla o después de este día de conferencia.

Esto es lo que quiero mostrarte hoy. Es una tienda en línea respaldada por Venger. Está construida, por supuesto, con Remix. Funciona en CloudFlare pages, que es una plataforma de computación en el edge. Y la API está en caché por Stellate, que es un servicio de caché de API que utiliza la red edge de Fastly para almacenar en caché las respuestas de la API. Así que tenemos todo en la mezcla de lo que he hablado. Así que esto debería ser bueno. Echemos un vistazo. Aquí está el sitio web. Está disponible en remix-storefront.venger.io. Te llevaré en un recorrido muy rápido. Aquí está la página de inicio. Podemos profundizar, ver estas categorías, cámara, foto, echar un vistazo a esto. Y como puedes ver, se ejecuta bastante rápido. Podemos filtrar, agregar al carrito, podemos ver el carrito. Modificarlo. Todo esto está sucediendo contra una API real. Podemos buscar.

Entonces, eso es lo que es usarlo. Estoy seguro de que estarás de acuerdo en que es bastante rápido. Pero, ¿qué tan rápido exactamente? ¿Podemos tener una medida objetiva de ello? Echemos un vistazo a Page Speed Insights. Y vamos a tomar esta página de detalle del producto y colocarla allí. Y ahora, se ejecutará un análisis. Y lo que esperamos ver, por supuesto, son muchos círculos verdes con números grandes acercándose a 100, con suerte. Veamos qué nos da. En primer lugar, veremos los resultados en dispositivos móviles. Bien. Muchos círculos verdes. Y casi 100 en todos ellos. Si pasamos a la versión de escritorio, bien, esto se ve realmente bien.

Tenemos prácticamente 100 en todo. Accessibility necesita un pequeño ajuste. Y estos números aquí son ridículamente buenos. Así que es rápido. Es objetivamente muy rápido.

Veamos si podemos obtener una medida de los beneficios que la computación en el edge está aportando en esta situación. Nuestro servidor de origen en este caso está en Europa. Estoy en Austria. Así que no estamos viendo realmente las capacidades completas del edge. Pero veamos si podemos ver este sitio web desde diferentes ubicaciones alrededor del mundo. Aquí hay una página que encontré que nos permite hacer esto. Así que hará una solicitud a este sitio web desde Singapur, Brasil, Virginia, California, Irlanda, Australia. Y veamos cuáles son los resultados. Así que todos llegan. Mira estos. Seis milisegundos. 14 milisegundos desde Brasil, Virginia, un milisegundo, Australia, 14 milisegundos, California, dos milisegundos.

No puedo pensar en una mejor ilustración de todo este concepto de headless y edge que esto. Los resultados hablan por sí mismos. Voy a callarme ahora. Ese es el final de la demostración. Volvamos a las diapositivas. Para resumir, hemos hablado sobre el futuro del comercio electrónico siendo headless, computación en el edge construida sobre Venger utilizando Remix. Gracias por su atención.