Smashing Podcast Episódio 22 Com Chris Coyier: O que é Serverless?

Hoje, estamos falando sobre arquiteturas Serverless. O que isso significa e como isso difere de como podemos construir sites atualmente? Falei com Chris Coyier para descobrir.

Mostrar notas

• Microsite de Chris The Power of Serverless for Front-end Developers
• Cris no Twitter
• Podcast do ShopTalk Show

Atualização semanal

• “Configurando o Redux para uso em um aplicativo do mundo real,”
  por Jerry Navi
• “Você pode criar um site para os cinco sentidos?”
  por Suzanne Scacca
• “Criando um blog estático com Sapper e Strapi,”
  por Daniel Madalitso Phiri
• “Um guia prático para tours de produtos em aplicativos React,”
  por Blessing Krofegha
• “Como criar um Porsche 911 com esboço”
  por Nikola Lazarevic

Transcrição

Drew McLellan: Ele é um web designer e desenvolvedor que você deve conhecer pelo CSS-Tricks, um site que ele começou há mais de 10 anos e que continua sendo um recurso de aprendizado fantástico para aqueles que constroem sites. Ele é o cofundador do CodePen, o playground de codificação baseado em navegador e a comunidade usada por front-enders em todo o mundo para compartilhar o que eles fazem e encontrar inspiração naqueles que seguem. Ao lado de Dave Rupert é o co-apresentador do ShopTalk Show, um podcast sobre criação de sites. Então, sabemos que ele sabe muito sobre desenvolvimento web, mas você sabia que uma vez ele ganhou uma competição de comer cachorro-quente usando apenas seu charme? Meus amigos, por favor, dêem as boas-vindas a Chris Coyier. Olá Cris, tudo bem?

Chris Coyier: Ei, estou arrasando.

Drew: Eu queria falar com você hoje não sobre o CodePen, e não necessariamente quero falar com você sobre CSS-Tricks, que é um daqueles recursos incríveis que tenho certeza que todo mundo sabe que aparece bem no topo do Google Resultados de pesquisa ao procurar respostas sobre qualquer pergunta de desenvolvimento da web. Aparece seu rosto e há uma postagem de blog útil escrita por você ou por um de seus colaboradores convidados.

Chris: Ah, eu costumava fazer isso. Houve um… não sei, provavelmente foi na época em que o Google tinha aquela rede social esquisita. O que é que foi isso? Google+?

Drew: Ah, além disso, sim.

Chris: Sim, onde eles associavam um site a uma conta Plus, então minha conta Plus tinha um avatar, e o avatar era eu, então ele aparecia nos resultados da pesquisa. Acho que esses dias se foram. Acho que se você…

Drew: Acho que sim, sim...

Cris: Sim.

Drew: Mas eu meio que queria falar com você sobre algo que tem sido um pouco mais como um interesse secundário seu, e esse é o conceito de arquiteturas sem servidor.

Chris: Hum (afirmativo).

Drew: Isso é algo que você vem aprendendo há algum tempo. Isso está certo?

Cris: Sim, sim. Eu sou apenas um fã. Parece um ajuste natural à evolução do desenvolvimento front-end, que é onde sinto que tenho, pelo menos, alguma experiência. Eu me considero muito mais... muito mais útil no front-end do que no back-end, não que eu... eu faço isso todos esses dias. Já estou por aí há tempo suficiente para não ter medo de olhar para um pequeno código Ruby, isso é certo. Mas prefiro o front-end. Já estudei mais. Eu participei de projetos mais nesse nível, e então veio esse pequeno tipo de novo paradigma que diz: “Você pode usar suas habilidades de JavaScript no servidor”, e é interessante. Você sabe? É assim que penso. Há muito mais do que isso, mas é por isso que eu me importo, é porque sinto que os desenvolvedores front-end se aprofundaram tanto no JavaScript. E agora podemos usar esse mesmo conjunto de habilidades em outro lugar. Muito legal.

Drew: Parece que um mundo totalmente novo se abriu, enquanto se você fosse apenas um codificador de front-end... digo, apenas um codificador de front-end, eu não deveria. Se você é um codificador de front-end e está acostumado a trabalhar com um colega ou amigo para ajudá-lo com a implementação de back-end, de repente isso se abre. E é algo que você mesmo pode gerenciar mais de toda a pilha.

Cris: Sim, sim. É isso.

Drew: Dirigindo-se ao elefante na sala, bem no topo. Estamos falando de serverless e, obviamente, nomear as coisas é difícil. Nós todos sabemos isso. Arquitetura sem servidor não significa que não há servidores, não é?

Chris: Eu acho que é obrigatório, tipo se este é o primeiro podcast que você está ouvindo, ou no primeiro… você só está ouvindo a palavra “serverless” nas primeiras doze vezes que você ouviu, é obrigatório que você ter uma reação visceral e ter esse tipo de “Ah, mas ainda há servidores”. Tudo bem. Se isso está acontecendo com você agora, apenas saiba disso, esse é um passo necessário para isso. É como qualquer outra coisa na vida. Há etapas para a compreensão. A primeira vez que você ouve algo, você é obrigado a rejeitá-lo um pouco, e só depois de uma dúzia de vezes, ou depois de provar que vale um pouco para você, você entra nos estágios posteriores de entendimento aqui. Mas a palavra ganhou, então se você ainda está lutando contra a palavra “serverless”, eu odeio te dizer, que o trem deixou a estação lá. A palavra já é sucesso. Você não vai ganhar essa. Sinto muito.

