Smashing Podcast Episodio 29 con Leslie Cohn-Wein: ¿Cómo Netlifica Dogfood The Jamstack?

En este episodio, le preguntamos cómo se ve hacer una prueba interna del Jamstack en Netlify. ¿Puede implementar una aplicación completa en una CDN? Drew McLellan habla con la ingeniera del personal de Netlify, Leslie Cohn-Wein, para averiguarlo.

Mostrar notas

• Sitio personal de Leslie
• Leslie en Twitter
• netlizar

Actualización semanal

• Una inmersión en React y Three.js usando react-three-fiber
  escrito por Fortuna Ikechi
• Mejores prácticas para el diseño de interfaz de usuario de comercio electrónico
  escrito por Suzanne Scacca
• Autenticación de aplicaciones React con Auth0
  escrito por Nefe Emadamerho-Atori
• De los expertos: Desarrollos globales de accesibilidad digital durante COVID-19
  escrito por robin christopherson
• ¿Qué hay de nuevo en Vue 3?
  escrito por Timi Omoyeni

Transcripción

Drew McLellan: es una galardonada especialista en frontend originaria de Austin, pero ahora vive en Dallas, Texas, a través de una temporada en la ciudad de Nueva York. Durante ese tiempo trabajando para agencias, creó sitios para clientes, como Nintendo, WorldPride y Jerry Seinfeld. Ahora es ingeniera de interfaz de personal en Netlify, donde, entre otras cosas, trabaja en la creación de la aplicación que usan los clientes para administrar su servicio e implementaciones. Entonces, sabemos que es una ingeniera frontend consumada, pero ¿sabías que, cuando vivía en la ciudad de Nueva York, se desempeñó como juez asistente de concurso de cocina de chili tres años seguidos? Y eso es realmente cierto. Mis grandes amigos, denle la bienvenida a Leslie Cohn-Wein. Hola leslie. ¿Cómo estás?

Leslie Cohn-Wein: Estoy genial.

Drew: Quería hablarles hoy sobre cómo Netlify come su propia comida para perros, para usar esa expresión encantadora, cuando se trata de construir en el Jamstack. Debería poner esto en contexto un poco diciendo que hasta hace unos meses, trabajábamos juntos en el mismo equipo en Netlify. Y cuando llegué allí, el proceso de desarrollo era realmente extraño para mí, incluso después de 20 años como desarrollador. Pensé que era realmente fascinante y que valía la pena explorarlo un poco, con una audiencia más amplia. Probablemente debería señalar que estamos hablando de esto porque es un estudio de caso genuinamente interesante y no es un gran anuncio patrocinado para Netlify. Todo el mundo debería echar un vistazo a Vercel. Pero creo que se pueden aprender muchas cosas valiosas al discutirlo, particularmente desde el punto de vista de Jamstack. Porque Netlify es un gran defensor del enfoque Jamstack y el servicio se ofrece al cliente y se basa en la idea de crear proyectos Jamstack. Pero el servicio también se construye utilizando esos principios. ¿no es así?

Leslie: Lo es, sí. Mucha gente piensa en esa arquitectura Jamstack como sitios estáticos, pero en realidad estamos analizando lo que significa construir una aplicación Jamstack con la interfaz de Netlify. Porque es una aplicación React que es una aplicación Jamstack completa que implementamos Netlify en Netlify, así que... Sí, realmente la estamos probando y superando los límites de lo que es posible.

Drew: Creo que a veces existe la idea de que Jamstack es excelente solo para sitios estáticos, como dices, y el aspecto de la API entra si quieres enviar un formulario a una dirección de correo electrónico y puedes hacer algo así de fácil, pero tú posiblemente pueda construir una aplicación web completa de esa manera. Pero, ¿estás haciendo eso, no?

Leslie: Sí, absolutamente. Nuestra aplicación, que habla específicamente de lo que ve si inicia sesión en app.netlify.com, funciona con... tenemos una API REST interna, pero la interfaz, como dije, es puro Jamstack. Entonces, tenemos nuestro propio paso de compilación, observamos la aplicación a medida que se compila en la aplicación y la implementamos en nuestro propio sistema.

Drew: Entonces, cuando hay un proceso de back-end involucrado, y siempre va a haber algún tipo de nivel de procesos de back-end, ya sabes, datos persistentes o, en el caso de Netlify, comenzando con una implementación o lo que sea, ese back-end simplemente ¿Se construye como una serie de API que luego pueden ser consumidas por la interfaz?

