Smashing Podcast Episodio 22 con Chris Coyier: ¿Qué es Serverless?

Hoy, estamos hablando de arquitecturas Serverless. ¿Qué significa eso y en qué se diferencia de cómo podríamos construir sitios actualmente? Hablé con Chris Coyier para averiguarlo.

Mostrar notas

• Micrositio de Chris El poder de Serverless para desarrolladores front-end
• Chris en Twitter
• Podcast de ShopTalk Show

Actualización semanal

• "Configuración de Redux para su uso en una aplicación del mundo real"
  por Jerry Navi
• “¿Se puede diseñar un sitio web para los cinco sentidos?”
  por Suzanne Scacca
• "Creación de un blog estático con Sapper y Strapi"
  por Daniel Madalitso Phiri
• "Una guía práctica para recorridos de productos en aplicaciones React"
  por Bendición Krofegha
• “Cómo crear un Porsche 911 con Sketch,”
  por Nikola Lazarevic

Transcripción

Drew McLellan: Es un diseñador y desarrollador web que quizás conozcas de CSS-Tricks, un sitio web que comenzó hace más de 10 años y que sigue siendo un fantástico recurso de aprendizaje para aquellos que crean sitios web. Es el cofundador de CodePen, la comunidad y el área de juegos de codificación basada en navegador que utilizan los front-enders de todo el mundo para compartir lo que hacen y encontrar inspiración en aquellos a quienes siguen. Junto a Dave Rupert, es el coanfitrión de ShopTalk Show, un podcast sobre creación de sitios web. Entonces, sabemos que sabe mucho sobre desarrollo web, pero ¿sabías que una vez ganó una competencia de comer perros calientes usando solo su encanto? Mis grandes amigos, denle la bienvenida a Chris Coyier. Hola cris, como estas?

Chris Coyier: Oye, estoy genial.

Drew: Quería hablarles hoy, no sobre CodePen, y no necesariamente quiero hablarles sobre CSS-Tricks, que es uno de esos increíbles recursos que estoy seguro que todos saben que aparece justo en la parte superior de Google. Resultados de búsqueda al buscar respuestas sobre cualquier pregunta de desarrollo web. Aparece su rostro y hay una publicación de blog útil escrita por usted o uno de sus colaboradores invitados.

Chris: Oh, en realidad solía hacer eso. Hubo un... no sé, probablemente fue durante la época en que Google tenía esa extraña red social. ¿Qué fue eso? ¿Google Mas?

Drew: Ah, además, sí.

Chris: Sí, donde asociaban un sitio web con una cuenta Plus, por lo que mi cuenta Plus tenía un avatar, y el avatar era yo, por lo que aparecía en los resultados de búsqueda. Creo que esos días se han ido. creo que si tu...

Drew: eso creo, si-

cris: si

Drew: Pero quería hablar contigo sobre algo que ha sido un poco más una especie de interés secundario tuyo, y ese es este concepto de arquitecturas sin servidor.

Chris: Mm (afirmativo).

Drew: Esto es algo sobre lo que has estado aprendiendo más durante un tiempo. ¿Está bien?

cris: sí, sí. Solo soy un fan. Parece un ajuste natural a la evolución del desarrollo front-end, que es donde siento que tengo, al menos, algo de experiencia. Me considero mucho más... mucho más útil en el front-end que en el back-end, no es que yo... lo hago todos estos días. Llevo tanto tiempo que no tengo miedo de mirar un pequeño código de Ruby, eso es seguro. Pero prefiero el frontal. Lo he estudiado más. He participado en proyectos más a ese nivel, y luego aparece este pequeño tipo de nuevo paradigma que dice: "Puedes usar tus habilidades de JavaScript en el servidor", y es interesante. ¿Sabes? Así es como lo pienso. Hay mucho más que eso, pero es por eso que me importa, es porque siento que es como si los desarrolladores front-end hubieran profundizado tanto en JavaScript. Y ahora podemos usar ese mismo conjunto de habilidades en otros lugares. Muy bien.

Drew: Parece que se ha abierto un mundo completamente nuevo, mientras que si fueras solo un codificador de front-end... Digo, solo un codificador de front-end, no debería. Si usted es un codificador front-end y está acostumbrado a trabajar con un colega o un amigo para que lo ayude con la implementación del back-end, de repente eso se abre. Y es algo que usted mismo puede administrar más de toda la pila.

cris: sí, sí. Eso es todo.

Drew: Dirigiéndose al elefante en la habitación, justo en la parte superior. Estamos hablando de serverless y, obviamente, nombrar las cosas es difícil. Todos sabemos eso. La arquitectura sin servidor no significa que no haya servidores, ¿verdad?

Chris: Creo que es obligatorio, como si este es el primer podcast que escuchas de él, o en el primero... solo escuchas la palabra "sin servidor" en la primera docena de veces que la escuchas, es obligatorio que tener una reacción visceral y tener este tipo de "Oh, pero todavía hay servidores". Esta bien. Si eso te está sucediendo en este momento, solo debes saber que es un paso obligatorio en esto. Es como cualquier otra cosa en la vida. Hay etapas para la comprensión. La primera vez que escuchas algo, debes rechazarlo un poco, y solo después de una docena de veces, o después de que se haya demostrado que vale un poco para ti, puedes ingresar a las etapas posteriores. de comprensión aquí. Pero la palabra ha ganado, así que si todavía estás luchando contra la palabra "sin servidor", odio decirte que el tren ha salido de la estación allí. La palabra ya tiene éxito. No vas a ganar este. Lo siento mucho.

Chris: Pero sí creo que es interesante que... está empezando a ser como, tal vez en realidad no hay servidores involucrados a veces. Creo que una de las cosas que encerró el concepto sin servidor fue AWS Lambda. Fueron como los primeros en la escena. Una lambda es como una función que le das a AWS y la coloca en el cielo mágico y luego... tiene una URL, y puedes presionarla y ejecutará esa función y devolverá algo si así lo deseas. ¿Sabes? Eso es solo HTTP o lo que sea. Así es como funciona, que... la primera vez que escuchas eso, piensas: “¿Por qué? No me importa." Pero entonces, hay algunas cosas obvias. Podría conocer mis claves API a las que nadie más tiene acceso. Es por eso que ejecuta back-end para empezar, es que conoce cosas secretas que no tienen que estar en JavaScript en el lado del cliente. Entonces, si necesita comunicarse con una base de datos, puede hacerlo. Puede hacerlo de forma segura sin tener que exponer las claves API en otro lugar. O incluso dónde están esos datos o cómo se obtienen, es...