Chris: Mas eu acho interessante que... está começando a ser tipo, talvez não haja servidores envolvidos às vezes. Eu acho que uma das coisas que travaram o serverless como conceito foi o AWS Lambda. Eles foram meio que os primeiros em cena. Um lambda é como uma função que você dá à AWS e a coloca no céu mágico e então… tem uma URL, e você pode acessá-la e ela executará essa função e retornará algo se você quiser. Você sabe? Isso é apenas HTTP ou qualquer outra coisa. É assim que funciona, que... a primeira vez que você ouve isso, você fica tipo, “Por quê? Eu não me importo." Mas então, há algumas coisas óbvias nisso. Ele poderia conhecer minhas chaves de API às quais ninguém mais tem acesso. É por isso que você executa o back-end para começar, é que ele conhece coisas secretas que não precisam estar no JavaScript no lado do cliente. Então, se ele precisa falar com um banco de dados, ele pode fazer isso. Ele pode fazer isso com segurança sem ter que expor as chaves de API em outro lugar. Ou mesmo onde estão esses dados ou como eles os obtêm, é…

Chris: Então isso é muito legal. Eu posso escrever uma função que converse com um banco de dados, obtenha alguns dados, retorne isso. Frio. Então, Lambda é isso, mas a AWS funciona. Você tem que escolher uma região. Você fica tipo, “Eu não sei. Onde deveria estar, Virgínia? Óregon? Devo escolher a Austrália? Não sei." Eles têm 20, 30. Eu nem sei quantos eles têm hoje em dia, mas até lambdas tinham regiões. Eles, eu acho, hoje em dia têm Lambda@Edge, o que significa que são todas as regiões, o que é bem legal. Mas eles foram os primeiros, e agora todo mundo tem algo como Lambda. Todos os serviços em nuvem. Eles querem algum tipo de serviço neste mundo. Um deles é o CloudFlare. CloudFlare tem trabalhadores. Eles têm muito mais locais do que a AWS, mas eles executaram em um momento diferente também… da maneira que um trabalhador do CloudFlare… é semelhante a um lambda em que você pode executar o Node. Você pode executar JavaScript. Você pode rodar várias outras linguagens também, mas… Eu penso nestas coisas em grande parte, a linguagem mais interessante é JavaScript, apenas por causa da prevalência dela.

Chris: Isso acontece apenas no nível da CDN, que acho que é um servidor, mas costumo não pensar nas CDNs como um servidor. Não tão obviamente como outra coisa. Está começando a parecer ainda mais sem servidor ultimamente. Uma CDN é um servidor? Quero dizer, acho que é um computador em algum lugar, mas parece ainda menos servidor.

Drew: Parece que sim, uma CDN pode ser um servidor, mas é a versão mais mínima de um servidor. É como um servidor fino, se você quiser.

Cris: Sim. Certo.

Drew: Tudo bem. Eu ouvi dizer… Não consigo lembrar a fonte para creditar, infelizmente, mas ouvi serverless descrito como “como usar um serviço de compartilhamento de carona como Uber ou Lyft” ou qualquer outra coisa. Você pode ser sem carro e não possuir um carro, mas isso não significa que você nunca use um carro.

Chris: Sim, isso não significa que os carros não existam. Isso é bom.

Drew: Você apenas convoca um quando precisa, mas ao mesmo tempo, você não está pagando o custo inicial de compra de um carro. Você não está pagando manutenção ou combustível ou-

Chris: Certo, e o preço também faz sentido, certo? Muito legal. Essa é uma bela analogia, eu acho. E então, porque também está no nível da CDN, ele apenas intercepta solicitações HTTP que já estão acontecendo, o que significa que você não pergunta… você não envia uma solicitação para ele e ele envia uma solicitação de volta. Está acontecendo naturalmente durante a solicitação, o que também faz com que pareça menos servidor. Não sei, é interessante. É interessante com certeza. Então, isso é um grande negócio, porém, que você trouxe a questão dos preços. Que você só paga pelo que usa. Isso também é significativo, porque… digamos, você é um desenvolvedor de back-end, que está acostumado a girar servidores a vida inteira. E eles arcam com os custos: “Preciso desse tipo de servidor com esse tipo de memória e esse tipo de CPU e esse tipo de especificações. E é isso que vai custar.” Serverless aparece e corta a cabeça desse preço.

Chris: Então, mesmo se você for um desenvolvedor de back-end que simplesmente não gosta muito disso, que eles simplesmente não gostam disso, como seu conjunto de habilidades é exatamente o que é ao longo dos anos, você compara o preço e você fica tipo, “O quê? Eu poderia estar pagando 1% do que estava pagando antes?” Você não tem permissão para não se importar com isso, certo? Se você é esse desenvolvedor de back-end que está pagando cem vezes mais pelo serviço do que precisa pagar, então você é meio ruim no seu trabalho. Lamento dizer. Isso veio e isso quebrou os preços de várias maneiras. Você tem que se preocupar com isso. E é legal que outra pessoa esteja… Não é como se você não precisasse se preocupar com segurança, mas não é o seu servidor. Você não tem... sua função lambda ou de nuvem, ou seu trabalhador, ou qualquer outra coisa, não está sentado em um servidor que está bem próximo a alguns dados realmente sensíveis em sua própria rede. Não está ao lado do seu banco de dados.

Chris: Se alguém escreve um código que de alguma forma tenta se ejetar do trabalhador ou do lambda, ou qualquer outra coisa, e tenta acessar outras coisas em seu caminho, não há nada lá para obter. Portanto, a segurança também é importante, então, novamente, se esse é o seu trabalho como administrador do servidor, é lidar com a segurança dessa coisa. Executando-o, executando certas coisas no Lambda, você obtém uma segurança natural dele, o que é ótimo. Então, é bem mais barato. É bem mais seguro. Ele incentiva essas pequenas arquiteturas modulares, o que pode ser uma boa ideia. Parece ser dominó atrás de dominó de boas ideias aqui. Por isso é notável. Você sabe?