Leslie: Sí, entonces hay un par de modelos diferentes de cómo puedes hacer que esto funcione. En la mayoría de los casos, en nuestra aplicación, usamos la búsqueda del lado del cliente con React, ¿verdad? Por lo tanto, servimos una especie de shell estático de la aplicación y luego obtenemos la información del usuario de nuestra API REST interna en el momento de la solicitud. Jamstack es interesante porque hay algunas cosas que puedes preconstruir, y tratamos de confiar en eso cuando podemos. Y luego, cuando estemos hablando de algunos de los datos más dinámicos, usaremos esa búsqueda del lado del cliente para asegurarnos de que estamos obteniendo los datos más actualizados.

Drew: Creo que me sorprendió, cuando comencé a trabajar en la aplicación, cuánto se está logrando en la interfaz, particularmente cuando se trata de interactuar con API externas y demás. Sé que cuando Netlify interactúa con su proveedor de Git, va a GitHub y obtiene una lista de repositorios, todo eso sucede entre su navegador y GitHub. Y aparte de tal vez... pasar por una función sin servidor que pone algunos secretos en la solicitud o algo ligero como eso, la mayor parte de eso está sucediendo en una especie de Jamstack-y. No está pasando por un tipo de Netlify de infraestructura back-end central. Entonces, eso es bastante fascinante. Eso realmente va mucho más allá de un sitio estático con algunas llamadas a la API para hacer pequeñas cosas. Esa es la funcionalidad central real, ¿no es así? ¿Esa se está implementando en el navegador?

Leslie: Absolutamente. Realmente impulsa, creo, ese concepto de lo que es un ingeniero desarrollador frontend, ¿verdad? Y es algo que me empuja, como ingeniero frontend, a ser mejor y pensar más en ese tipo de... la capa API, que no es algo a lo que tradicionalmente he estado tan cerca. Trabajo más en la interfaz de usuario, los colores y los sistemas de diseño, por lo que realmente... de hecho, descubrí que trabajar en una aplicación Jamstack a escala me ha empujado a ser un mejor desarrollador.

Drew: Ser un desarrollador front-end no es saber CSS al pie de la letra, aunque eso es parte de ello. No es saber HTML de principio a fin, pero eso es parte de ello. También se está adentrando en este territorio que tradicionalmente estaba reservado a un ingeniero de back-end, lo cual es bastante interesante. ¿Netlify utiliza nuevos formatos de representación del lado del servidor?

Leslie: No que yo sepa.

Drew: Entonces, todo está literalmente hecho, como usted dice, sirve un shell, y luego se llena con solicitudes de regreso a diferentes puntos finales de API para llenarlo todo.

Leslie: Exacto.

Drew: ¿Y dices que es una aplicación React?

leslie: si Si. Reaccionar. Usamos React Redux en este momento, y en este momento somos PostCSS, pero también estamos experimentando con nuestra arquitectura CSS.

Drew: ¿No lo somos todos? Entonces, ¿construyes la aplicación en React y luego la implementas en Netlify?

leslie: si Quizás mi parte favorita de todo ese proceso es la magia de las vistas previas de implementación, que obtenemos a través de Netlify. Entonces, lo que sucede es que... estás trabajando en GitHub, aumentas tu PR. Entonces, abre su PR en GitHub, y eso creará automáticamente una compilación de su Vista previa de implementación de la aplicación. Por lo tanto, en realidad usamos Deploy Previews de la aplicación en sí para probar, para asegurarnos de que todo funcione como debería. Realizamos nuestras pruebas. Eso es lo que usamos para verificar manualmente durante la revisión del código. Entonces, tenemos toda esa implementación continua configurada directamente desde GitHub.

Leslie: Y luego, una de las otras cosas geniales que hemos configurado es que en realidad tenemos un par de sitios diferentes de Netlify que se extraen del mismo repositorio donde se encuentra nuestra aplicación. Entonces, tenemos nuestra aplicación, tenemos una instancia de Storybook que tiene una especie de componentes de interfaz de usuario para la aplicación. Entonces, tenemos nuestra propia aplicación, tenemos los componentes de la interfaz de usuario de Storybook y básicamente tenemos un sitio de Netlify que muestra nuestra interfaz de usuario de Storybook. Y luego también tenemos un tercer sitio que ejecuta un analizador de paquetes de paquetes web. Entonces, es una interfaz de usuario visual que le brinda un mapa de árbol, visualización de todos los paquetes de aplicaciones, y podemos medir su tamaño, y es solo un recordatorio para que verifiquemos dos veces. A medida que se realiza cada implementación de la aplicación, podemos verificar y asegurarnos de que no estamos haciendo nada extraño con el tamaño de nuestro paquete allí. Entonces, los tres sitios se generan en una solicitud de extracción de la aplicación. Por lo tanto, obtendrá enlaces para obtener una vista previa, esencialmente sus vistas previas de implementación, tanto de la aplicación Storybook como del perfil de esa aplicación para que podamos verificar.