Chris: Así que eso es genial. Puedo escribir una función que se comunique con una base de datos, obtenga algunos datos y los devuelva. Frio. Entonces, Lambda es eso, pero AWS funciona. Tienes que elegir una región. Estás como, “No lo sé. ¿Dónde debería estar, Virginia? ¿Oregón? ¿Debo elegir el de Australia? No sé." Tienen 20, 30. Ni siquiera sé cuántos tienen en estos días, pero incluso las lambdas tenían regiones. Ellos, creo, en estos días tienen Lambda@Edge, lo que significa que son todas las regiones, lo cual es genial. Pero fueron los primeros, y ahora todo el mundo tiene algo como Lambda. Todos los servicios en la nube. Quieren algún tipo de servicio en este mundo. Uno de ellos es CloudFlare. CloudFlare tiene trabajadores. Tienen muchas más ubicaciones que AWS, pero también lo ejecutaron en un momento diferente... de la forma en que un trabajador de CloudFlare... es similar a un lambda en el que puede ejecutar Node. Puede ejecutar JavaScript. También puede ejecutar una serie de otros idiomas, pero... Creo que en gran medida, el lenguaje más interesante es JavaScript, solo por su prevalencia.

Chris: Ocurre solo en el nivel de CDN, que supongo que es un servidor, pero tiendo a no pensar en las CDN como un servidor. No tan obviamente como otra cosa. Está empezando a sentirse aún más sin servidor últimamente. ¿Es un CDN un servidor? Quiero decir, supongo que es una computadora en alguna parte, pero se siente aún menos como un servidor.

Drew: Parece que, sí, una CDN puede ser un servidor, pero es la versión más mínima de un servidor. Es como un servidor delgado, si lo desea.

cris: si Por supuesto.

Drew: Está bien. Escuché que dijo... No puedo recordar la fuente a la que dar crédito, desafortunadamente, pero escuché que la tecnología serverless se describe como "como usar un servicio de viajes compartidos como Uber o Lyft" o lo que sea. Puede estar sin automóvil y no tener un automóvil, pero eso no significa que nunca use un automóvil.

Chris: Sí, eso no significa que los autos no existan. Eso es bueno.

Drew: Simplemente convoca uno cuando lo necesita, pero al mismo tiempo, no está pagando el costo inicial de compra de un automóvil. No estás pagando mantenimiento o combustible o-

Chris: Correcto, y el precio también tiene sentido, ¿verdad? Qué lindo. Esa es una buena analogía, creo. Y luego, debido a que también está en el nivel de CDN, solo intercepta las solicitudes HTTP que ya están ocurriendo, lo que significa que no le pregunta... no le envía una solicitud y le devuelve una solicitud. Simplemente sucede durante la solicitud de forma natural, lo que también hace que se sienta menos servidor. No sé, es interesante. Seguro que es interesante. Sin embargo, es un gran problema que hayas mencionado el tema de los precios. Que sólo pagas por lo que usas. Eso también es significativo, porque... digamos, usted es un desarrollador de back-end, que está acostumbrado a hacer girar servidores toda su vida. Y corren con los costos: “Necesito este tipo de servidor con este tipo de memoria y este tipo de CPU y este tipo de especificaciones. Y esto es lo que va a costar”. Serverless aparece y corta la cabeza de ese precio.

Chris: Entonces, incluso si eres un desarrollador de back-end al que no le gusta mucho esto, que simplemente no les gusta, como si tu conjunto de habilidades fuera el mismo a lo largo de los años, comparas el precio. y estás como, “¿Qué? ¿Podría estar pagando el 1% de lo que estaba pagando antes?” No se te permite no preocuparte por eso, ¿verdad? Si eres un desarrollador de back-end que está pagando cien veces más por su servicio de lo que necesitan pagar, entonces eres un poco malo en tu trabajo. Perdon por decir. Esto ha aparecido y ha hecho añicos los precios de muchas maneras. Tienes que preocuparte por eso. Y es genial que alguien más lo esté... No es como si no tuvieras que preocuparte por la seguridad en absoluto, pero no es tu servidor. No tiene... su lambda o función de nube, o su trabajador, o lo que sea, no está sentado en un servidor que está justo al lado de algunos datos realmente confidenciales en su propia red. No está justo al lado de su base de datos.

Chris: Si alguien escribe código que de alguna manera trata de expulsarse del trabajador o de la lambda, o lo que sea, y trata de obtener acceso a otras cosas en su camino, no hay nada que obtener. Entonces, la seguridad también es un gran problema, así que nuevamente, si ese es su trabajo como administrador del servidor, es ocuparse de la seguridad de esta cosa. Ejecutándolo, ejecutando ciertas cosas en Lambda, solo obtienes algo de seguridad natural, lo cual es genial. Entonces, es mucho más barato. Es mucho más seguro. Fomenta estas pequeñas arquitecturas modulares, que pueden ser una buena idea. Parece ser dominó tras dominó de buenas ideas aquí. Por eso es notable. ¿Sabes?

Drew: Sí, quiero decir, tradicionalmente con una arquitectura basada en servidor que hemos estado ejecutando durante décadas en la web, tienes un servidor web que ejecutas tú mismo. Contiene su código de front-end, su código de back-end, su base de datos y todo. Luego, debe mantener eso y mantenerlo en funcionamiento y pagar las facturas, e incluso si no se usa, está acumulando facturas. El usuario haría una solicitud y construiría todo ese material de consulta HTML desde la base de datos, y lo enviaría todo al navegador. Ese proceso funciona. Así es como se construyen muchas cosas. Es probablemente la mayor parte de cómo se construye la web. Así es como funcionan cosas como WordPress. ¿Es este realmente un problema que debemos resolver? Quiero decir, hemos hablado un poco sobre los costos. ¿Cuáles son los otros tipos de problemas con eso, que estamos... que debemos abordar, y que sin servidor podría ayudarnos?