Drew: Sim, quero dizer, tradicionalmente com uma arquitetura baseada em servidor que estamos executando há décadas na web, você tem um servidor web que você mesmo executa. Ele contém seu código front-end, seu código back-end, seu banco de dados e tudo mais. Então você precisa manter isso e mantê-lo funcionando e pagar as contas, e mesmo que ele não esteja sendo usado, ele está lá marcando as contas. O usuário faria uma solicitação e criaria todas as consultas HTML do banco de dados, enviaria tudo para o navegador. Esse processo funciona. É como um monte de coisas são construídas. É provavelmente a maior parte de como a web é construída. É como coisas como o WordPress funcionam. Este é realmente um problema que precisamos resolver? Quer dizer, nós conversamos um pouco sobre custos. Quais são os outros tipos de problemas com isso, que estamos... que precisamos resolver, e que o serverless pode nos ajudar?

Chris: Sim, os problemas com a abordagem da velha escola. Sim, eu não sei, talvez não haja nenhum. Quer dizer, não estou dizendo que toda a web precisa mudar tudo… a coisa toda da noite para o dia. Não sei. Talvez não realmente, mas acho que abre portas. Parece que, quando boas ideias chegam assim, elas mudam lentamente a forma como a web funciona. Portanto, se houver algum CMS construído de alguma forma que espere que um banco de dados esteja lá, isso significa que talvez os hosts do futuro comecem a aproveitar isso de maneiras interessantes. Talvez pareça para você que ainda é apenas um servidor tradicional, mas os próprios hosts o desenvolveram, como eles operam, para arquiteturas sem servidor. Então, você nem sabe realmente o que está acontecendo, mas eles encontraram uma maneira de reduzir seus custos hospedando as coisas que você precisa de maneiras sem servidor. Talvez sim, nem precise se importar como desenvolvedor, mas em um nível meta, é isso que está acontecendo. Pode ser. Não sei.

Chris: Também não significa que... Os bancos de dados ainda estão lá. Se a arquitetura de um banco de dados relacional for a maneira correta de armazenar esses dados, ótimo. Menciono isso porque esse mundo do Serverless está crescendo ao mesmo tempo que o JAMstack. E o JAMstack é essa arquitetura que é: “Você deveria estar servindo seu site fora de hosts estáticos, que não executam nada, exceto...” Eles são como pequenas CDNs. Eles são como, “Eu não posso fazer nada. Eu não corro PHP. Eu não corro Ruby. não corro nada. Eu corro em um pequeno servidor web que foi projetado apenas para servir apenas arquivos estáticos.”

Chris: “E então, se você precisar fazer mais do que isso, se precisar extrair dados de um banco de dados relacional, faça isso em outro momento, não no servidor. Você pode fazer isso em um processo de compilação com antecedência e extrair essas coisas do banco de dados, pré-compilar arquivos estáticos e eu os servirei, ou fazê-lo em tempo de execução.” Ou seja, você obtém esse shell de um documento e, em seguida, faz uma solicitação JavaScript para obter alguns dados e os preenche previamente. Então você faz isso antes ou depois, mas isso não significa “não use um banco de dados relacional”. Significa apenas: “Não faça o servidor gerar no momento da solicitação do documento”, o que é um… não sei, é uma pequena mudança de paradigma.

Chris: Também não é apenas o JAMstack. Também estamos vivendo na época dos frameworks JavaScript. Estamos vivendo em uma época em que está começando a ser um pouco mais esperado que a maneira como um aplicativo JavaScript inicializa, é que ele monta alguns componentes e, à medida que esses componentes são montados, solicita os dados de que precisa. E assim, pode ser um ajuste natural para algo como um site React dizer: “Bem, vou apenas acessar uma função sem servidor para liberar os dados de que ele precisa. Ele atinge essencialmente alguma API JSON. Recebo os dados JSON de que preciso e me construo a partir desses dados e, em seguida, renderizo na página.” Agora, se isso é bom ou ruim para a web, é como, “Eu não sei. Que pena. O navio partiu. É assim que muitas pessoas estão construindo sites.” São apenas coisas renderizadas pelo cliente. Portanto, o JavaScript sem servidor e o moderno andam de mãos dadas.

Drew: Suponho que você não precise vender por atacado… estar olhando para uma arquitetura ou outra. Há uma área no meio onde partes de uma infraestrutura podem ser mais tradicionais e partes podem ser sem servidor, estou supondo?

Cris: Sim. Bem, eles estão tentando lhe dizer isso de qualquer maneira. Qualquer um que queira lhe vender qualquer parte de sua arquitetura diz: “Você não precisa comprar tudo agora. Basta fazer um pouco.” Porque, é claro, eles querem que você mergulhe o dedo do pé em qualquer coisa que eles estejam vendendo, porque uma vez que você mergulhe o dedo do pé, as chances de você mergulhar na piscina são muito maiores. Então, acho que… não é mentira, porém, necessariamente, embora eu ache um pouco menos de sorte em… não quero que meu stack seja um pouco de tudo. Acho que há alguma morte técnica aí que nem sempre quero engolir.

Drew: Mm (afirmativo).

Chris: Mas é possível fazer. Acho que o mais citado é... digamos que eu tenha um site que tenha um elemento de comércio eletrônico, o que significa... e digamos comércio eletrônico em larga escala, então 10.000 produtos ou algo assim, que essa arquitetura JAMstack não chegou ao ponto em que isso é sempre particularmente eficiente para reconstruir isso estaticamente. Então, o pensamento vai, "Então não." Deixe essa parte se hidratar naturalmente com… acessar funções sem servidor e obter os dados de que precisa, e fazer tudo isso. Mas o resto do site, que não é... não há tantas páginas, não há tantos dados, você pode meio que pré-renderizar ou qualquer outra coisa. Então, um pouco dos dois.