Drew: Y con Deploy Previews, eso se convierte esencialmente en su entorno de ensayo, ¿verdad?

Leslie: Exacto. Realmente no ejecutamos un entorno de prueba tradicional, porque realmente confiamos en que nuestras vistas previas de implementación son esencialmente lo que se pondrá en marcha cuando presionemos el botón de combinación e iniciemos la compilación oficial de nuestra rama principal en nuestra aplicación principal. Por lo tanto, me encanta que podamos confiar en Deploy Previews como entorno de ensayo. Realmente confiamos en que va a igualar la producción. Lo estamos creando con todas las variables de producción, todo lo que... las variables de entorno, todo eso se crea en la vista previa de implementación. Entonces, es más o menos como una situación sin preocupaciones. Mientras su Vista previa de implementación esté funcionando, sabrá que la aplicación también funcionará.

Drew: Y supongo que, como organización, si su Vista previa de implementación no coincide con lo que se pone en marcha, entonces ese es un problema de servicio que Netlify quiere resolver. Entonces, en realidad funciona bastante bien desde ese punto de vista. Entonces, revisó una vista previa de implementación, todo se ve muy bien, el PR se fusionó. ¿Qué pasa entonces?

Leslie: Entonces, debido a que Netlify ejecuta toda nuestra implementación continua, esencialmente lo tenemos todo conectado para que cualquier combinación con nuestra rama principal inicie automáticamente una implementación de producción oficial con la aplicación. Entonces, por lo general, si usted es el desarrollador que fusionó su propio PR, aparecerá en el real... debe asegurarse de revisar sus pestañas dos veces, porque si tiene una Vista previa de implementación de la aplicación abierta y la aplicación, tienes que asegurarte de que normalmente quieres seguirlo en la aplicación real. Entonces, tienes que revisar tu ficha. Pero, sí, en la aplicación, por lo general entras, puedes ver los registros de compilación de esa combinación que acabas de iniciar, por lo que todo es automático. Y luego, tan pronto como se completen esos registros de compilación y el sitio esté activo, todo lo que tiene que hacer es actualizar la ventana del navegador y verá que todo lo que acaba de implementar debe actualizarse en la aplicación.

Drew: Y digamos que detectas un problema una vez que se activa, ¿qué haces entonces?

Leslie: Esa es una muy buena pregunta. Y tal vez una de mis cosas favoritas sobre el uso de Netlify incluso antes de trabajar en Netlify, esto fue como un poco de magia para mí, porque Netlify se ha incorporado, lo que llamamos, reversiones. Entonces, esencialmente cada implementación en Netlify... porque estamos usando esta arquitectura Jamstack, cada implementación es atómica. Entonces, lo que eso significa es que tiene este historial completo de cada tipo de implementación que haya realizado en un sitio, y puede retroceder instantáneamente a cualquiera de ellos. Entonces, si accidentalmente implementamos un error o algo se rompe, lo primero que hacemos generalmente es detener esa integración continua. Entonces, entraremos y es solo un botón en la interfaz de usuario de Netlify que dice: "Detener la publicación automática", y lo que hará es detener esa conexión con GitHub. Entonces, si mi compañero de equipo de repente también fusiona sus relaciones públicas, no vamos a volver a presentar el error, nada de eso va a suceder.

Leslie: Entonces, detenemos todas esas implementaciones automáticas. Y luego, todo lo que tengo que hacer es volver a mi lista de implementaciones y encontrar la última implementación en funcionamiento, presionar un botón más que dice "Publicar este" y se activa. Entonces, lo que eso hace es quitar esa presión para poder realmente regresar, mirar el código, descubrir qué sucedió realmente. A veces, eso significa hacer una reversión de Git en su rama principal y hacer que la rama principal vuelva a estar donde tenía que estar. Y a veces es una solución rápida o te vas a una rama y lo arreglas y ni siquiera necesitas preocuparte por volver a Git. Y luego, cuando esté listo para regresar, asegúrese de que todo esté funcionando en su Vista previa de implementación de la aplicación, y puede restablecer todo eso nuevamente. Entonces, tan pronto como comience esas implementaciones automáticas, básicamente estará de vuelta en el negocio.

Drew: Entonces, he detectado un problema aquí.

Leslie: Ah, oh.

