 Tenemos a Jepser Bernardino, que es desarrollador front-end, experto en WordPress de Guatemala con más de 7 años de experiencia y actualmente vive en Barcelona. Trabaja en Typeform como líder técnico y tiene una cosa bastante chula la verdad que lo publicaremos luego en un resumen que es el creador del primer artículo conversacional del mundo. Luego lo pondremos si seguís la cuenta de WorkCamp porque merece la pena verlo, ¿vale? También tiene experiencia de desarrollando plugins para WooCommerce y ahora viene a hablarnos de Riot y WordPress que es... si habéis estado atentos en la charla de antes pues más o menos van los tiros por ahí, el futuro en Javascript y demás. Y nada, no le robo más tiempo, os dejo con él y con la charla, ¿vale? Buenos días. Como ya bien dijeron, mi nombre es Jepser Bernardino, soy front-end developer y desde hace aproximadamente dos años me mudé de Guatemala a Barcelona para trabajar en Typeform. Para los que no conocen Typeform, Typeform es una startup que se dedica a tratar de ser la organización que puntea en el ámbito de Conversational Data Collection. ¿Qué quiere decir eso? Creamos herramientas que ayudan a tanto a los creadores de formularios como a los que responden para tener mejores datos. Y hoy vamos a hablar de sitios web estáticos con WordPress y Riot y me voy a enfocar más en la parte de Riot y de sitios web estáticos. Luis explicaba ya parte de cómo ha ido evolucionando la web y llega a un punto donde es tan compleja que es interesante si volvemos a pensar en cómo eran antes, cuando era simplemente HTML, JavaScript y CSS. Y quiero empezar explicando por qué creo que es importante que empezamos a evolucrarnos en el tema de sitios web estáticos. Primero, no es porque es cool simplemente estar con las novedades de las tecnologías. Tampoco, es porque querramos como desarrolladores una empresa tener un stack cool que diga, tengo React, tengo Redux, tengo GraphQL, Sinoq o tampoco es porque no nos gusta otra cosa que sea JavaScript, digo como frontends. Sino que realmente soluciona problemas de la vida real y voy a contar un poco la experiencia mientras estaba en el equipo encargado de las propiedades públicas. Primero, es que normalmente si bien existen aplicaciones basadas en WordPress normalmente entregamos contenido estático. Los blogs es contenido estático. Los sitios web institucionales es contenido estático. Entonces, si pensamos un visitante normal, va nuestro sitio web, el request llega al servidor, el servidor va nuestro CMS, nuestro CMS se conecta con la base de datos y luego después el contenido estático se devuelve. Sin embargo, podríamos pensar que si el contenido no cambia en el momento cuando se hace el request a cuando se devuelve y el usuario no va a interactuar con él podríamos eliminar el CMS y la base de datos para optimizar recursos. Lo primero que podemos pensar es que podemos utilizar un catch-up para generar esos assets estáticos. Siguiente, normalmente como desarrolladores cuando estamos haciendo algo en WordPress cada vez que hay una nueva funcionalidad hay muchas partes moviéndose. Cuando digo muchas partes moviéndose es que tanto el template engine como la lógica de WordPress están atadas. A la hora de como desarrollador crear un nuevo módulo y construirlo en el build de nuestro sitio no solo se desarrolla ese módulo nuevo que hicimos sino también otros componentes que no cambiaron nunca haciendo que nuestro proceso de release de una nueva funcionalidad tenga que mover otras partes que no son necesarias. Y bueno, luego tenemos nuestro sitio. Siguiente, en Typhoon tenemos aproximadamente 70 ingenieros de los cuales 20 tal vez son frontend. Es natural que en una empresa tan grande tengamos muchos proyectos que tienen un frontend. Y cuando digo normalizar nuestro stack es porque cuando teníamos que crear una nueva funcionalidad nosotros nos sentíamos como Ted Mosby siendo el comino entre la sal y la pimienta. O como podemos ver aquí. Porque nuestro frontend estaba atado a PHP y los frontend de otros o cuando digo frontend es la parte del UI de los proyectos estaban hechos en React. Y tenemos una comunidad de frontend bastante sincronizada donde tenemos un sistema de diseño que nosotros no podíamos utilizar. Y que teníamos que volver a hacer las cosas simplemente porque no teníamos esa normalización del stack. Y entonces, la pregunta vino o esta presentación se me ocurrió cuando en el equipo nos preguntábamos ¿puedemos hacer nuestro public site? El public site es www.tifon.com que está hecho en WordPress. Y esta fue mi cara. Claro. Tenemos experiencia. Anteriormente hicimos el developer portal para los que no han ido. Es nuestro sitio web donde tenemos toda la documentación y guías para poder ir con los APIs. Y este sitio web está hecho estático y está hecho en React. Entonces, cuando lo empezamos a hacer la primera herramienta que vino en nuestro curso fue Fenómico. Al momento cuando estábamos estando el proyecto Fenómico tenía, si bien ahora es un poco más robusto seguía en Alpha. Y la versión estable era la .21 que tenía muchas limitantes en las cuales una de ellas que era importante para nosotros era que no podíamos tener contenido que tenía diferentes APIs, simplemente una. Siguiente también es que conforme fue creciendo el proyecto necesitábamos tener diferentes layouts. Algo muy básico, pero nos dimos cuenta que con Fenómico era muy complicado de hacer. Entonces, tuvimos que movernos a la siguiente herramienta. Gatsby. Gatsby como Fenómico fue el director de sitio web estáticos con React. Y Gatsby nos gustó, fue nuestra decisión final para este proyecto porque era muy fácil generar páginas estáticas. Cuando digo páginas estáticas pensemos como un avautos acerca de, pensemos en un contact us y ese tipo de páginas. También soportaba múltiples nudos de contenido. Es decir, nosotros podíamos tener un contenido en API A y un API B, C, D, N cantidad. Y siguiente, ya hablo Luis de esto, un poco es que teníamos, bueno, podríamos utilizar GraphQL para obtener ese contenido. Sin embargo, esto de GraphQL también tenía su downside que era que necesitábamos aprender un nuevo lenguaje. Sin embargo, a la larga pensábamos que era valioso tener un nuevo lenguaje en nuestro stack porque la industria se está moviendo para ese lado. Siguiente, como WordPress, Gatsby tiene un director de plugins que son módulos para extenderlo. Y último, y no menos importante, una buena documentación. A diferencia de Phenomix, que teníamos que estar leyendo el código fuente para saber qué hacía. Y por último, que es más importante, son los resultados. Los resultados es que nuestro sitio bebe una conexión estándar, y no digo estándar de fibra, sino una conexión estándar que cargaba a 2.2 segundos. El primer de First Content Full Paint, o es cuando un usuario ya puede ver algo en la página, era en menos de un segundo. Y el home page al menos con todos los assets y scripts pesaba 1.3 megas. Siguiente, bueno, si tuve obstáticos al final, son HTMLs con CSS y un poquito de JavaScript. Entonces, es por default self-friendly. A diferencia de la single-page application que como ya comentaron, es que es gigante que lo que el servidor ve es un tag que dice script donde se carga app.js normalmente. Y siguiente, fue mucho más sencillo integrar continuous deployment. Cosa que con WordPress era mucho más complicado por la naturaleza que se mueve muchas cosas a la vez. Entonces, nuestro public site es un monolito de WordPress que queríamos hacerlo estático. Lo primero que podemos pensar es vamos a tener nuestro front-end en React, vamos a tener nuestro content API en WordPress y como WordPress ya tiene su REST API, era relativamente sencillo poder hacer esta migración. Y esa era nuestra reacción. React all the things. Sin embargo, nos dimos cuenta que Gatsby, que era la solución que queríamos usar, le faltaba algo, algo que no vimos al principio. Y es que Gatsby no tiene preview. Como se generan páginas estáticas, existe un tiempo en el cual yo empiezo el build y termino el build. Cuando digo build es que se generan todas las páginas estáticas. Ese es el preview. Entonces no podíamos hacer preview. No existía la forma y teniendo más de 15 editores manipulando diariamente el sitio web podemos imaginar cuánto tiempo perdido podrían tener los editores esperando a que se cargará el preview de esos cambios. Entonces ¿qué podíamos hacer? Y es ahí donde el concepto de perfect react framework salió dentro de las búsquedas. Esta no es más que una forma cool de decir que es un framework que sirve tanto para crear, que sirve tanto en el servidor como el cliente con básicamente el mismo código. Es decir, mi aplicación podría vivir en un servidor de contenido dinámico, es decir JavaScript o en este caso JavaScript o podría también ser totalmente estático, es decir, generar HTML. Y es ahí donde descubrimos Next.js. Next.js es un isomorphic framework para react, que nos permite crear aplicaciones y tiene la opción de poder exportar ciertas partes a un contenido estático. Next.js está hecho port site. Los que aún no han visto site es una empresa fundada por Guillermo, no me recuerdo el apeido, pero es un genio, es un genio. Y tiene muchos más proyectos que le recomiendo como frontends que son no máximo. Entonces, parte de ello Next.js solucionaba estos problemas que teníamos con el preview. Perdón. Y es bueno, lo vamos a comparar con Gatsby que creo que es lo mejor que podemos hacer. Y perdón si les muestro un poco de código, pero era la única forma que podían intentar de compararlo. Para los que react está hecho a base de componentes y todo lo que ven aquí es una página. Esta página es un simple componente react. Sin embargo, tiene algo distinto que una aplicación de react no tiene como tal. Y es que existe un nuevo método llamado get initial props que lo que hace y esto es llamémoslo solo de Next.js que lo que hace es facilitar la adquisición de los datos para que cuando yo monte o cuando yo cargue la página estos datos que en este caso puede ser nuestro WordPress API se cargue en el componente de una forma muy sencilla. Siguiente, las rutas estáticas. Hablábamos del about de ciertas páginas que sé que van a estar ahí y que no dependen de WordPress como tal. Pueden definirse en un simple objeto donde el primer parámetro es el slug y siguiente, tenemos dos propiedades. La primera es el page que es básicamente el template que utilizaré y el query. En este ejemplo de WordPress podría ser nuestro post ID. Y pueden decir jevser, pero mirá, la verdad que este ejemplo que diste es sencillo pero cómo se muestra cómo podría ser un ejemplo en la vida real. Este es el mapa donde exporto todas las páginas y posts de mi sitio web. Y si se dan cuenta no tiene más de 30 líneas. Routas dinámicas, hablábamos de preview. Una cosa que me gusta mucho es que Next.js como tal es agnóstico a la herramienta que utilicemos como servidor. En este caso, es express si miramos esta línea. Simplemente estoy llamando un servidor de express normal y lo que requiero es que a Next.js le mande cuatro parámetros. El primero es el request, el segundo es el response porque tiene que saber cómo va a devolver la llamada al endpoint. Tercero tenemos el template que va a ser en este caso sería si lo miramos en nuestro folder sería un notifications que dentro de folder de notifications tiene un single .js. Y por último los parámetros que definíamos en aquí. En este caso era title, pero podría ser ID y se lo mando como parámetro el ID y listo. Ya tengo service rendering para preview. Entonces suena que podíamos solucionar este problema. Sin embargo, al momento cuando todavía estaba en el equipo, nos dimos cuenta que el public site también tiene más de tres millones de visitantes mensuales. ¿Qué quiere decir eso? Que teníamos que tener cuidado en que la migración no afectara ninguno de esos tres millones. Siguiente, es que también tenemos servicios integrados, no solo devolvemos contenido estático. Tercero, es que hay una configuración bastante complicada para mí que no soy ops, que tenía WordPress y teníamos que solucionar. Y por último los editores tienen un customization API que era complicado, pero no imposible de crear. Entonces, yo sí estaba muy, muy emocionado de la parte de poder abstraer la parte de template de WordPress a algo que podía hacer WordPress más otra cosa en el futuro. Y como no lo podía hacer lo hice para mi sitio. Dije, esto es una muy buena idea. Ese es un proyecto opensource en mi sitio y si en un momento dado quieren tener una idea de cómo se creó, pueden forquear el proyecto y, bueno, contactarme por cualquier cosa. Este es la infraestructura de deployment que tengo en mi sitio web donde por medio de nuestro API cada vez que cambia nosotros en este caso podría hacer que hacemos un trigger a nuestra Lambda Function para crear un nuevo build. Un nuevo build donde pueda hacer el preview que posteriormente podría yo deployar. En el caso de mi sitio web yo tengo Travis que es mi herramienta de continuous integration y que es mi servicio de hosting. Ahora es de site también. Espero haberles dado un poquito de contexto en este mundo y, bueno, estoy abierto a la pregunta si tienen alguna. Muchas gracias. ¿Aguien tiene una pregunta? Justo la primera fila me he puesto atrás para... Hola, felicidades por la charla. Mira, el nex que has usado sería equivalente al NUSJS de VUEJS. Exacto. Vale, vale. ¿Tienes la referencia? Este es con React y el otro es con VUE. Vale, vale. No he trabajado con la parte de VUE pero nos resuelven el mismo problema. Es la misma filosofía. Esto es server rendering y envías la página al cliente, ¿no? Sí, la idea es que estas herramientas exportan HTMLs entonces nosotros ya no necesitamos un servidor que tenga Node o el servidor de producción no tiene que tener Node, no tiene que tener PHP sino simplemente tiene que ser capaz de resolver HTMLs que en sí nos hace más seguros porque no pueden hacer nada en cuestión de comunicarse con la base de datos directamente. ¿Alguna pregunta más? Que va a declarar que cuando digo estático no es que el usuario mire solo un HTML sin JavaScript. Es simplemente que lo que mira el servidor es un HTML y lo que se sirve al usuario es un HTML que luego monta React que luego ya puede ser cualquier cosa como llamadas una API y cuestiones dinámicas. Hola, muchas gracias por el track, ha sido muy interesante y lo único, me ha surgido la duda con el tema de la exportación, ¿cómo funciona realmente cada vez que modificas algo en el vaquén de WordPress se va publicando o se va haciendo con publicaciones que vas programando cada cierto tiempo, ¿cómo es la parte de exportación que comentabas? Bueno, eso depende son dos opciones, la opción en la cual miré a yo es que el previo API, como Next también es un framework para aplicaciones no es necesario crear un nuevo build, sino simplemente tener conectado un previo API de WordPress con la instancia de la aplicación corriendo en un servidor para que luego, después de los chequeos de QA se pueda hacer un nuevo build. En nuestro caso, lo que habíamos hecho es que el previo manda una instancia viva de la aplicación corriendo y cuando tú colocas publish este si genera un nuevo build y hay una latencia de dos minutos y medio en la cual genera la nueva versión. Entiendo que entonces el vaquén o sea, lo que comentabas hasta un momento está completamente separado, ¿no? Puedes tener los diferentes servidores o lo que quieras y directamente comunicarlo directamente, no internamente. Exacto, y otra cosa es de lado también de recursos es mucho más barato porque en vez de que me aguante tener 3 millones de visitantes al mes tenía simplemente ciertas llamadas a los servicios dinámicos. De lo contrario era MostravHTMLs. Y en cuanto a tema de SEO y demás nos afectaba porque tienes el tema publicado, todo el sitio lo tienes publicado realmente, ¿no? Sí, sí, sí. Y bueno, si quieren pueden buscar Jepser y van a ver que el sitio web se mira el extracto y se mira el título sin ningún problema.