Drew: Claro, muitas pessoas estão lidando com sistemas legados que… alguma coisa antiga de banco de dados que foi construída nos anos 2000 que eles podem colocar uma espécie de camada de API JSON em cima…

Cris: Sim.

Drew: … e construir algo mais moderno, e talvez sem servidor, e ainda interagir com esses sistemas legados colando-os de uma maneira estranha.

Cris: Sim. Eu gosto disso, porém, não é? Não são... a maioria dos sites já existe. Quantos de nós são sites totalmente greenfield? A maioria de nós trabalha em alguma porcaria que já existe que precisa ser arrastada para o futuro por algum motivo, porque eu não sei, os desenvolvedores querem trabalhar mais rápido, ou você não pode mais contratar ninguém no COBOL, ou qualquer que seja a história é. Você sabe?

Drew: Em termos de terminologia, estamos falando do JAMstack, que é essa metodologia de executar um código praticamente no navegador, servindo-o a partir de um CDN. Então, não ter nada dinâmico no servidor. E então, quando falamos sobre serverless, estamos falando sobre aqueles pequenos pedaços de funcionalidade que são executados em seu servidor em outro lugar. Isso está certo? Que estávamos falando sobre essas funções de nuvem meio-

Chris: Sim, quero dizer, eles são duas ideias quentes agora. Então é meio fácil falar de um e falar do outro. Mas eles não precisam necessariamente estar juntos. Você pode executar um site JAMstack que não tem nada a ver com nada sem servidor. Você está apenas fazendo isso, você apenas pré-compila o site e o executa, e você pode usar serverless sem ter que se preocupar com o JAMstack. Na verdade, o CodePen não faz nada no JAMstack. Não que queiramos falar sobre o CodePen necessariamente, mas é um aplicativo Ruby on Rails. Ele é executado em várias instâncias do AWS EC2 e em uma variedade de outras arquiteturas para que isso aconteça. Mas usamos coisas sem servidor sempre que podemos para o que pudermos, porque é barato e seguro, e apenas uma boa maneira de trabalhar. Portanto, nenhum JAMstack em uso, mas sem servidor em todo o lugar.

Drew: Isso é muito interessante. Que tipo de tarefas você está colocando sem servidor no CodePen?

Chris: Bem, há um monte de coisas. Um deles é, eu acho, bastante óbvio, eu preciso… o ponto do CodePen é que você escreve cada HTML, CSS e JavaScript no navegador e ele os renderiza na sua frente, certo? Mas você também pode escolher idiomas de pré-processador. Digamos que você goste de Sass. Você ativa o Sass no CSS e escreve Sass. Bem, algo tem que processar o Sass. Hoje em dia, Sass é escrito em Dart ou algo assim.

Chris: Teoricamente, você poderia fazer isso no cliente. Mas essas bibliotecas que fazem pré-processamento são bem grandes. Acho que não quero enviar toda a biblioteca Sass para você, apenas para executar essa coisa. Eu não quero… não é, não é necessariamente a arquitetura certa para isso. Talvez seja no futuro, quero dizer, poderíamos falar sobre porcaria offline, yada, yada, Web Workers. Há um milhão de coisas arquitetônicas que poderíamos fazer. Mas é assim que funciona agora, existe um lambda. Ele processa Sass. Tem um trabalho minúsculo, minúsculo, minúsculo.

Chris: Você manda esse blob de Sass e ele te manda coisas de volta, que é o CSS processado, talvez um mapa do site, qualquer coisa. Tem um pequeno trabalho e provavelmente pagamos por esse lambda, como quatro centavos ou algo assim. Porque lambdas são incrivelmente baratos e você também pode martelar. Você não precisa se preocupar com escala. Você acaba de acertar essa coisa o quanto quiser e sua conta será surpreendentemente barata. Há momentos em que o serverless começa a cruzar a linha de ser muito caro. Não sei o que é isso, não sou tão mestre em coisas assim. Mas geralmente, qualquer coisa sem servidor que fazemos, nós basicamente... quase todos contam como grátis, porque é muito barato. Mas há um para Sass. Há um para menos. Há um para Babbel. Há um para TypeScript. Há um para… Todos esses são lambdas individuais que executamos. Aqui está um código, entregue ao lambda, ele volta e fazemos o que quisermos com ele. Mas nós o usamos para muito mais do que isso, mesmo recentemente.

Chris: Aqui está um exemplo. Cada caneta no CodePen tem uma captura de tela. Isso é legal, certo? Então, as pessoas fazem uma coisa e então precisamos de um PNG ou JPEG, ou algo assim, para que possamos... dessa forma, quando você twitta, você obtém uma pequena prévia. Se você compartilhá-lo no Slack, terá uma pequena prévia dele. Usamos no próprio site para renderizar... em vez de um iframe, se pudéssemos detectar que a caneta não está animada, pois a imagem de um iframe é muito mais leve, então por que não usar a imagem? Não é animado de qualquer maneira. Apenas ganhos de desempenho como esse. Portanto, cada uma dessas capturas de tela tem um URL, obviamente. E nós a arquitetamos para que essa URL seja, na verdade, uma função sem servidor. É um trabalhador. E assim, se esse URL for atingido, podemos verificar rapidamente se já fizemos essa captura de tela ou não.