Drew: está utilizando Netlify para implementar cambios en la aplicación Netlify. ¿Qué sucede si el error que ha implementado le impide retroceder? ¿Que haces entonces?

Leslie: Tengo pesadillas. No. En realidad, tenemos un par de formas que podrían manejar eso. Por lo tanto, si eliminamos la aplicación y no podemos usar la interfaz de usuario para realizar este proceso, nuestras vistas previas de implementación en realidad se ejecutan en nuestra API de producción. Entonces, lo que eso significa es que, incluso si la aplicación no funciona, todavía tenemos esas implementaciones atómicas. Entonces, si tiene un enlace de GitHub, tal vez de un PR antiguo o reciente, y tiene esa URL de vista previa de implementación, en realidad podría acceder a la vista previa de implementación de la aplicación y hacer cualquier cambio que necesite, volver atrás y publicar una implementación anterior. de la vista previa de implementación. Y todavía está afectando nuestra API de producción, por lo que seguirá afectando a la aplicación, y luego hará que la aplicación vuelva a funcionar. Es como una especie de emoji de cerebro que explota, pero es una forma de hacerlo. También podríamos publicar una implementación anterior de algunos de nuestros sistemas backend. Podríamos hacer que nuestros ingenieros de back-end lo publiquen por nosotros. O siempre puedes usar Git para revertir e intentar subir eso, pero da un poco de miedo porque no puedes ver lo que estás haciendo.

Drew: Supongo que solo necesitas una mente muy clara para manejar esa situación.

leslie: si

Drew: Pero es totalmente recuperable, al parecer.

leslie: si Bueno, y una vez que haya publicado su despliegue de trabajo, toda la presión se acabará. Esa es realmente la mejor parte. Y encontré esto trabajando en agencias también. Poder retroceder fue realmente un salvavidas para... También te hace sentir menos preocupado por la publicación de nuevos cambios. Si rompe algo, se tarda un segundo en hacerlo retroceder, lo que encaja muy bien con el tipo de movimiento rápido y sacar las cosas del modelo.

Drew: Definitivamente. Creo que, por lo general, este tipo de flujo de trabajo completo funciona mejor cuando se trata de cambios realmente pequeños. Quiero decir, idealmente desea crear una rama, implementar un pequeño cambio, aumentar un PR y luego volver a fusionarlo lo más rápido posible. Lo que obviamente funciona bien para ajustes y correcciones de errores y pequeñas cosas, pero no funciona tan bien para el trabajo de funciones principales cuando esa función puede tardar semanas o incluso meses desde que comienza hasta que está lista para implementarse. ¿Cómo manejas ese tipo de proceso?

Leslie: Sí, esa es una gran pregunta. Por lo tanto, recientemente comenzamos a usar indicadores de características un poco más. Antes de hablar un poco más sobre cómo hacemos eso, hablaré sobre lo que solíamos hacer. Entonces, antes de que usáramos indicadores de características, creo que todos están familiarizados con la idea de la rama de características de ejecución prolongada. Todos los odiamos, ¿verdad? Pero trabajaríamos en nuestras relaciones públicas más pequeñas. Combinaríamos cada uno de ellos individualmente, después de la revisión del código, en esta rama de características de ejecución más prolongada. Entonces, básicamente tendría toda su nueva función en un solo lugar, podría tener una Vista previa de implementación con la que puede probar esa nueva función. A veces, este modelo requería implementaciones coordinadas entre otros equipos. Entonces, cuando estábamos listos para decir: "Está bien, esta rama de características, estamos listos para fusionarla y ponerla en marcha", ocasionalmente eso significaba: "Está bien, debes asegurarte de que el backend ya haya implementado su cambio", así que lo que sea El trabajo de API que estamos haciendo en nuestra característica está listo para funcionar. Si hay documentos en nuestro sitio de documentos que deben publicarse al mismo tiempo que la función, debe coordinar y presionar los botones al mismo tiempo.

Leslie: Este modelo es... funcionó para nosotros, pero tienes razón, tal vez no fue el más fluido. En realidad, es un poco divertido, nuestro cofundador y director ejecutivo de Netlify, Matt Biilmann, lanzó nuestra función de análisis utilizando este proceso en el escenario de Jamstack Conf London el año pasado. Por lo tanto, usó nuestra función de implementación de bloqueo para básicamente tomar la vista previa de implementación de la nueva función de análisis y publicarla en vivo en el escenario. Eso es muy intersesante.