Chris: Sí, los problemas con el enfoque de la vieja escuela. Sí, no sé, tal vez no haya ninguno. Quiero decir, no estoy diciendo que toda la web necesite cambiar todo... todo de la noche a la mañana. No sé. Tal vez no realmente, pero creo que abre puertas. Parece que, cuando llegan buenas ideas como esta, cambian lentamente la forma en que funciona la web. Entonces, si hay algún CMS que está construido de alguna manera que espera que haya una base de datos allí, significa que tal vez los hosts del futuro comenzarán a aprovechar esto de maneras interesantes. Tal vez le parezca que todavía es solo un servidor tradicional, pero los propios hosts lo han convertido, cómo funcionan, en arquitecturas sin servidor. Entonces, ni siquiera sabe realmente lo que está sucediendo, pero han encontrado una manera de reducir sus costos alojando las cosas que necesita sin servidor. Tal vez sí, ni siquiera necesita preocuparse como desarrollador, pero a un nivel meta, eso es lo que está sucediendo. Quizás. No sé.

Chris: Tampoco significa que... Las bases de datos sigan ahí. Si resulta que arquitectónicamente tener una base de datos relacional es la forma correcta de almacenar esos datos, genial. Lo menciono porque este mundo de Serverless está creciendo al mismo tiempo que JAMstack. Y JAMstack es esta arquitectura que dice: "Debería servir su sitio web desde hosts estáticos, que no ejecutan nada excepto..." Son como pequeños CDN. Son como, “No puedo hacer nada. No ejecuto PHP. No manejo Ruby. no corro nada. Me ejecuto en un pequeño servidor web que está diseñado solo para servir archivos estáticos".

Chris: “Y luego, si necesita hacer más que eso, si necesita extraer datos de una base de datos relacional, hágalo en otro momento, no en el servidor. Puede hacerlo en un proceso de compilación con anticipación y extraer esas cosas de la base de datos, compilar previamente los archivos estáticos y los serviré, o hacerlo en tiempo de ejecución”. Lo que significa que obtienes este caparazón de un documento, y luego hace una solicitud de JavaScript para obtener algunos datos y luego los completa. Así que lo hace antes o después de tiempo, pero eso no significa "No use una base de datos relacional". Simplemente significa, "No hacer que el servidor lo genere en el momento de la solicitud del documento", lo cual es un... no sé, es un pequeño cambio de paradigma.

Chris: Tampoco es solo JAMstack. También estamos viviendo en la época de los marcos de JavaScript. Vivimos en una época en la que se empieza a esperar un poco más que la forma en que se inicia una aplicación de JavaScript es que monta algunos componentes y, a medida que esos componentes se montan, solicita los datos que necesita. Entonces, puede ser algo natural que algo como un sitio web de React sea como: “Bueno, solo presionaré una función sin servidor para obtener los datos que necesita. Golpea esencialmente una API JSON. Obtengo los datos JSON que necesito y me construyo a partir de esos datos, y luego los represento en la página”. Ahora, si eso es bueno o malo para la web, es como, “No lo sé. Demasiado. El barco ha zarpado. Así es como mucha gente está construyendo sitios”. Son solo cosas renderizadas por el cliente. Entonces, JavaScript moderno y sin servidor van de la mano.

Drew: Supongo que no tienes que vender al por mayor... mirar una arquitectura u otra. Hay un área en el medio donde partes de una infraestructura pueden ser más tradicionales y partes podrían no tener servidor, ¿supongo?

cris: si Bueno, están tratando de decirte eso de todos modos. Cualquiera que quiera venderte cualquier parte de su arquitectura dice: “No tienes que comprar todo ahora. Solo hazlo un poco”. Porque, por supuesto, quieren que sumerjas el dedo del pie en lo que sea que estén vendiendo, porque una vez que lo sumerges, las posibilidades de que te caigas a la piscina son mucho mayores. Entonces, creo que… no es mentira, aunque, necesariamente, aunque encuentro un poco menos de suerte en… no quiero que mi stack sea un poco de todo. Creo que hay algo de muerte técnica ahí que no siempre quiero tragarme.

Drew: Mm (afirmativo).

Chris: Pero es posible hacerlo. Creo que el más citado es... digamos que tengo un sitio que tiene un elemento de comercio electrónico, lo que significa... y digamos comercio electrónico a gran escala, así que 10 000 productos o algo así, que esta arquitectura JAMstack no ha llegado al punto en que eso siempre es particularmente eficiente para reconstruir eso estáticamente. Entonces, el pensamiento dice: "Entonces no lo hagas". Deje que esa parte se hidrate de forma natural con… acceda a las funciones sin servidor y obtenga los datos que necesita, y haga todo eso. Pero el resto del sitio, que no lo es... no hay tantas páginas, no hay tantos datos, podrías pre-renderizar o lo que sea. Así que un poco de ambos.

Drew: Por supuesto, muchas personas están lidiando con sistemas heredados que... alguna base de datos antigua que se creó en la década de 2000 a la que pueden pegar una especie de capa de API JSON encima...

cris: si

Drew: … y construya algo más moderno, y tal vez sin servidor, y luego aún interactúe con esos sistemas heredados pegándolos por completo de una manera extraña.

cris: si Eso sí me gusta, ¿no? No lo son… la mayoría de los sitios web ya existen. ¿Cuántos de nosotros somos sitios web completamente nuevos? La mayoría de nosotros trabajamos en alguna basura que ya existe y que debe ser arrastrada al futuro por alguna razón, porque no sé, los desarrolladores quieren trabajar más rápido, o ya no puedes contratar a nadie en COBOL, o lo que sea. es. ¿Sabes?

Drew: Por lo que respecta a la terminología, estamos hablando de JAMstack, que es esta metodología de ejecutar un código prácticamente en el navegador, sirviéndolo desde una CDN. Entonces, no tener nada dinámico en el servidor. Y luego, cuando hablamos de sin servidor, estamos hablando de esos pequeños fragmentos de funcionalidad que se ejecutan en su servidor en otro lugar. ¿Está bien? Que estábamos hablando de estas funciones de la nube como...