Chris: Na verdade, isso é habilitado pelo CloudFlare Workers, porque o CloudFlare Workers não é apenas uma função sem servidor, mas também possui um armazenamento de dados. Eles têm essa coisa chamada armazenamento de valor-chave, então o ID disso, podemos verificar bem rápido e será: "Verdadeiro ou falso, você tem ou não?" Se tem, serve. E ele o atende pelo CloudFlare, que é super rápido para começar. E então te dá toda essa habilidade também. Por ser uma CDN de imagem, você pode dizer: “Bem, sirva no formato ideal. Sirva-o como essas dimensões.” Eu não tenho que fazer a imagem nessas dimensões. Você apenas coloca as dimensões no URL e ele volta com esse tamanho, magicamente. Então isso é muito legal. Se não tiver, ele pede outra função serverless para torná-lo realmente rápido. Então ele vai fazer e depois vai colocar em um balde em algum lugar... porque você tem que ter uma origem para a imagem, né? Você tem que realmente hospedá-lo em algum lugar normalmente. Então, colocamos em um balde S3 bem rápido e depois servimos.

Chris: Então não há nenhum servidor de filas, não há nada. É como se as funções sem servidor gerenciassem a criação, armazenamento e veiculação dessas imagens. E há uns 50 milhões ou 80 milhões deles ou algo assim. É muito, então ele lida muito bem com isso como escala. Nós simplesmente nem tocamos nele. Simplesmente acontece. Tudo acontece super rápido. Muito legal.

Drew: Acho que… bem, uma função serverless é ideal para uma tarefa que precisa de muito pouco conhecimento do estado das coisas. Quero dizer, você mencionou a capacidade do CloudFlare de armazenar pares de valores-chave para ver se você já tem algo armazenado em cache ou não.

Cris: Sim. Isso é o que eles estão tentando resolver, porém, com aqueles. Esses pares de valores-chave, é que… acho que tradicionalmente era verdade. Eles são como, “Evite o estado da coisa”, porque você simplesmente não pode contar com isso. E os CloudFlare Workers estão dizendo: “Sim, na verdade, você pode lidar com o estado, até certo ponto”. Não é tão chique quanto um… não sei, são valores-chave, então é uma chave em um valor. Não é como uma coisa fantasiosa aninhada e relacional. Então provavelmente há alguns limites para isso. Mas este é o dia do bebê para isso. Eu acho que essas coisas vão evoluir para serem mais poderosas, então você tem alguma habilidade de fazer algumas coisas tipo estado.

Drew: E às vezes a limitação, esse tipo de capacidade limitada de manter o estado, ou o fato de você não ter… você não quer manter nenhum estado, meio que o empurra para uma arquitetura que lhe dá esse tipo de… falamos sobre a filosofia de software de “Pequenos pedaços unidos livremente”, não é?

Chris: Hum (afirmativo).

Drew: Onde cada pequeno componente faz uma coisa e faz bem. E realmente não sabe sobre o resto do ecossistema ao seu redor. E parece que realmente se aplica a esse conceito de funções sem servidor. Você concorda?

Cris: Sim. Eu acho que você poderia ter um debate filosófico se isso é uma boa ideia ou não. Você sabe? Acho que algumas pessoas gostam do monólito, por assim dizer. Eu acho que é possível... existem maneiras de exagerar isso e fazer muitas peças pequenas que são muito difíceis de testar completamente. É bom ter um teste do tipo “Oh, eu me pergunto se minha função Sass está funcionando. Bem, vamos apenas escrever um pequeno teste para isso e ter certeza de que é.” Mas digamos, o que importa para o usuário é uma sequência de sete desses. Como você testa todos os sete juntos? Acho que essa história fica um pouco mais complicada. Eu não sei como falar de forma super inteligente com todas essas coisas, mas eu sei que não é necessariamente isso, se você rolar com todas as funções sem servidor, isso é automaticamente uma arquitetura melhor do que qualquer outra arquitetura. Eu gosto disso. Ele raciocina bem para mim, mas não sei se é o fim de todas as arquiteturas. Você sabe?

Drew: Para mim, parece extremamente web, pois... é exatamente assim que o HTML funciona, não é? Você entrega um pouco de HTML e o navegador irá buscar suas imagens e buscar seu JavaScript e buscar seu CSS. Parece que é uma expansão disso -

Cris: É legal.

Drew: … tipo de ideia. Mas, uma coisa que sabemos sobre a web, é que ela foi projetada para ser resiliente porque a rede é frágil.

Chris: Hum (afirmativo).

Drew: Quão robusto é o tipo de abordagem sem servidor? O que acontece se alguma coisa... se um desses pequenos pedaços for embora?

Chris: Isso seria muito ruim. Você sabe? Isso seria um desastre. Seu site cairia como qualquer outro servidor, se acontecer de cair, eu acho.

Drew: Existem maneiras de mitigar isso, que são particularmente -

Cris: Não sei.

Drew: ... adequado para esse tipo de abordagem, que você encontrou?

Cris: Talvez. Quero dizer, como eu disse, uma coisa robusta realmente super chique pode ser como… digamos que você visite o CodePen e digamos que há uma implementação JavaScript do Sass e notamos que você está em uma rede bastante rápida e que está ocioso agora mesmo. Talvez peguemos esse JavaScript e o joguemos em um service worker. Então, se detectarmos que o lambda falha, ou algo assim, ou que você já tem essa coisa instalada, então vamos atingir o service worker em vez do lambda, e os service workers poderão trabalhar offline. Então, isso é legal também. Isso é interessante. Quero dizer, eles são a mesma linguagem-ish. Service workers são JavaScript e muitas funções de nuvem são JavaScript, então há algumas… acho que é uma possibilidade, embora… é apenas, isso é uma técnica séria que… Me assusta ter esse pedaço de JavaScript que você entregou para quantos milhares de usuários, que você não sabe necessariamente o que eles têm e qual versão eles têm. Eca, mas isso é apenas o meu próprio medo. Tenho certeza que algumas pessoas fizeram um bom trabalho com esse tipo de coisa.