Leslie: Pero, como dijiste, es... tienes un poco menos de confianza. Todo sigue estando oculto en esta solicitud de extracción. Se vuelve un poco difícil de manejar. Alguien tiene que aprobar esa Solicitud de extracción final que, por lo general, es bastante grande. Eso es un poco abrumador. Entonces, hoy en día usamos principalmente indicadores de funciones. Usamos un servicio llamado LaunchDarkly, que básicamente nos permite envolver nuestra nueva interfaz de usuario de características con estas banderas, para que podamos seguir fusionando código continuamente, incluso si la interfaz de usuario no es algo que queremos que los clientes vean. Entonces, solo asegúrese de que en el entorno de producción su indicador de función esté desactivado, podemos implementar el código, fusionarlo y nadie... suponiendo que sea un usuario general, no verá esa nueva interfaz de usuario.

Drew: Entonces, un indicador de función es básicamente como un interruptor en el código que dice: "Si esta función está habilitada, use este nuevo código; de lo contrario, use este código antiguo".

Leslie: Exacto.

Drew: ¿Eso significa que obtienes una base de código desordenada con todas estas bifurcaciones en su lugar? ¿Cómo lidias con eso?

Leslie: Sí, creo que eso es... cualquiera que use banderas de funciones probablemente esté acostumbrado a este tipo de batalla ¿cuándo limpias las banderas de funciones? ¿Cuánto tiempo los dejas allí? Llegamos unas dos semanas después del lanzamiento de una función importante, tenemos recordatorios. Afortunadamente, LaunchDarkly recientemente configuró una función que notificará a Slack. Por lo tanto, puede conectarlo con Slack y simplemente le dirá: “Oye, tu indicador de función ha sido… Has estado en producción durante dos semanas. Ya es hora de que te asegures de limpiar tu bandera en el código”.

Leslie: Entonces, lo intentamos y lo limpiamos bastante rápido, pero es bueno saber que la bandera todavía está allí. Incluso si ha lanzado la función, significa que nuevamente, con un clic, puede ingresar y cambiar esa bandera hacia atrás si hay un error, si aparece algo. Por lo tanto, nos gusta dejarlos durante un tiempo, solo mientras la función realmente se está horneando, mientras la gente se acostumbra, para asegurarnos de que no haya problemas importantes. Pero luego intentamos y volvemos al código y es un poco de limpieza, por lo que no es un proceso ideal, pero generalmente eliminar el indicador no lleva mucho tiempo, solo está eliminando un par de líneas de código.

Drew: Entonces, supongo que el enfoque más simple para implementar un indicador de función podría ser simplemente una... como una variable de configuración en su aplicación que dice: "Esta función está activada o desactivada", pero luego necesita alguna forma de asegurarse de que está activado para las personas adecuadas y desactivado para las personas adecuadas. Y supongo que ahí es donde entra en juego un servicio como LaunchDarkly, porque toma eso... quiero decir, toma básicamente lo que es encender y apagar una variable a un nivel extremo, ¿no es así?

leslie: si Si. Eso es exactamente. Por lo tanto, hay formas en las que podríamos tener, incluso sin LaunchDarkly, básicamente configurar una variable de configuración nosotros mismos que manejamos de alguna manera. Una de las cosas que me encantan de LaunchDarkly es que hay diferentes entornos. Entonces, lo que podemos hacer es esencialmente activar un indicador de función para nuestras vistas previas de implementación. Entonces, cualquier persona que esté viendo internamente en Netlify, una vista previa de implementación de la aplicación puede tener acceso a la nueva función, puede probarla, pero, de nuevo, tan pronto como se active en producción, esa bandera se apagará. Entonces, hay muy poco... de nuevo, tiene que revisar su ficha y asegurarse de saber en qué segmento se encuentra, porque no quiere sorprenderse y pensar que ha lanzado algo que no lo hiciste, tienes que tener un poco de cuidado allí. Pero, en general, funciona bastante bien y LaunchDarkly también te permite hacer estos despliegues selectivos. Por lo tanto, puede implementar una función en algún porcentaje de su base de código o en un segmento de usuario específico, personas con un tipo específico de plan o un tipo específico de usuario. Por lo tanto, te permite mucho más control sobre a quién le estás liberando.

Drew: Sí. Eso puede ser realmente poderoso, supongo, particularmente con nuevas funciones o funciones que podría esperar que resuelvan un problema. Tal vez esté mejorando una función para que sea más comprensible, tal vez pueda probarla con el 10% de los usuarios y ver si están experimentando los mismos problemas y...

Leslie: Exacto. Es una excelente manera de obtener comentarios también, sí.