Chris: Sí, quiero decir, resulta que ambas son ideas candentes en este momento. Así que es un poco fácil hablar de uno y hablar del otro. Pero no necesariamente tienen que estar juntos. Podría ejecutar un sitio JAMstack que no tiene nada que ver con nada sin servidor. Simplemente lo está haciendo, simplemente crea previamente el sitio y lo ejecuta, y puede usar serverless sin tener que preocuparse por JAMstack. De hecho, CodePen no hace nada de JAMstack. No es que queramos hablar necesariamente de CodePen, pero es una aplicación de Ruby on Rails. Se ejecuta en un montón de instancias de AWS EC2 y en una variedad de otras arquitecturas para que esto suceda. Pero usamos cosas sin servidor siempre que podemos para lo que podemos, porque es barato y seguro, y simplemente una forma agradable de trabajar. Por lo tanto, no hay JAMstack en uso, pero no hay servidor en todas partes.

Drew: Eso es bastante interesante. ¿Qué tipo de tareas realiza sin servidor en CodePen?

Chris: Bueno, hay un montón de cosas. Uno de ellos es, creo, con suerte bastante obvio, necesito... el punto de CodePen es que escribes cada HTML, CSS y JavaScript en el navegador y lo muestra frente a ti, ¿verdad? Pero también puede elegir idiomas de preprocesador. Digamos que te gusta Sass. Activas Sass en el CSS y escribes Sass. Bueno, algo tiene que procesar el Sass. En estos días, Sass está escrito en Dart o algo así.

Chris: Teóricamente, podrías hacer eso en el cliente. Pero estas bibliotecas que realizan preprocesamiento son bastante grandes. No creo que quiera enviarte toda la biblioteca de Sass, solo para ejecutar esa cosa. No quiero… es solo que no, esa no es la arquitectura correcta para esto necesariamente. Tal vez sea más adelante, quiero decir, podríamos hablar de basura fuera de línea, yada, yada, Web Workers. Hay un millón de cosas arquitectónicas que podríamos hacer. Pero así es como funciona ahora, hay una lambda. Procesa Sass. Tiene un pequeño, pequeño, pequeño, pequeño trabajo.

Chris: Le envías esta gota de Sass y te devuelve cosas, que es el CSS procesado, tal vez un mapa del sitio, lo que sea. Tiene un pequeño trabajo y probablemente paguemos por esa lambda, como cuatro centavos o algo así. Porque las lambdas son increíblemente baratas y también puedes martillarlas. No tienes que preocuparte por la escala. Simplemente golpea esa cosa tanto como quieras y tu factura será asombrosamente barata. Hay momentos en los que serverless comienza a cruzar la línea de ser demasiado caro. No sé qué es eso, no soy tan maestro en cosas así. Pero, en general, cualquier cosa sin servidor que hagamos, básicamente... casi todas contamos como gratis, porque es así de barato. Pero hay uno para Sass. Hay uno por Menos. Hay uno para Babel. Hay uno para TypeScript. Hay uno para... Todas esas son lambdas individuales que manejamos. Aquí hay algo de código, dáselo a la lambda, regresa y hacemos lo que sea que vayamos a hacer con él. Pero lo usamos para mucho más que eso, incluso recientemente.

Chris: He aquí un ejemplo. Cada Pen en CodePen tiene una captura de pantalla. Eso es genial, ¿verdad? Entonces, la gente hace una cosa y luego necesitamos un PNG o un JPEG, o algo de eso, para que podamos... de esa manera cuando lo twitteas, obtienes una pequeña vista previa. Si lo compartes en Slack, obtienes una pequeña vista previa. Lo usamos en el sitio web mismo para renderizar... en lugar de un iframe, si pudiéramos detectar que el Pen no está animado, porque la imagen de un iframe es mucho más clara, ¿por qué no usar la imagen? No es animado de todos modos. Solo ganancias de rendimiento como esa. Entonces, cada una de esas capturas de pantalla tiene una URL, obviamente. Y lo hemos diseñado para que esa URL sea en realidad una función sin servidor. es un trabajador Entonces, si esa URL se ve afectada, podemos verificar rápidamente si ya tomamos esa captura de pantalla o no.

Chris: CloudFlare Workers lo habilita, porque CloudFlare Workers no es solo una función sin servidor, sino que también tiene un almacén de datos. Tienen esta cosa llamada almacén de clave-valor, por lo que la identificación de eso, podemos verificarla muy rápido y será, "Verdadero o falso, ¿lo tienes o no?" Si lo tiene, lo sirve. Y lo sirve a través de CloudFlare, que es súper rápido para empezar. Y luego te da toda esta habilidad también. Debido a que es una imagen CDN, puede decir: “Bueno, sírvala en el formato óptimo. Sírvelo como estas dimensiones. No tengo que hacer la imagen en esas dimensiones. Simplemente pones las dimensiones en la URL y regresa con ese tamaño, mágicamente. Así que eso es muy bueno. Si no lo tiene, le pide a otra función serverless que lo haga realmente rápido. Así que lo hará y luego lo pondrá en un balde en alguna parte... porque tienes que tener un origen para la imagen, ¿verdad? Tienes que alojarlo en algún lugar por lo general. Así que lo ponemos en un balde S3 muy rápido y luego lo servimos.

Chris: Así que no hay servidor de colas, no hay nada. Es como si las funciones sin servidor administraran la creación, el almacenamiento y el servicio de estas imágenes. Y hay como 50 millones u 80 millones de ellos o algo así. Es mucho, por lo que maneja eso como escala bastante bien. Ni siquiera lo tocamos. Solo pasa. Todo sucede súper rápido. Super bonito.

Drew: Supongo que... bueno, una función sin servidor se adapta idealmente a una tarea que necesita muy poco conocimiento del estado de las cosas. Quiero decir, mencionaste la capacidad de CloudFlare para almacenar pares clave-valor para ver si ya tienes algo en caché o no.

cris: si Sin embargo, eso es lo que están tratando de resolver con esos. Esos pares clave-valor, es que... Creo que tradicionalmente era cierto. Son como, "Evita el estado en la cosa", porque simplemente no puedes contar con eso. Y los trabajadores de CloudFlare dicen: "Sí, en realidad, puedes lidiar con el estado, hasta cierto punto". No es tan elegante como… no sé, son valores clave, por lo que es una clave en un valor. No es como una fantasía relacional anidada. Así que probablemente haya algunos límites para eso. Pero estos son días de bebé para esto. Creo que esas cosas van a evolucionar para ser más poderosas, por lo que tienes cierta capacidad para hacer cosas similares a las de un estado.