Chris: Eu realmente não sei. Talvez você conheça algumas estratégias que eu não conheço, sobre resiliência de serverless.

Drew: Acho que há um modo de falha, um estilo de falha, que pode acontecer com funções sem servidor, onde você executa uma função uma vez e ela falha, e você pode executá-la uma segunda vez imediatamente depois e seria bem-sucedida, porque pode atingir um servidor completamente diferente. Ou seja qual for o problema, quando essa execução pode não existir em uma segunda solicitação. Os problemas de um host inteiro estar inativo é uma coisa, mas talvez haja… você tem problemas individuais com a máquina. Você tem um servidor específico onde sua memória está ruim, e está lançando uma carga de erros, e na primeira vez que você o atinge, ele falhará. Na segunda vez, esse problema pode ter sido enraizado.

Chris: As empresas que tendem a oferecer essa tecnologia, você tem que confiar nelas, mas elas também são o tipo de empresa que... esse é o orgulho delas. Esta é a razão pela qual as pessoas os usam é porque eles são confiáveis. Tenho certeza de que as pessoas podem apontar algumas interrupções da AWS do passado, mas elas tendem a ser um pouco raras e não super comuns. Se você estivesse hospedando sua própria porcaria, aposto que eles o venceram em um nível de porcentagem de SLA. Você sabe? Portanto, não é como “Não construa de maneira resiliente”, mas geralmente o tipo de empresa que oferece essas coisas é bastante confiável. As chances de você cair porque você estragou essa função são muito maiores do que porque a arquitetura deles está falhando.

Drew: Suponho, quero dizer, assim como qualquer coisa em que você está usando uma API ou algo que pode falhar, é apenas certificar-se de estruturar seu código para lidar com esse modo de falha e saber o que acontece a seguir, em vez de apenas jogar até um erro para o usuário, ou apenas morrendo, ou o que você tem. É estar ciente disso e pedir ao usuário que tente novamente. Ou tentando de novo você mesmo, ou algo assim.

Chris: Sim, eu gosto dessa ideia de tentar mais de uma vez, ao invés de apenas dizer “Ah, não. Falhou. Abortar." "Eu não sei, por que você não tenta de novo, amigo?"

Drew: Então, quero dizer, quando se trata de teste e desenvolvimento de funções sem servidor, tipo de funções de nuvem, isso é algo que pode ser feito localmente? Tem que ser feito na nuvem? Existem maneiras de gerenciar isso?

Chris: Eu acho que existem algumas maneiras. Não sei se a história é tão incrível. Ainda é um conceito relativamente novo, então acho que fica cada vez melhor. Mas pelo que sei, por um lado, você está escrevendo uma função Node bastante normal. Supondo que você esteja usando JavaScript para fazer isso, e eu sei que no Lambda especificamente, eles suportam todos os tipos de coisas. Você pode escrever um maldito PHP Cloud Function. Você pode escrever uma função Ruby Cloud. Então, eu sei que estou falando especificamente sobre JavaScript, porque tenho a sensação de que a maioria dessas coisas são JavaScript. Mesmo não importa o idioma, quero dizer, você pode acessar sua linha de comando localmente e executar a coisa. Alguns desses testes são… você apenas testa como faria com qualquer outro código. Você apenas chama a função localmente e vê se funciona.

Chris: É uma história um pouco diferente quando você está falando sobre uma solicitação HTTP para ele, é isso que você está tentando testar. Ele responde ao pedido corretamente? E ele devolve o material corretamente? Não sei. A rede pode se envolver lá. Então você pode querer escrever testes nesse nível. Isso é bom. Não sei. Qual é a história normal lá? Você ativa algum tipo de servidor local ou algo que o sirva. Use o Postman, não sei. Mas há… Frameworks tentam ajudar também. Eu sei que o “.com” sem servidor é terrivelmente confuso, mas existe literalmente uma empresa chamada Serverless e eles criam uma estrutura para escrever as funções sem servidor que ajudam a implantá-las.

Chris: Então, se você gosta de instalar o NPM sem servidor, você obtém sua estrutura. E é amplamente considerado muito bom, porque é muito útil, mas eles não têm sua própria nuvem ou qualquer outra coisa. Você escreve isso e isso ajuda a levá-los a um lambda real. Ou pode funcionar com vários provedores de nuvem. Eu nem sei hoje em dia, mas o propósito de existir deles é facilitar a história da implantação. Não sei o quê... A AWS não é conhecida por sua simplicidade. Você sabe? Existe todo esse mundo de ferramentas para ajudá-lo a usar a AWS e eles são um deles.

Chris: Eles têm algum tipo de produto pago. Eu nem sei o que é exatamente. Eu acho que uma das coisas que eles fazem é… o propósito de usá-los é para testar, é ter um ambiente de desenvolvimento que é para testar sua função serverless.

Drew: Sim, porque acho que isso é uma grande parte do fluxo de trabalho, não é? Se você escreveu sua função JavaScript, testou-a localmente, sabe que ela fará o trabalho. 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: Sim. 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. Não sei. 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. Qualquer que seja. 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. Sim.

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: Sim. 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. I think so. 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: Sim. 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: Sim, sim. Acho que sim, acho que é… porque tem momentos assim… você não precisa ser muito habilidoso para saber o que é apropriado e o que não é para um site. Tipo, eu fiz um pequeno tutorial na outra semana, onde havia esse glitch usa isso... quando você salva um glitch, eles te dão um slug para sua coisa que você construiu, que é, “Whiskey, tango, foxtrot. 1.000.” É como uma coisinha inteligente. As chances de ser único são super altas, porque acho que até acrescentam um número ou algo assim também. Mas eles acabam sendo essas pequenas coisas divertidas. Eles abrem o código de sua biblioteca que contém todas essas palavras, mas são como uma centena, milhares de palavras. O arquivo é enorme. Você sabe? É megabytes grande de apenas um dicionário de palavras. Você provavelmente aprendeu em seu primeiro ano de desenvolvimento: “Não envie um arquivo JavaScript que seja megabytes de um dicionário”. Isso não é uma boa coisa para enviar. Você sabe? Mas o Node não se importa. Você pode enviar centenas deles. É irrelevante para a velocidade em um servidor.