Drew: Supongo que usar LaunchDarkly de esta manera, en lugar de implementar su propia solución, es otro aspecto del enfoque de Jamstack, ¿no es así? Es simplemente usar una API que le brinda esta funcionalidad sin tener que preocuparse por cómo la implementa usted mismo y cómo desarrollarla y cómo mantenerla y mantenerla para que pueda subcontratarla, decir: "Correcto, estamos voy a usar esta API y todo lo demás está resuelto”.

Leslie: Sí. Sí, exactamente.

Drew: Por lo tanto, este enfoque le permite enviar pequeñas porciones de nuevas características a la producción esencialmente, pero simplemente están escondidas detrás de la bandera. Y luego, cuando todo esté listo para funcionar, puede voltear la bandera y puede volver a cambiarla rápidamente si algo sale mal.

Leslie: Sí, exactamente. Hace que nuestros lanzamientos sean un poco menos emocionantes. Solía ​​ser que estabas presionando estos botones grandes y había todo este código que se fusionaba y estabas viendo tus registros de compilación y era este momento de anticipación. Y ahora te subes a una llamada de Zoom, haces clic en un botón y está en vivo.

Drew: Sí. Creo que en el lanzamiento de la última característica, trabajé en Netlify, usamos este enfoque. Y habían sido semanas de trabajo para todo un equipo de personas, y recibimos una llamada de Zoom para coordinar el lanzamiento, y todos confirmaron que sus partes estaban listas. Y luego volteé la bandera de función y la encendí para todos los usuarios, y eso fue todo.

Leslie: Listo.

Drew: Y terminó en unos minutos y fue realmente decepcionante.

Leslie: Sí, es un poco triste.

Drew: No había palmas sudorosas, no había nada, que por supuesto es exactamente lo que quieres, ¿no es así? Así es como sabe que tiene un proceso sólido, si activar algo para todos no es gran cosa.

Leslie: Exacto. Y si tienes que retroceder, de nuevo, es así de simple, es un solo clic. Alivia algo de esa presión, ansiedad.

Drew: Entonces, presumiblemente, quiero decir, no todos los cambios serán solo cambios en la interfaz. A veces, habrá cambios en el back-end y, presumiblemente, también tienen sus propios indicadores de características en la mayoría de los sistemas de back-end. Entonces, también mencionaste documentos. ¿Hay alguna manera de coordinar todo esto junto? ¿Todo el mundo voltea sus banderas al mismo tiempo? ¿O cómo funciona eso?

leslie: si Entonces, esta es un área en la que estamos trabajando activamente en todos los equipos en este momento en Netlify, está trabajando para encontrar una solución que quizás nos permita vincular todo a una sola bandera en LaunchDarkly, que todos nuestros sistemas están usando , todas nuestras bases de código están usando. Entonces, en un mundo ideal, podríamos cambiar una bandera y decir: "Está bien, esto es alternar el nuevo punto final de la API que también se consume en la interfaz con esta nueva interfaz de usuario que está envuelta en una bandera de función, así como esta parte del sitio de documentos, que tiene nueva información sobre esta nueva característica”. Y le das la vuelta a esa bandera que afecta a todos esos repositorios. Todavía no estamos allí. Estamos trabajando en eso, pero estoy emocionado de ver si podemos hacer que todo esté coordinado y funcionando.

Drew: Netlify, como servicio, se adapta mucho a los sitios de construcción de esta manera. ¿El trabajo que usted y su equipo están haciendo usando el producto, realmente influyó en el desarrollo del producto?

Leslie: Yo diría que definitivamente lo hace. Todo el mundo siempre dice que no eres tu usuario, lo que creo que es cierto la mayor parte del tiempo, excepto a veces cuando eres tu usuario. Lo cual es divertido en Netlify porque creo que la mayoría de las personas en el equipo de interfaz en particular son personas que han usado Netlify antes como producto. Y ciertamente, debido a que usamos Netlify para implementar Netlify, nos encontramos con los mismos desafíos que creo que enfrentan algunos de nuestros usuarios. Entonces, de alguna manera, si nos encontramos con un problema, trataremos de comunicárselo al resto de la empresa. Lo mencionaremos en una llamada de ingeniería o llamaremos a nuestro CTO y le diremos: “Oye, esto es algo con lo que estamos luchando. ¿Hay algo que podamos integrar en el producto que lo haga más fácil para nosotros y para todos nuestros usuarios que están implementando cosas similares a las nuestras?” Por lo tanto, es una posición única en la que estar, pero es divertido ver cómo se desarrolla la hoja de ruta del producto.

Drew: Supongo que probablemente hay pocas personas que usan Netlify con tanta intensidad como lo hace Netlify.