Drew: Y a veces la limitación, ese tipo de capacidad limitada para mantener el estado, o el hecho de que no tienes... no quieres mantener ningún estado, te empuja a una arquitectura que te da este tipo de... Bueno, cuando hablamos de la filosofía de software de “Pequeñas piezas sueltas”, ¿no?

Chris: Mm (afirmativo).

Drew: Donde cada pequeño componente hace una cosa y la hace bien. Y realmente no sabe sobre el resto del ecosistema que lo rodea. Y parece que realmente se aplica a este concepto de funciones sin servidor. ¿Estás de acuerdo?

cris: si Creo que podrías tener un debate filosófico sobre si es una buena idea o no. ¿Sabes? Creo que a algunas personas les gusta el monolito, por así decirlo. Creo que es posible... hay maneras de exagerar esto y hacer demasiadas piezas pequeñas que son demasiado difíciles de probar por completo. Es bueno tener una prueba que diga: “Oh, me pregunto si mi función Sass está funcionando. Bueno, escribamos una pequeña prueba para ello y asegurémonos de que así sea”. Pero digamos, lo que le importa al usuario es una serie de siete de esos. ¿Cómo se prueban los siete juntos? Creo que la historia se vuelve un poco más complicada. No sé cómo hablar de manera súper inteligente a todas esas cosas, pero sé que no es necesariamente eso, si sigues con todas las funciones sin servidor, automáticamente es una arquitectura mejor que cualquier otra arquitectura. Me gusta. Me razona muy bien, pero no sé si es el final de todas las arquitecturas. ¿Sabes?

Drew: Para mí, se siente muy similar a la web, en eso... así es exactamente como funciona HTML, ¿no es así? Usted entrega algo de HTML y el navegador luego irá y buscará sus imágenes, buscará su JavaScript y buscará su CSS. Parece que es una expansión de eso -

cris: es agradable

Drew: … tipo de idea. Pero una cosa que sabemos sobre la web es que está diseñada para ser resistente porque la red es frágil.

Chris: Mm (afirmativo).

Drew: ¿Qué tan robusto es el tipo de enfoque sin servidor? ¿Qué pasa si algo… si uno de esos pedacitos se va?

Chris: Eso sería muy malo. ¿Sabes? Sera un desastre. Su sitio se caería como cualquier otro servidor, si se cae, supongo.

Drew: ¿Hay formas de mitigar eso, que son particularmente...

cris: no lo sé.

Drew: … adecuado para este tipo de enfoque, que has encontrado?

cris: tal vez Quiero decir, como dije, una cosa robusta realmente súper elegante podría ser... digamos que visita CodePen y digamos que hay una implementación de JavaScript de Sass y notamos que está en una red bastante rápida y que está inactivo ahora mismo. Tal vez iremos a buscar ese JavaScript y lo incluiremos en un trabajador de servicio. Luego, si detectamos que la lambda falla, o algo así, o que ya tiene esto instalado, entonces activaremos el trabajador de servicio en lugar de la lambda, y los trabajadores de servicio podrán trabajar sin conexión. Entonces, eso también es bueno. Eso es interesante. Quiero decir, son del mismo idioma. Los trabajadores del servicio son JavaScript y muchas de las funciones de la nube son JavaScript, por lo que hay algunas... Creo que es una posibilidad, aunque eso... es solo, eso es algo técnico serio que... Simplemente me asusta tener esta porción de JavaScript que has entregado. a cuántos miles de usuarios, que no necesariamente saben qué tienen y qué versión tienen. Eww, pero eso es solo mi propio miedo. Estoy seguro de que algunas personas han hecho un buen trabajo con ese tipo de cosas.

Chris: En realidad no lo sé. Tal vez conozca algunas estrategias que yo no conozco, sobre la resistencia de serverless.

Drew: Supongo que hay un modo de falla, un estilo de falla, que podría ocurrir con funciones sin servidor, donde ejecuta una función una vez y falla, y puede ejecutarla una segunda vez inmediatamente después y tendría éxito, porque podría golpear un servidor completamente diferente. O cualquiera que sea el problema, cuando esa ejecución puede no existir en una segunda solicitud. Los problemas de que todo un host esté inactivo es una cosa, pero tal vez los haya... usted tiene problemas individuales con la máquina. Tienes un servidor en particular donde su memoria se estropeó y está arrojando una gran cantidad de errores, y la primera vez que lo golpeas, fallará. La segunda vez, ese problema podría haber estado arraigado.

Chris: Las empresas que tienden a ofrecer esta tecnología, hay que confiar en ellas, pero también son el tipo de empresas que… ese es su orgullo. Esta es la razón por la cual la gente los usa porque son confiables. Estoy seguro de que la gente podría señalar algunas interrupciones de AWS del pasado, pero tienden a ser un poco raras y no muy comunes. Si estabas organizando tu propia mierda, apuesto a que te ganaron desde un tipo de nivel de porcentaje de SLA. ¿Sabes? Así que no es como, "No construyas de manera resiliente", pero generalmente el tipo de empresas que ofrecen estas cosas son bastante confiables. Las posibilidades de que falles porque arruinaste esa función son mucho más altas que porque su arquitectura está fallando.

Drew: Supongo, quiero decir, al igual que cualquier cosa en la que estés usando una API o algo que pueda fallar, es solo asegurarte de estructurar tu código para hacer frente a ese modo de falla y saber qué sucede a continuación, en lugar de simplemente lanzar hasta un error para el usuario, o simplemente muriendo, o lo que sea. Es ser consciente de eso y pedirle al usuario que intente nuevamente. O intentarlo de nuevo tú mismo, o algo así.

Chris: Sí, me gusta la idea de intentarlo más de una vez, en lugar de decir simplemente: “Oh, no. Fallar. Abortar." "No lo sé, ¿por qué no lo intentas de nuevo allí, amigo?"

Drew: Quiero decir, cuando se trata de pruebas y desarrollo de funciones sin servidor, una especie de funciones en la nube, ¿es algo que se puede hacer localmente? ¿Se tiene que hacer en la nube? ¿Hay formas de manejar eso?