Drew: Sim.

Chris: Não importa em um servidor. Então, eu poderia dizer: “Hmm, bem, vou fazer isso no Node então.” Terei uma declaração que diz: “Palavras iguais exigem palavras”, ou qualquer outra coisa, e uma nota no topo: “Faça com que ele aleatorize um número. Puxe-o para fora da matriz e devolva-o.” Portanto, essa função sem servidor tem oito linhas de código com um packaged@JSON que extrai essa biblioteca de código aberto. E então meu código front-end, há uma URL para a função serverless. Ele atinge esse URL. A URL retorna uma palavra ou um grupo de palavras ou qualquer outra coisa. Você constrói sua própria pequena API para isso. E agora, eu tenho uma coisa muito legal e eficiente. O que foi legal nisso é que é tão simples. Não estou preocupado com a segurança dele. Eu não... você sabe?

Chris: É apenas… um desenvolvedor JavaScript muito mediano ou iniciante, eu acho, pode fazer isso, o que é legal. Isso é uma coisa capacitadora que eles não tinham antes. Antes, eles diziam: “Bem, aqui está um conjunto de palavras de 2 MB”. “Oh, eu não posso enviar isso para o cliente.” "Ah, você vai desligar então." Você pode bater nessa parede que é como, “Eu simplesmente não posso fazer essa parte então. Eu preciso pedir a outra pessoa para me ajudar com isso ou simplesmente não fazer isso ou escolher lesmas mais chatas ou algo assim...” É só que você tem que ir de alguma outra maneira que é um muro para você, porque você não poderia fazê-lo. E agora, você está, “Ah, bem, eu vou...” Em vez de ter isso na minha barra de script, ou na minha pasta de scripts de barra de origem, vou colocá-lo na minha pasta de funções.

Chris: Você meio que moveu o script de uma pasta para outra. E esse é implantado como uma função sem servidor. Quão legal é isso? Você sabe? Você está usando exatamente o mesmo conjunto de habilidades, quase. Ainda há algumas arestas, mas está bem próximo.

Drew: É super legal. Você montou uma espécie de microsite sobre essas idéias, não é?

Cris: Sim. Cheguei um pouco adiantado para o jogo. Eu estava trabalhando nisso hoje, porém, porque… ele recebe pull requests. A ideia… bem, está em serverless.css-tricks.com e… há um traço em CSS-Tricks, a propósito. Então é um subdomínio de CSS-Tricks, e eu o construí sem servidor também, então isso é… CSS-Tricks é como um site WordPress, mas este é um site gerador de site estático. Todo o conteúdo dele está no repositório do GitHub, que é de código aberto. Portanto, se você quiser alterar o conteúdo do site, basta enviar uma solicitação de pesquisa, o que é bom porque já houve uma centena delas ao longo do tempo. Mas eu construí todo o conteúdo original.

Drew: É um lugar super útil, porque lista… Se você está pensando, “Certo, eu quero começar com funções sem servidor”, ele lista todos os provedores que você pode experimentar e…

Chris: Isso é tudo, basicamente, são listas de tecnologia. Sim.

Drew: O que é ótimo, porque, caso contrário, você está apenas pesquisando no Google e não sabe o que está encontrando. Sim, são listas de provedores de API que ajudam você a fazer esse tipo de coisa.

Chris: Forms é um exemplo disso, porque... então no minuto que você escolher... digamos, você vai usar o JAMstack, que eu sei que não é necessariamente o objetivo disso, mas você vê como eles estão de mãos dadas . De repente, você não tem um arquivo PHP ou qualquer outra coisa para processar esse formulário. Como você faz formulários em um site JAMstack? Bem, há várias maneiras de fazer isso. Todos e suas irmãs querem ajudá-lo a resolver esse problema, aparentemente. Então, acho que se eu fosse o inventor da palavra JAMstack, eles tentariam ajudá-lo naturalmente, mas você não precisa usá-los.

Chris: Na verdade, fiquei tão surpreso ao montar este site. Vamos ver. Há seis, nove, doze, quinze, dezoito, vinte e um, vinte e dois serviços por aí, que querem ajudá-lo a processar seus formulários sem servidor neste site agora mesmo. Se você quer ser o 23º, você é bem-vindo, mas há alguma competição lá fora. Então a ideia por trás disso é que você escreva um formulário em HTML, como literalmente um elemento de formulário. E então o atributo de ação do formulário, não pode apontar para nenhum lugar internamente, porque não há nada para apontar. Você não pode processar, então aponta externamente. Ele aponta para o que eles querem que você aponte. Eles processarão o formulário e, em seguida, tendem a fazer coisas que você espera, como enviar uma notificação por e-mail. Ou envie uma coisa do Slack. Ou então envie para o Zapier e o Zapier o enviará para outro lugar. Todos eles têm conjuntos de recursos, preços e coisas ligeiramente diferentes, mas todos estão tentando resolver esse problema para você, como: “Você não quer processar seus próprios formulários? Sem problemas. Processaremos para você.”

Drew: Sim, é um recurso super útil. Eu realmente recomendo que todos confiram. É serverless.css-tricks.com. Então, eu tenho aprendido tudo sobre serverless. O que você tem aprendido ultimamente, Chris?