leslie: si Si. Creo que eso es correcto. Observo Netlify tanto cuando lo construyo como cuando lo implemento, así que estoy bastante familiarizado con él.

Drew: Y luego, el fin de semana, trabajas en un proyecto paralelo y te encuentras nuevamente en Netlify.

leslie: si Eso es realmente muy cierto. Si. Si. si, de hecho

Drew: ¿Tiene algún ejemplo de cómo la dirección del producto se ha visto influenciada por el trabajo que ha realizado el equipo?

leslie: si Por lo tanto, recientemente lanzamos un nuevo tipo de panel de inicio para la aplicación que llamamos The Team Overview. Entonces, cuando iniciaba sesión en Netlify, aterrizaba en la página del sitio, que básicamente sería una larga lista de sus sitios. Y queríamos darles a las personas un poco más de un área de control de la misión donde puedan ver mucha información importante de un vistazo, tener acceso a las cosas que les serán más útiles. Y entonces, esa fue una nueva característica que construimos. En la iteración inicial, estamos tratando de sacarlo rápidamente, tenemos una pequeña tarjeta en esa interfaz de usuario que se vincula a sus últimas compilaciones. Le muestra cualquier construcción en todo su equipo, debería aparecer en esa tarjeta.

Leslie: Y al principio, en realidad no los habíamos vinculado con la compilación... el registro de visualización en sí. Entonces, era solo una lista donde podías consultarlo. Puede hacer clic en la página de compilaciones para obtener una vista similar. Pero en realidad estaba trabajando en algo durante el fin de semana, un sitio personal, y tenía activada esta descripción general del equipo y estaba molesto porque me di cuenta de que inicié sesión en Netlify y quería ver esta versión que estaba sucediendo de mi proyecto, y no podía simplemente hacer clic en él y llegar directamente a él. Tuve que hacer clic en la página de compilaciones y luego hacer clic de nuevo. Entonces, al día siguiente en el trabajo, entré y agregué ese cambio y vinculé esas compilaciones porque me estaba molestando. Entonces, ese fue un ejemplo de cómo simplemente darse cuenta al usar el producto, que había una oportunidad muy pequeña para mejorarlo. Y tomamos eso.

Leslie: Pero también tenemos otros ejemplos. Probablemente un poco más impactante. Una es que agregamos esta función de detección de formularios. Entonces, un poco de historia, si no está familiarizado, los formularios de Netlify son una función en Netlify que le permite crear un formulario de interfaz. Y Netlify hace todo el trabajo de gestión de envíos. Es algo así como su base de datos para su formulario que ha creado en su interfaz. Significa que no tiene que escribir ningún código del lado del servidor o una gran cantidad de JavaScript adicional para administrar los envíos de formularios. En realidad, cualquier sitio que haya implementado en Netlify, a medida que se realiza la compilación, nuestros bots de compilación analizan el HTML de su sitio en el momento de la implementación para detectar básicamente si tiene un formulario de Netlify al que Netlify debe prestar atención y administrar. Y esta detección de formularios, el bot de compilación está buscando eso, está habilitada de forma predeterminada.

Leslie: Pero lo que eso significa es que, como puedes imaginar, consume un poco de tu tiempo de compilación porque los bots tienen que buscar este paso adicional. Entonces, la aplicación de Netlify en sí, en realidad, no la estamos usando, no tenemos ningún formulario de Netlify en la aplicación en este momento. Entonces, este es un paso que básicamente agrega un poco a nuestro tiempo de compilación, pero no necesariamente tiene que suceder. Entonces, Netlify en realidad creó una nueva función que permite a cualquier usuario deshabilitar esa detección de formularios. Lo que eso significa es que puede desactivar esa configuración en la configuración de su sitio, los bots de compilación se dan cuenta de que no hay nada que necesiten buscar, por lo que ahorra un poco de tiempo de procesamiento adicional en las compilaciones.

Drew: Supongo que eso es genial en términos de productividad, porque las cosas se completan un poco más rápido.

Leslie: Exacto.

Drew: Pero también, como servicio medido, le permite sacar más provecho del tipo de asignaciones que tiene.

Leslie: Sí. Exactamente. Y entonces, esto fue algo que también escuchamos de algunos de nuestros usuarios y clientes, y también fue algo que notamos. Fue: “Bueno, no necesitamos este paso adicional en nuestro propio producto. Entonces, ¿hay alguna manera, algo que podamos dar a todos nuestros usuarios para hacer la vida de todos un poco más fácil, hacer que todos construyan un poco más rápido si no están usando esta función?