Chris: Creo que hay algunas maneras. No sé si la historia es tan impresionante. Todavía es un concepto relativamente nuevo, así que creo que mejora cada vez más. Pero por lo que sé, por un lado, estás escribiendo una función de Nodo bastante normal. Suponiendo que está utilizando JavaScript para hacer esto, y sé que en Lambda específicamente, admiten todo tipo de cosas. Puedes escribir una puta función de nube de PHP. Puede escribir una función de nube de Ruby. Entonces, sé que estoy hablando específicamente de JavaScript, porque tengo la sensación de que la mayoría de estas cosas son JavaScript. Incluso sin importar qué idioma sea, quiero decir, puede ir a su línea de comando localmente y ejecutarlo. Algunas de esas pruebas son... simplemente lo prueba como lo haría con cualquier otro código. Simplemente llame a la función localmente y vea si funciona.

Chris: Es una historia un poco diferente cuando hablas de una solicitud HTTP, eso es lo que estás tratando de probar. ¿Responde correctamente a la solicitud? ¿Y devuelve las cosas correctamente? No sé. La red podría involucrarse allí. Por lo tanto, es posible que desee escribir pruebas a ese nivel. Esta bien. No sé. ¿Cuál es la historia normal allí? Activas algún tipo de servidor local o algo que lo sirva. Usar Postman, no lo sé. Pero hay... Frameworks que intentan ayudar también. Sé que el ".com" sin servidor, que es terriblemente confuso, pero hay literalmente una compañía llamada Serverless y crean un marco para escribir las funciones sin servidor que te ayudan a implementarlas.

Chris: Entonces, si te gusta la instalación sin servidor de NPM, obtienes su marco. Y es ampliamente considerado como muy bueno, porque es muy útil, pero no tienen su propia nube o lo que sea. Los escribes y luego te ayuda a llevarlos a una lambda real. O podría funcionar con múltiples proveedores de nube. Ni siquiera lo sé en estos días, pero su propósito de existir es facilitar la historia del despliegue. No sé qué... AWS no es conocido por su simplicidad. ¿Sabes? Existe todo este mundo de herramientas para ayudarlo a usar AWS y son una de ellas.

Chris: Tienen algún tipo de producto pago. Ni siquiera sé qué es exactamente. Creo que una de las cosas que hacen es… el propósito de usarlos es para probar, es tener un entorno de desarrollo que es para probar su función sin servidor.

Drew: Sí, porque supongo que es una gran parte del flujo de trabajo, ¿no? Si ha escrito su función de JavaScript, la ha probado localmente, sabe que va a hacer el trabajo. How do you actually pick which provider it's going to go into and how do you get it onto that service? Now, I mean, that's a minefield, isn't it?

cris: si I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it's live now.” That's not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don't hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.

Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that's like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you're using their little Wrangler tool thing to do that. Also, I think the way we did it was… it's also a little dangerous. The second you put it live, it's affecting all your web traffic. It's kind of a big deal. You don't want to screw up a worker. You know? You can spin up a dev worker that's at a fake subdomain, and because it's CloudFlare, you can… CloudFlare can just make a subdomain anyway. No sé. It's just kind of a nice way to do a… as you're only affecting sub-domain traffic, not your main traffic yet. But the subdomain's just a mirror of a production anyway, so that's kind of a… that's a testing story there.

Chris: It brings up an interesting thing, though, to me. It's like… imagine you have two websites. One of them is… for us it's like a Ruby on Rails app. Whatever. It's a thing. But we don't have a CMS for that. That's just like… it's not a CMS, really. I think there's probably Ruby CMSs, but there's not any renowned ones. You know? It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you've lived in the CMS market for a long time -

Drew: Absolutely.

Chris: … so you know how this goes. Let's say you want to manage your sites in Perch or whatever, because it's a good CMS and that's the proper thing to use to build the kind of pages you want to build. But you don't want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don't know, there's any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There's an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That's fine, I guess, but now you're in a client side rendered page. It's going to be slow. It's going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It's just a bad story for SEO. It's not very resilient, because who knows what's going to happen in the network. It's not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.

Chris: You could also do it on the server side, though. Let's say you had… Ruby is capable of granting a network request too, but that's even scarier because then if something fails on the network, the whole page could die or something. It's like a nervous thing. I don't love doing that either. But we did this just recently with a worker, in that we… because the worker's JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn't. It all happened at the… on the edge, at the worker level, at the serverless level.

Chris: So it's kind of cool. I think you can imagine a fetch request on the browser probably takes, I don't know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. They do. Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It's not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it's kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there's a cool future to that.

Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I'm sort of thinking about how to architect things. Say I've got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who's going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?

Chris: Mm (affirmative). That's a fascinating question. I'd probably have an architect function or something. One function would be the one that's in charge of orchestrating the rest of them. It doesn't have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that's somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that's probably generally a good idea-

Drew: Yeah, that sounds smart. Sí.

Chris: But I think that's the ultimate thing. You get a bunch of server nerds talking, they'll talk about the different approaches to that exact idea in 10 different ways.

Drew: Sí. No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you're using APIs where you've got secret information. You've got API keys or something that you don't want to live in the client. Because I don't know, maybe this florist API charges you $100 dollars every time flower bomb someone.

Chris: Easily.

Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That's a viable way to work?

Chris: Yeah, yeah. Creo que sí. I mean, secrets are, I don't know, they're interesting. They're a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It's kind of like, you could just put your API key right in the serverless function, because it's just going to a server, right? You don't even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there's probably a source control along the way. It's probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can't put your API key in there, because then it's in the repo, and you don't put your API keys in repos. That's good advice. Now there's stuff. We've just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it's encrypted by the time anybody's looking at that file.

Chris: But only locally they're decrypted, so they're useful. So it's just kind of an interesting idea. I don't know if that helps in this case, but usually, cloud providers of these things have a web interface that's, “Put your API keys here, and we'll make them available at runtime of that function.” Then it kind of locks… it doesn't lock you in forever but it kind of is… it's not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.

Drew: Yeah, I think that's the way that Netlify manage it.

Chris: They all do, you know?

Drew: Sí. You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.

Chris: Yeah, right. But then you got to leave… I don't know, it's not that big of a deal. I'm not saying they're doing anything nefarious or anything. How do you deal with those secrets? Well, it's a hard problem. So they kind of booted it to, I don't know, “Just put them in this input field and we'll take care of it for you, don't worry about it.”