Chris: Bem, eu ainda estou muito neste mundo e aprendendo sobre coisas sem servidor. Eu tive a ideia de… Eu costumava jogar este RPG online há muito tempo. Descobri recentemente que ainda está vivo. É um tipo de jogo de fantasia medieval baseado em texto. Eu joguei quando a AOL era uma coisa, porque a AOL queria ter esses jogos que você tinha que estar conectado para jogar, porque eles queriam que você passasse horas e horas na AOL, para que eles pudessem enviar essas contas enormes, o que era , tenho certeza, por que eles se saíram tão bem em algum momento.

Drew: Então faturando por segundo. Sim.

Cris: Sim. Então os jogos eram grandes para eles. Se eles pudessem fazer você jogar com outras pessoas lá. Então esse jogo meio que… não estreou lá, mas mudou para a AOL, porque tenho certeza que eles conseguiram um bom negócio por ele, mas era tão… quer dizer, é apenas, não poderia ser mais nerd. Você é um mago anão e recebe um cajado rúnico de sua bainha de couro. E você digita comandos nele como um terminal. Então o jogo responde a você. Joguei esse jogo por muito tempo. Eu estava muito nisso. Eu entrei na comunidade disso e no espírito disso. Foi meio que… era como se eu estivesse sozinho no meu computador, mas ainda assim eu olho para trás naquela época da minha vida e penso: “Aquela foi uma época maravilhosa da minha vida”. Eu estava realmente… eu só gostava das pessoas e do jogo e tudo isso. Mas então eu cresci e parei de jogar, porque a vida acontece com você.

Chris: Eu só descobri recentemente, porque alguém começou a fazer um podcast sobre isso de novo... Não sei como me deparei com isso, mas acabei de descobrir. Eu estava tipo, “Este jogo está vivo e bem no mundo de hoje, você está brincando comigo? Essa coisa baseada em texto.” E fiquei mais do que feliz em reativar e recuperar meus personagens antigos e jogá-lo. Mas só para descobrir que os clientes que eles baixaram para este jogo não evoluíram nada. Eles são horríveis. Eles quase assumem que você está usando o Windows. Há apenas essas renderizações terrivelmente bregas… e é baseado em texto, você acha que pelo menos teria uma boa tipografia. Não. Então eu disse, “Eu poderia estar envolvido. Eu poderia escrever um cliente para este jogo. Coloque uma tipografia bonita nele.” Basta modernizar a coisa, e acho que os jogadores do jogo apreciariam, mas foi esmagador para mim. "Como eu posso fazer isso?" Mas eu encontro alguns projetos de código aberto. Um deles é como… você pode jogar o jogo através de uma janela de terminal real, e ele usa algumas bibliotecas de código aberto para fazer uma GUI de uma janela de terminal.

Drew: Sério?

Cris: Não sei. Então isso foi legal. Eu fiquei tipo, “Se eles escreveram isso, deve haver um código lá para como se conectar ao jogo e fazer tudo funcionar e outras coisas. Então, pelo menos eu tenho algum código inicial.” Eu estava tentando seguir o aplicativo: “Talvez eu faça isso no Flutter ou algo assim”, para que o aplicativo do produto final funcionasse em telefones celulares e “eu poderia realmente modernizar essa coisa”. Mas depois fiquei sobrecarregado. Eu fiquei tipo, “Ah, isso é muito grande… eu não posso. Estou ocupado." Mas eu encontrei outra pessoa que teve a mesma ideia e eles estavam muito mais avançados com ela, então eu poderia contribuir em um nível de design. E tem sido muito divertido trabalhar nisso, mas também tenho aprendido muito, porque é raro eu entrar em um projeto que é o bebê de outra pessoa, e estou apenas contribuindo um pouco, e isso é totalmente diferente opções de tecnologia do que eu jamais teria escolhido.

Chris: É um aplicativo Electron. Eles escolheram isso, que também é um jeito legal de seguir, porque são minhas habilidades na web… então não estou aprendendo nada muito estranho, e é multiplataforma, o que é ótimo. Então, eu tenho aprendido muito sobre Electron. Eu acho divertido.

Drew: Isso é fascinante. É sempre incrível como pequenos projetos paralelos e coisas que fazemos por diversão acabam sendo o lugar onde às vezes mais aprendemos. E aprender habilidades que podem então retroalimentar nosso tipo de trabalho diário.

Chris: Essa é a única maneira que eu aprendo as coisas. Eu sou arrastado para algo que… eu estava tipo, “Eles não são…” É renderizado com uma biblioteca JavaScript chamada Mithril, que é… Eu não sei se você já ouviu falar disso, mas é estranho. Não é… é quase como escrever React sem JSX. Você tem que “criar elemento” e fazer tudo isso… mas é suposto fazer benchmark muito melhor do que isso… E isso realmente importa porque neste jogo baseado em texto, o texto está apenas voando. Há muita manipulação de dados, que é como… você pensaria que este jogo baseado em texto seria tão fácil para uma janela do navegador rodar, mas na verdade não é. Há tanta manipulação de dados acontecendo, que você realmente tem que ser muito... temos que ser conscientes sobre a velocidade da renderização. Você sabe?

Drew: Isso é fascinante-

Cris: Muito legal.

Drew: Sim. Se você, querido ouvinte, gostaria de ouvir mais de Chris, você pode encontrá-lo no Twitter, onde ele é @chriscoyier. Claro, CSS-Tricks podem ser encontrados em css-tricks.com e CodePen em codepen.io. Mas acima de tudo, recomendo que você assine o podcast ShopTalk Show, se ainda não o fez, em shoptalkshow.com. Obrigado por se juntar a nós hoje, Chris. Você tem alguma palavra de despedida?

Chris: Smashingpodcast. com. Espero que seja o URL real.