Drew: ¿Hay algún peligro? Quiero decir, dices que no eres tu usuario, pero con Netlify a menudo eres tu usuario. ¿Existe el peligro de que, con la intensidad con la que usa el producto, pueda pasar por alto al tipo de usuarios que solo lo usan muy a la ligera y todo podría volverse demasiado complejo y demasiado avanzado, y sería muy difícil de conseguir? empezó con?

Leslie: Esa es una gran pregunta. También hemos desarrollado nuestra función de investigación de usuarios en Netlify y nuestra función de ciencia de datos, y creo que, en general, confiamos mucho más en ellos que en mi experiencia anecdótica al usar e implementar la aplicación. Pero creo que todos esos datos se juntan para permitirnos tener una mejor idea de quién está usando Netlify, ¿a qué tipo de usuario le estamos hablando? Hay personas con diferentes tipos de necesidades. Tenemos personas en nuestros equipos iniciales que administran blogs y sitios personales, y también tenemos grandes empresas que lanzan grandes campañas de marketing y grandes aplicaciones web, no muy diferentes de Netlify. Por lo tanto, es emocionante ver crecer la base de usuarios y pensar en todos estos casos de uso y descubrir cómo podemos atender a todos esos usuarios. Y, ciertamente, usar más de nuestra funcionalidad de investigación para apoyarnos en comprender quiénes son esos usuarios, no solo nuestra experiencia interna.

Drew: Cuéntame, Leslie, sobre el servicio de captura de pantalla que tiene Netlify. Porque me pareció muy interesante.

leslie: si En la interfaz de usuario tenemos... cuando implementa un sitio en Netlify, en la interfaz de usuario, tenemos una pequeña captura de pantalla que le muestra normalmente cómo se ve la página de inicio del sitio que sintió. De hecho, es divertido que mencionáramos esto, porque estaba escuchando a Chris Coyier su episodio sobre Serverless no hace mucho, y también estaba hablando sobre cómo hacen capturas de pantalla en CodePen, que en realidad no es tan diferente de cómo lo hace Netlify. Pero básicamente ejecutamos Puppeteer para capturar esa captura de pantalla del sitio del usuario, y la forma en que se ejecuta todo es que está configurado con una función de Netlify. Entonces, esto es nuevamente, un ejemplo de nosotros haciendo dogfood con nuestro propio producto. Entonces, esencialmente usamos este punto final que es una función de Netlify dentro de nuestra propia aplicación para devolver la URL de esa imagen de la captura de pantalla, que luego podemos mostrar en la aplicación.

Drew: Entonces, las funciones de Netlify son la implementación de Netlify de una función sin servidor, ¿no es así? Básicamente, solo coloca un archivo JavaScript en una carpeta designada como parte de su fuente, y luego está disponible para ejecutarse como una función en la nube.

Leslie: Sí, exactamente.

Drew: Súper inteligente, ¿no?

leslie: si Es brillante. This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you're basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it's exciting because there's so much you can do, but that can make it a little intimidating also because there's so much you can do.

Drew: I sort of find it funny how it's like… that's seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it's just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. Si.

Drew: This sounds like a really nice way to be working, and a very modern way to we're working, but it can't be without its challenges, can it?

Leslie: Absolutely not. I think I've spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there's a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there's probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there's an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we're more familiar with or more comfortable using. So, in terms of challenges, I think it's opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there's so many different ways on there to… with the tooling that's available, to be able to attack a particular problem. At Smashing, we probably shouldn't say there's more than one way to skin a cat.

Leslie: Yikes.

Drew: What's interesting about the workflow as well, is that it's really intensively Git based, which I think suits… it's really developer friendly, isn't it? As a frontend engineer, something that's Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I'm very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you're talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it's really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone's going to have to rebase, everyone's going to have to communicate, or at least be aware of what happened. And so, it's not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you're doing, then you've got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that's one of the other things that Jamstack… You're introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they're getting. So, I always try to keep that in mind when I'm frustrated about how long something is taking to build, but certainly I think that's an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don't deploy a build if a test fails, but at the same time, then you've got to run all those tests.

Leslie: So, it's this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you're doing your due diligence before you actually deploy something. And we're playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you're then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn't the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they're working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we're growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I'm just aware of who's managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I've seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there's an error that got thrown, either from Netlify or from your own code, it'd be nice to be able to link directly to that log line. So, that's sort of a fun, small improvement that I've been thinking about a bit. And that's not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I'm still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it's really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn't want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn't it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it's exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it's a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we've been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that's always a big question. I mentioned Cypress before, we've been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I've been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that's been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I'm starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That's exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she's @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?