Drew: Is there anything that you've seen that stands out as an obvious case for things that you can do with serverless, that you just couldn't do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?

Chris: It's probably mostly that. I don't know that it unlocks any possibility that you just absolutely couldn't run it any other way. Yeah, I think that's a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don't know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That's the one I want to use. I think that's kind of cool. You know? That you can kind of benefit from other people's experience in that way. I think that will happen more and more.

Drew: I guess it's the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.

cris: sí, sí. Creo que sí, creo que es... porque hay momentos como... no tienes que ser tremendamente hábil para saber qué es apropiado y qué no para un sitio web. Como, hice un pequeño tutorial la otra semana, donde estaba este glitch usa estos... cuando guardas un glitch, te dan un slug por lo que construiste, eso es, "Whiskey, tango, foxtrot". 1,000.” Es como una cosita inteligente. Las posibilidades de que sea único son muy altas, porque creo que incluso le agregan un número o algo así. Pero terminan siendo estas pequeñas cosas divertidas. Abren el código de su biblioteca que tiene todas esas palabras, pero son como cien, miles de palabras. El archivo es enorme. ¿Sabes? Es megabytes grande de sólo un diccionario de palabras. Probablemente aprenda en su primer año de desarrollo: "No envíe un archivo JavaScript que sea megabytes de un diccionario". Eso no es algo bueno para enviar. ¿Sabes? Pero a Node no le importa. Puedes enviar cientos de ellos. Es irrelevante para la velocidad en un servidor.

Drew: Sí.

Chris: No importa en un servidor. Entonces, podría decir: "Hmm, bueno, entonces lo haré en Node". Tendré una declaración que diga, "Palabras iguales requieren palabras", o lo que sea, y una nota en la parte superior, "Haz que aleatorice un número. Sácalo de la matriz y devuélvelo”. Entonces, esa función sin servidor consta de ocho líneas de código con un @JSON empaquetado que extrae esta biblioteca de código abierto. Y luego mi código front-end, hay una URL para la función sin servidor. Llega a esa URL. La URL devuelve una palabra o un grupo de palabras o lo que sea. Construyes tu propia pequeña API para ello. Y ahora, tengo una cosa realmente agradable y eficiente. Lo bueno de eso es que es tan simple. No estoy preocupado por la seguridad de la misma. Yo no... ¿sabes?

Chris: Es solo que... un desarrollador de JavaScript muy promedio o principiante, creo, puede lograrlo, lo cual es genial. Eso es algo habilitador que no tenían antes. Antes, decían: "Bueno, aquí hay una serie de palabras de 2 MB". "Oh, no puedo enviar eso al cliente". "Oh, simplemente cerrarás entonces". Podrías chocar con esta pared que es como, “Simplemente no puedo hacer esa parte entonces. Necesito pedirle a alguien más que me ayude con eso o simplemente no hacerlo o elegir babosas más aburridas o algo así…” Es solo que tienes que ir de otra manera que es una pared para ti, porque no puedes hacerlo. Y ahora, estás, "Oh, bueno, solo..." En lugar de tener eso en mi barra de script, o en mi carpeta de scripts de barra de fuente, lo pondré en mi carpeta de funciones.

Chris: Te gusta mover el guión de una carpeta a la otra. Y ese se implementa como una función sin servidor en su lugar. ¿Cuan genial es eso? ¿Sabes? Estás usando exactamente el mismo conjunto de habilidades, casi. Todavía hay algunos bordes ásperos, pero está bastante cerca.

Drew: Es genial. Ha creado una especie de pequeño micrositio sobre estas ideas, ¿no es así?

cris: si Llegué un poco temprano al juego. Sin embargo, hoy estaba trabajando en ello porque... recibe solicitudes de incorporación de cambios. La idea... bueno, está en serverless.css-tricks.com y... por cierto, hay un guión en CSS-Tricks. Así que es un subdominio de CSS-Tricks, y también lo construí sin servidor, así que esto es... CSS-Tricks es como un sitio de WordPress, pero este es un sitio generador de sitios estáticos. Todo el contenido está en el repositorio de GitHub, que es de código abierto. Entonces, si desea cambiar el contenido del sitio, simplemente puede enviar una solicitud de encuesta, lo cual es bueno porque ha habido un centenar de ellos a lo largo del tiempo. Pero construí todo el contenido original.

Drew: Es un lugar súper útil, porque enumera... Si está pensando: "Bien, quiero comenzar con las funciones sin servidor", enumera todos los proveedores con los que podría probarlo y...

Chris: Eso es todo, más o menos, son listas de tecnología. Si.

Drew: Lo cual es genial, porque de lo contrario, solo estás buscando en Google lo que sea y no sabes lo que estás encontrando. Sí, son listas de proveedores de API que te ayudan a hacer este tipo de cosas.

Chris: Forms es un ejemplo de eso, porque... así que en el momento en que eliges... digamos, vas a ir a JAMstack, que sé que no es necesariamente el punto de esto, pero ves cómo están de la mano. . De repente, no tiene un archivo PHP o lo que sea para procesar ese formulario. ¿Cómo se hacen formularios en un sitio JAMstack? Bueno, hay muchas maneras de hacerlo. Aparentemente, todos y su hermana quieren ayudarte a resolver ese problema. Así que creo que si yo fuera el inventor de la palabra JAMstack, tratarían de ayudarte de forma natural, pero no tienes que usarlos.

Chris: De hecho, me sorprendió mucho armar este sitio. Vamos a ver. Hay seis, nueve, doce, quince, dieciocho, veintiuno, veintidós servicios que quieren ayudarlo a procesar sus formularios sin servidor en este sitio ahora mismo. Si quieres ser el 23, eres bienvenido, pero tienes competencia por ahí. Entonces, la idea detrás de esto es que escribes un formulario en HTML, como literalmente un elemento de formulario. Y luego el atributo de acción del formulario, no puede apuntar a ningún lado internamente, porque no hay nada a lo que apuntar. No puede procesar, por lo que apunta externamente. Apunta a lo que sea que ellos quieran que lo apuntes. Procesarán el formulario y luego tenderán a hacer las cosas que esperarías que hicieran, como enviar una notificación por correo electrónico. O envía algo de Slack. O luego envíelo a Zapier y Zapier lo enviará a otro lugar. Todos tienen conjuntos de funciones y precios ligeramente diferentes, pero todos están tratando de resolver ese problema por usted, como, “¿No desea procesar sus propios formularios? No hay problema. Lo procesaremos por usted”.

Drew: Sí, es un recurso súper útil. Realmente recomendaría a todos que lo revisen. Es serverless.css-tricks.com. Entonces, he estado aprendiendo todo sobre la tecnología sin servidor. ¿Qué has estado aprendiendo últimamente, Chris?

Chris: Bueno, todavía estoy mucho en este mundo y aprendo sobre cosas sin servidor. Tuve una idea para... Solía ​​jugar a este juego de rol en línea hace mucho tiempo. Hace poco descubrí que todavía está vivo. Es un tipo de juego de fantasía medieval basado en texto. Lo jugué cuando AOL era una cosa, porque AOL quería tener estos juegos en los que tenías que iniciar sesión para jugar, porque querían que pasaras horas y horas en AOL, para poder enviarte estas enormes facturas, que era , estoy seguro, por qué les fue tan bien en algún momento.

Drew: Así que facturando por segundo. Si.

cris: si Así que los juegos eran importantes para ellos. Si pudieran hacerte jugar juegos con otras personas allí. Así que este juego como que... no debutó allí, pero se trasladó a AOL, porque estoy seguro de que consiguieron un trato jugoso por él, pero era tan... quiero decir, es simplemente, no podría ser más nerd. Eres un mago enano y obtienes bastón rúnico de tu vaina de cuero. Y escribes comandos en él como una terminal. Entonces el juego te responde. Jugué ese juego durante mucho tiempo. Yo estaba muy metido en eso. Me metí en la comunidad y el espíritu de la misma. Era una especie de... era como si estuviera solo en mi computadora, pero sin embargo, miro hacia atrás en ese momento de mi vida y pienso: "Fue un momento maravilloso en mi vida". Yo estaba realmente... Me gustaba la gente y el juego y todo eso. Pero luego crecí y dejé de jugarlo, porque la vida te pasa.

Chris: Me enteré recientemente, porque alguien comenzó a hacer un podcast sobre el tema nuevamente... No sé cómo lo encontré, pero lo acabo de hacer. Yo estaba como, “Este juego está vivo y bien en el mundo de hoy, ¿estás bromeando? Esta cosa basada en texto. Y estaba más que feliz de reactivar y recuperar mis viejos personajes y jugarlo. Pero solo para descubrir que los clientes que te tienen descargado para este juego, no han evolucionado en absoluto. son horribles Casi asumen que estás usando Windows. Solo hay estos terriblemente cursis mal representados... y está basado en texto, crees que al menos tendría una buena tipografía. No. Así que estoy como, “Podría estar involucrado. Podría escribir un cliente para este juego. Ponle una tipografía hermosa”. Simplemente modernice la cosa, y creo que los jugadores del juego lo apreciarían, pero me pareció abrumador. "¿Cómo puedo hacerlo?" Pero encuentro algunos proyectos de código abierto. Uno de ellos es como... puedes jugar el juego a través de una ventana de terminal real, y usa algunas bibliotecas de código abierto para hacer una GUI a partir de una ventana de terminal.

Drew: ¿En serio?

cris: no lo sé. Así que eso fue genial. Pensé: “Si escribieron eso, debe haber un código allí sobre cómo conectarse al juego y hacer que todo funcione y esas cosas. Así que al menos tengo un código de inicio”. Estaba tratando de seguir la aplicación, "Tal vez lo haga en Flutter o algo así", para que la aplicación del producto final funcione en teléfonos móviles y, "Realmente podría modernizar esto". Pero luego me abrumé. Yo estaba como, “Ah, esto es demasiado grande… No puedo. Estoy ocupado." Pero encontré a otra persona que tenía la misma idea y estaba mucho más avanzada, así que solo pude contribuir a nivel de diseño. Y ha sido muy divertido trabajar en él, pero también he estado aprendiendo mucho, porque es raro para mí saltar a un proyecto que es el bebé de otra persona, y solo estoy contribuyendo un poco, y eso tiene un significado totalmente diferente. opciones tecnológicas de las que jamás hubiera elegido.

Chris: Es una aplicación de Electron. Eligieron eso, que también es una forma genial de hacerlo, porque son mis habilidades web... así que no estoy aprendiendo nada demasiado extraño, y es multiplataforma, lo cual es genial. Entonces, he estado aprendiendo mucho sobre Electron. Creo que es divertido.

Drew: Eso es fascinante. Siempre es sorprendente cómo los pequeños proyectos paralelos y las cosas que hacemos para divertirnos terminan siendo el lugar donde a veces aprendemos más. Y aprender habilidades que luego pueden retroalimentarse en nuestro tipo de trabajo diario.

Chris: Esa es la única forma en que aprendo cosas. Me arrastraron a algo que... Pensé: "No son..." Está renderizado con una biblioteca de JavaScript llamada Mithril, que es... No sé si alguna vez has oído hablar de él, pero es extraño. No es... es casi como escribir React sin JSX. Tienes que "crear un elemento" y hacer todo esto... pero se supone que es un punto de referencia mucho mejor que él... Y en realidad es importante porque en este juego basado en texto, el texto simplemente vuela. Hay mucha manipulación de datos, que es como... uno pensaría que este juego basado en texto sería tan fácil de ejecutar para una ventana de navegador, pero en realidad no lo es. Hay tanta manipulación de datos que hay que ser realmente... tenemos que ser conscientes de la velocidad de renderizado. ¿Sabes?

Drew: Eso es fascinante-

Chris: Muy bien.

Drew: Sí. Si usted, querido oyente, desea saber más de Chris, puede encontrarlo en Twitter, donde es @chriscoyier. Por supuesto, CSS-Tricks se puede encontrar en css-tricks.com y CodePen en codepen.io. Pero, sobre todo, le recomiendo que se suscriba al podcast de ShopTalk Show, si aún no lo ha hecho, en shoptalkshow.com. Gracias por acompañarnos hoy, Chris. ¿Tienes alguna palabra de despedida?

Chris: Smashingpodcast.com. Espero que esa sea la URL real.