Smashing Podcast Episódio 29 Com Leslie Cohn-Wein: Como Netlify Dogfood The Jamstack?

Neste episódio, estamos perguntando como é o dogfood do Jamstack na Netlify. Você pode implantar um aplicativo inteiro em uma CDN? Drew McLellan conversa com a engenheira de equipe da Netlify, Leslie Cohn-Wein, para descobrir.

Mostrar notas

• Site pessoal de Leslie
• Leslie no Twitter
• Netlify

Atualização semanal

• Um mergulho em React e Three.js Usando react-three-fiber
  escrito por Fortune Ikechi
• Práticas recomendadas para design de interface de usuário de comércio eletrônico
  escrito por Suzanne Scacca
• Autenticação de aplicativos React com Auth0
  escrito por Nefe Emadamerho-Atori
• Dos especialistas: desenvolvimentos globais de acessibilidade digital durante o COVID-19
  escrito por Robin Christopherson
• O que há de novo no Vue 3?
  escrito por Timi Omoyeni

Transcrição

Drew McLellan: Ela é uma premiada especialista em front-end originalmente de Austin, mas agora morando em Dallas, Texas, por um período em Nova York. Durante esse tempo trabalhando para agências, ela construiu sites para clientes, como Nintendo, WorldPride e Jerry Seinfeld. Ela agora é engenheira de front-end da equipe da Netlify, onde, entre outras coisas, trabalha na construção do aplicativo que os clientes usam para gerenciar seus serviços e implantações. Então, sabemos que ela é uma talentosa engenheira de front-end, mas você sabia que, quando morava em Nova York, ela atuou como juíza assistente de culinária de chili por três anos seguidos. E essa é realmente verdade. Meus amigos, por favor, dêem as boas-vindas a Leslie Cohn-Wein. Olá, Leslie. Como você está?

Leslie Cohn-Wein: Estou arrasando.

Drew: Eu queria falar com você hoje sobre como a Netlify meio que come sua própria comida de cachorro, para usar essa expressão encantadora, quando se trata de construir no Jamstack. Eu deveria contextualizar um pouco, dizendo que até alguns meses atrás, trabalhávamos juntos na mesma equipe da Netlify. E quando cheguei lá, o processo de desenvolvimento era realmente estranho para mim, mesmo depois de 20 anos como desenvolvedor. Eu pensei que era realmente fascinante e vale a pena explorar um pouco, com um público mais amplo. Eu provavelmente deveria salientar que estamos falando sobre isso porque é um estudo de caso genuinamente interessante e não é um grande anúncio patrocinado para a Netlify. Todos deveriam conferir o Vercel. Mas acho que há muitas coisas valiosas que podem ser aprendidas discutindo isso, principalmente do ponto de vista do Jamstack. Porque a Netlify é uma grande defensora da abordagem Jamstack e o serviço é meio que oferecido ao cliente e é construído em torno da ideia de construir projetos Jamstack. Mas o serviço também é construído usando esses princípios. Não é?

Leslie: É, sim. Muitas pessoas pensam nessa arquitetura Jamstack como sites estáticos, mas estamos realmente entendendo o que significa construir um aplicativo Jamstack com o frontend Netlify. Porque é um aplicativo React que é um aplicativo Jamstack completo que nós implantamos Netlify no Netlify então… Sim, estamos realmente testando e forçando os limites do que é possível.

Drew: Acho que às vezes existe essa ideia de que o Jamstack é ótimo apenas para sites estáticos, como você diz, e o aspecto da API entra se você quiser enviar um formulário para um endereço de e-mail e você pode fazer algo fácil assim, mas você possivelmente pode construir um aplicativo da web inteiro dessa maneira. Mas, você está fazendo isso não é?

Leslie: Sim, com certeza. Nosso aplicativo, falando especificamente sobre o que você vê se fizer login em app.netlify.com, é alimentado por… temos uma API REST interna, mas o frontend, como eu disse, é puro Jamstack. Portanto, temos nossa própria etapa de compilação, observamos o aplicativo enquanto ele é compilado no aplicativo e implantamos em nosso próprio sistema.

Drew: Então, quando há um processo de back-end envolvido, e sempre haverá algum tipo de nível de processos de back-end, você sabe, dados persistentes ou, no caso do Netlify, começando com uma implantação ou o que você tem, esse back-end apenas meio que é construído como uma série de APIs que podem ser consumidas pelo frontend?

Leslie: Sim, então há alguns modelos diferentes de como você pode fazer isso funcionar. Na maioria dos casos, em nosso aplicativo, usamos a busca do lado do cliente com o React, certo? Então, servimos uma espécie de shell estático do aplicativo e, em seguida, buscamos as informações do usuário de nossa API REST interna no momento da solicitação. O Jamstack é interessante porque há algumas coisas que você pode pré-construir, e tentamos confiar nisso quando podemos. E então, quando estivermos falando sobre alguns dos dados mais dinâmicos, usaremos essa busca do lado do cliente para garantir que estamos extraindo os dados mais recentes.

Drew: Acho que me surpreendeu, quando comecei a trabalhar no aplicativo, o quanto está sendo alcançado no frontend, principalmente quando se trata de interagir com APIs externas e outras coisas. Eu sei que quando o Netlify interage com seu provedor Git, então ele vai para o GitHub e obtém uma lista de repos, tudo isso está acontecendo entre o seu navegador e o GitHub. E além de talvez… passar por uma função sem servidor que está colocando alguns segredos na solicitação ou algo leve como isso, a maior parte disso está acontecendo de uma maneira Jamstack-y. Não está passando por um tipo de infraestrutura de back-end principal da Netlify. Então, isso é muito fascinante. Isso realmente vai muito além de apenas um site estático com algumas chamadas de API para fazer pequenas coisas. Essa é a funcionalidade central real, não é, que está sendo implementada no navegador?

Leslie: Com certeza. Isso realmente impulsiona, eu acho, esse conceito do que é um engenheiro de desenvolvimento de front-end, certo? E é algo que me impulsiona, como engenheiro de front-end, a ser melhor e a pensar mais sobre esse tipo de… a camada de API, que não é algo de que tradicionalmente estive tão perto. Eu trabalho mais em UI, cores e sistemas de design, então realmente… Na verdade, descobri que trabalhar em um aplicativo Jamstack em escala me levou a ser um desenvolvedor melhor.

Drew: Ser um desenvolvedor frontend não é conhecer CSS de trás para frente, embora isso seja parte disso. Não é saber HTML de trás para frente, mas isso faz parte. Também está entrando nesse território que tradicionalmente era reservado a um engenheiro de back-end, o que é bastante interessante. O Netlify usa a nova renderização do lado do servidor para-

Leslie: Não que eu saiba.

Drew: Então, está tudo literalmente feito, como você diz, você serve um shell e, em seguida, ele é preenchido com solicitações de volta para diferentes pontos finais da API para preencher tudo.

Leslie: Exatamente.

Drew: E você diz que é um aplicativo React?

Leslie: Sim. sim. Reagir. Usamos React Redux agora, e agora somos PostCSS, mas também estamos experimentando com nossa arquitetura CSS.

Drew: Não somos todos? Então, você cria o aplicativo no React e depois o implanta no Netlify?

Leslie: Sim. Talvez minha parte favorita de todo esse processo seja a magia do Deploy Previews, que recebemos através do Netlify. Então, o que acontece é que você… você está trabalhando no GitHub, você aumenta seu PR. Então, você abre seu PR no GitHub, e isso criará automaticamente uma compilação do seu Deploy Preview do aplicativo. Então, na verdade, usamos o Deploy Previews do próprio aplicativo para testar, para garantir que tudo esteja funcionando como deveria. Executamos nossos testes. Isso é o que usamos para verificar manualmente durante a revisão do código. Então, temos toda essa implantação contínua configurada diretamente do GitHub.

Leslie: E uma das outras coisas legais que configuramos é que na verdade temos alguns sites Netlify diferentes que estão puxando do mesmo repositório onde nosso aplicativo está. Então, temos nosso aplicativo, temos uma instância do Storybook que tem nossos componentes de interface do usuário para o aplicativo. Então, temos nosso próprio aplicativo, temos os componentes da interface do usuário do Storybook e temos basicamente um site Netlify que mostra nossa interface do usuário do Storybook. E também temos um terceiro site que executa um analisador de pacotes webpack. Portanto, é uma interface de usuário visual que fornece um mapa de árvore, visualização de todos os pacotes de aplicativos, e podemos avaliar seu tamanho, e é apenas um lembrete para verificarmos novamente. À medida que cada implantação do aplicativo sai, podemos verificar e ter certeza de que não estamos fazendo nada estranho com o tamanho do nosso pacote lá. Portanto, todos os três sites são gerados em uma solicitação de pull do aplicativo. Assim, você receberá links para visualizar, essencialmente, suas visualizações de implantação, tanto do aplicativo Storybook quanto para esse perfil do aplicativo para que possamos verificar.

Drew: E com o Deploy Previews, isso basicamente se torna seu ambiente de teste, não é?

Leslie: Exatamente. Na verdade, não executamos um ambiente de teste tradicional, porque realmente confiamos que nossos Deploy Previews são essencialmente o que será lançado quando pressionarmos o botão de mesclagem e iniciarmos a compilação oficial de nossa ramificação principal em nosso aplicativo principal. Então, eu adoro poder contar com o Deploy Previews como o ambiente de teste. Nós realmente confiamos que vai combinar com a produção. Estamos construindo com todas as variáveis ​​de produção, tudo que... variáveis ​​de ambiente, todas essas coisas são construídas no Deploy Preview. Então, é muito parecido com uma situação sem preocupações. Enquanto o Deploy Preview estiver funcionando, você saberá que o aplicativo também funcionará.

Drew: E eu acho que, como uma organização, se o seu Deploy Preview não corresponder ao que é colocado ao vivo, então esse é um problema de serviço que a Netlify quer resolver. Então, na verdade, funciona muito bem desse ponto de vista. Então, você revisou um Deploy Preview, tudo parece ótimo, o PR é mesclado. O que acontece depois?

Leslie: Então, como o Netlify executa toda a nossa implantação contínua, basicamente temos tudo conectado para que qualquer mesclagem em nossa ramificação principal inicie automaticamente uma implantação oficial de produção com o aplicativo. Então, normalmente, se você é o desenvolvedor que combinou seu próprio PR, você vai aparecer no real... você tem que ter certeza, verifique suas guias, porque se você tiver uma visualização de implantação do aplicativo aberta você tem que ter certeza... você geralmente quer acompanhar no aplicativo real. Então, você tem que verificar sua guia. Mas, sim, no aplicativo, você geralmente entra, você pode assistir os logs de compilação para essa mesclagem que você acabou de iniciar, então é tudo automático. E assim que esses logs de compilação forem concluídos e o site estiver ativo, tudo o que você precisa fazer é atualizar a janela do navegador e verá o que acabou de implantar e deve ser atualizado no aplicativo.

Drew: E digamos que você pega um problema assim que ele for ao ar, o que você faz então?

Leslie: Essa é uma pergunta muito boa. E talvez uma das minhas coisas favoritas sobre o uso do Netlify, mesmo antes de trabalhar no Netlify, foi como um pouco de mágica para mim, porque o Netlify meio que incorporou, o que chamamos de rollbacks. Então, essencialmente todo deploy no Netlify... porque estamos usando essa arquitetura Jamstack, todo deploy é atômico. Então, o que isso significa é que você tem esse histórico completo de todos os tipos de implantação que já fez em um site e pode reverter instantaneamente para qualquer um deles. Portanto, se implantarmos acidentalmente um bug ou algo estiver quebrado, a primeira coisa que costumamos fazer é interromper essa integração contínua. Então, vamos entrar e é apenas um botão na interface do usuário do Netlify que você diz, “Parar publicação automática”, e o que isso fará é interromper a conexão com o GitHub. Então, se meu companheiro de equipe de repente também fundir seu PR, não vamos reintroduzir o bug, nada disso vai acontecer.

Leslie: Então, paramos todas essas implantações automáticas. E então tudo o que tenho a fazer é voltar à minha lista de implantações e encontrar a última implantação em funcionamento, pressionar mais um botão que diz “Publicar esta” e ela será ativada. Então, o que isso faz é tirar essa pressão para poder realmente voltar, olhar para o código, descobrir o que realmente aconteceu. Às vezes, isso significa fazer uma reversão do Git em sua ramificação principal e colocar a ramificação principal de volta onde precisava estar. E às vezes é um hot fix ou você sai em um branch e o conserta e você realmente não precisa se preocupar em reverter no Git. E então, quando estiver pronto para voltar, verifique se tudo está funcionando na visualização de implantação do aplicativo e você pode simplesmente redefinir tudo isso de volta. Assim, assim que você iniciar essas implantações automáticas, você estará basicamente de volta aos negócios.

Drew: Então, eu encontrei um problema aqui.

Leslie: Ah.

Drew: Você está usando o Netlify para implantar alterações no aplicativo Netlify. E se o bug que você implantou o impedir de reverter? O que fazes, então?

Leslie: Eu tenho pesadelos. Não. Na verdade, temos algumas maneiras de lidar com isso. Portanto, se desativarmos o aplicativo e não pudermos usar a interface do usuário para passar por esse processo, nossas visualizações de implantação serão executadas em nossa API de produção. Então, o que isso significa é que, mesmo que o aplicativo não esteja funcionando, ainda temos essas implantações atômicas. Portanto, se você tiver um link do GitHub, talvez de um PR antigo ou recente, e tiver esse URL de visualização de implantação, poderá acessar a visualização de implantação do aplicativo e fazer qualquer alteração necessária, voltar e publicar uma implantação mais antiga na visualização de implantação. E ainda está atingindo nossa API de produção, então isso ainda afetará o aplicativo, e isso fará com que o aplicativo volte a funcionar. É como um emoji de cérebro explodindo lá, mas é uma maneira de fazer isso. Também poderíamos publicar uma implantação mais antiga de alguns de nossos sistemas de back-end. Podemos fazer com que nossos engenheiros de back-end publiquem isso para nós. Ou você sempre pode usar o Git para reverter e tentar empurrar isso, mas é um pouco assustador porque você não pode assistir o que está fazendo.

Drew: Acho que você só precisa de uma mente muito clara para administrar essa situação.

Leslie: Sim.

Drew: Mas é totalmente recuperável, parece que sim.

Leslie: Sim. Bem, e uma vez que você publicou seu desdobramento de trabalho, toda a pressão está desligada. Essa é realmente a parte mais legal. E eu encontrei isso trabalhando em agências também. Ser capaz de reverter foi realmente um salva-vidas para… Também deixa você menos preocupado com a publicação de novas alterações. Se você quebrar alguma coisa, leva um segundo para rolar de volta, o que se encaixa muito bem com o tipo de movimento rápido e tira as coisas do modelo.

Drew: Com certeza. Eu acho que normalmente esse tipo de fluxo de trabalho inteiro funciona melhor quando você está lidando com mudanças muito pequenas. Quero dizer, idealmente você quer criar uma ramificação, implementar uma pequena mudança, gerar um PR e, em seguida, fazer a mesclagem de volta o mais rápido possível. O que obviamente funciona bem para ajustes e correções de bugs e pequenas coisas, mas não funciona tão bem para o trabalho de recursos principais quando esse recurso pode levar semanas ou talvez até meses desde o início até estar pronto para implantação. Como você gerencia esse tipo de processo?

Leslie: Sim, essa é uma ótima pergunta. Então, recentemente começamos a usar sinalizadores de recursos um pouco mais. Antes de falar um pouco mais sobre como fazemos isso, vou falar sobre o que costumávamos fazer. Então, antes de usarmos sinalizadores de recursos, acho que todos estão familiarizados com a ideia do branch de recursos de longa duração. Todos nós meio que os odiamos, certo? Mas trabalharíamos em nossos PRs menores. Nós mesclaríamos cada um deles individualmente, após a revisão do código, nesta ramificação de recursos de execução mais longa. Então, você basicamente teria todos os seus novos recursos em um só lugar, você poderia ter um Deploy Preview com o qual você pode testar esse novo recurso. Às vezes, esse modelo exigia implantações coordenadas em outras equipes. Então, quando estávamos prontos para dizer: “Ok, este branch de recursos, estamos prontos para mesclá-lo e colocá-lo no ar”, ocasionalmente isso significava: “Ok, você precisa ter certeza de que o back-end já implantou sua alteração”, então, seja qual for O trabalho de API que estamos fazendo em nosso recurso está pronto. Se houver documentos em nosso site de documentos que precisam ser publicados ao mesmo tempo que o recurso, você meio que precisa coordenar e apertar os botões ao mesmo tempo.

Leslie: Este modelo é... funcionou para nós, mas você está certo, talvez não tenha sido o mais suave. Na verdade, é meio engraçado, nosso cofundador e CEO da Netlify, Matt Biilmann, lançou nosso recurso de análise usando esse processo no palco da Jamstack Conf London no ano passado. Então, ele usou nosso recurso de implantações de bloqueio para basicamente fazer o Deploy Preview do novo recurso de análise e publicá-lo ao vivo no palco. Então isso foi muito legal.

Leslie: Mas, como você disse, é... você tem um pouco menos de confiança. Tudo ainda está meio escondido nesta Pull Request. Torna-se um pouco pesado. Alguém tem que aprovar aquele Pull Request final que normalmente é bem grande. Isso é um pouco esmagador. Então, hoje em dia estamos usando principalmente sinalizadores de recursos. Usamos um serviço chamado LaunchDarkly, que nos permite basicamente envolver nossa nova interface do usuário de recursos com esses sinalizadores, para que possamos continuar mesclando código continuamente, mesmo que a interface do usuário não seja algo que queremos que os clientes vejam. Então, você apenas garante no ambiente de produção que seu sinalizador de recurso está desativado, podemos implantar o código, mesclá-lo e ninguém... supondo que você seja um usuário geral, não verá essa nova interface do usuário.

Drew: Então, um sinalizador de recurso é basicamente como um interruptor no código que diz: “Se esse recurso estiver ativado, use este novo código, caso contrário, use este código antigo”.

Leslie: Exatamente.

Drew: Isso significa que você tem uma base de código meio bagunçada com todas essas bifurcações no lugar? Como você lida com isso?

Leslie: Sim, eu acho que... qualquer um que usa sinalizadores de recursos provavelmente está acostumado a esse tipo de batalha de quando você limpa os sinalizadores de recursos? Quanto tempo você os deixa lá? Nós meio que desembarcamos em cerca de duas semanas após o lançamento de um recurso importante, é que temos lembretes. Felizmente, o LaunchDarkly configurou recentemente um recurso que notificará o Slack. Então, você pode conectá-lo ao Slack e ele apenas dirá: “Ei, seu sinalizador de recurso foi… Você está em produção há duas semanas. Já está na hora de garantir que você limpe sua bandeira no código.”

Leslie: Então, nós tentamos e limpamos bem rápido, mas é, nesse meio tempo, é bom saber que a bandeira ainda está lá. Mesmo que você tenha lançado o recurso, isso significa que, novamente, com um clique, você pode entrar e alternar esse sinalizador, se houver um bug, se houver algo que apareça. Então, gostamos de deixá-los um pouco, apenas enquanto o recurso está realmente funcionando, enquanto as pessoas estão se acostumando, para garantir que não haja problemas maiores. Mas então tentamos voltar ao código e é um pouco de limpeza, então não é um processo ideal, mas geralmente remover o sinalizador não demora muito, você está apenas excluindo algumas linhas de código.

Drew: Então, acho que a abordagem mais simples para implementar um sinalizador de recurso pode ser apenas... como uma variável de configuração em seu aplicativo que diz: "Este recurso está ativado ou desativado", mas você precisa de alguma maneira de garantir que está ligado para as pessoas certas e desligado para as pessoas certas. E acho que é aí que entra um serviço como o LaunchDarkly, porque leva isso... quer dizer, leva basicamente o que está ligando e desligando uma variável a um nível extremo, não é?

Leslie: Sim. sim. É exatamente isso. Então, existem maneiras que poderíamos ter, mesmo sem o LaunchDarkly, basicamente configurar uma variável de configuração que nós gerenciamos do nosso lado. Uma das coisas que eu amo no LaunchDarkly é que existem ambientes diferentes. Então, o que podemos fazer é essencialmente ativar um sinalizador de recurso para nossas visualizações de implantação. Assim, qualquer pessoa que esteja visualizando internamente na Netlify, um Deploy Preview do aplicativo pode ter acesso ao novo recurso, pode testá-lo, mas, novamente, assim que ele entrar em produção, esse sinalizador será desativado. Então, há muito pouco... mais uma vez, você precisa verificar sua guia e ter certeza de que tipo de segmento você está, porque você não quer se surpreender e pensar que lançou algo que você não fez, você tem que ter um pouco de cuidado lá. Mas, em geral, funciona muito bem, e o LaunchDarkly permite que você também faça esses lançamentos seletivos. Assim, você pode lançar um recurso para uma porcentagem de sua base de código ou para um segmento de usuário específico, pessoas com um tipo específico de plano ou um tipo específico de usuário. Então, isso permite muito mais controle sobre para quem você está liberando.

Drew: Sim. Isso pode ser realmente poderoso, eu acho, principalmente com novos recursos ou recursos que você pode esperar para resolver um problema. Talvez você esteja aprimorando um recurso para torná-lo mais compreensível, talvez possa experimentá-lo com 10% dos usuários e ver se eles estão enfrentando os mesmos problemas e…

Leslie: Exatamente. É uma ótima maneira de obter feedback também, sim.

Drew: Acho que usar o LaunchDarkly dessa maneira, em vez de lançar sua própria solução, é outro aspecto da abordagem do Jamstack, não é? É apenas usar uma API que oferece essa funcionalidade sem ter que se preocupar em como você implementa isso e como desenvolvê-la e como mantê-la e mantê-la para que você possa terceirizar, digamos, “Certo, estamos vai usar esta API e todo o resto é cuidado.”

Leslie: Sim. Sim, exatamente.

Drew: Então, essa abordagem permite que você comprometa pequenos pedaços de novos recursos essencialmente para produção, mas eles estão meio que escondidos atrás da bandeira. E então, quando tudo estiver pronto, você pode simplesmente virar a bandeira e rapidamente trocá-la novamente se algo der errado.

Leslie: Sim, exatamente. Isso torna nossos lançamentos um pouco menos emocionantes. Antes, você pressionava esses botões grandes e havia todo esse código sendo mesclado e você observava seus logs de compilação e é esse momento de antecipação. E agora você entra em uma chamada do Zoom, clica em um botão e está ao vivo.

Drew: Sim. Acho que no último lançamento de recurso, trabalhei em um Netlify, usamos essa abordagem. E foram semanas de trabalho para toda uma equipe de pessoas, e recebemos uma ligação do Zoom para coordenar o lançamento, e todos confirmaram que suas peças estavam prontas. E então eu virei o sinalizador de recurso e o ativei para todos os usuários, e foi isso.

Leslie: Pronto.

Drew: E acabou em poucos minutos e foi realmente um anticlímax.

Leslie: Sim, é meio triste.

Drew: Não havia palmas das mãos suadas, não havia nada, o que, claro, é exatamente o que você quer, não é? É assim que você sabe que tem um processo robusto, se ativar algo para todos não for grande coisa.

Leslie: Exatamente. E se você tiver que reverter, novamente, é simples assim, é aquele clique. Isso alivia um pouco dessa pressão, ansiedade.

Drew: Então, presumivelmente, quero dizer, nem todas as mudanças serão apenas mudanças de front-end. Às vezes, haverá alterações de back-end e, presumivelmente, eles também terão seus próprios sinalizadores de recursos na maioria dos sistemas de back-end. Então, você mencionou documentos também. Existe uma maneira de coordenar tudo isso juntos? Todo mundo apenas agita suas bandeiras ao mesmo tempo? Ou como isso funciona?

Leslie: Sim. Então, esta é uma área em que estamos trabalhando ativamente em todas as equipes agora na Netlify, está trabalhando em uma solução que nos permitiria talvez amarrar tudo a um único sinalizador no LaunchDarkly, que todos os nossos sistemas estão usando , todas as nossas bases de código estão usando. Então, em um mundo ideal, poderíamos virar um sinalizador e dizer: “Ok, isso está alternando no novo ponto final da API que também está sendo consumido no frontend com essa nova interface do usuário que está envolvida em um sinalizador de recurso, bem como esta parte do site doc, que tem novas informações sobre esse novo recurso.” E você vira esse sinalizador afeta todos esses repositórios. Ainda não chegamos lá. Estamos trabalhando nisso, mas estou animado para ver se somos capazes de coordenar e trabalhar tudo isso.

Drew: O Netlify, como serviço, é muito adaptado para construir sites dessa maneira. O trabalho que você e sua equipe estão fazendo usando o produto realmente influenciou o desenvolvimento do produto?

Leslie: Eu diria que sim. Todo mundo sempre diz que você não é seu usuário, o que eu acho que é verdade na maioria das vezes, exceto às vezes quando você é seu usuário. O que é engraçado no Netlify porque acho que a maioria das pessoas na equipe de frontend em particular são pessoas que usaram o Netlify antes como um produto. E certamente porque estamos usando o Netlify para implantar o Netlify, enfrentamos os mesmos desafios que acho que alguns de nossos usuários enfrentam. Então, de certa forma, se encontrarmos um problema, tentaremos trazê-lo ao resto da empresa. Vamos mencioná-lo em uma chamada de engenharia ou vamos chamar nosso CTO e dizer: “Ei, isso é algo com o qual estamos lutando. Existe algo que poderíamos construir no produto que tornaria isso mais fácil para nós e para todos os nossos usuários que estão implantando coisas semelhantes às nossas?” Portanto, é uma posição única para se estar, mas é divertido ver como o roteiro do produto é desenvolvido.

Drew: Acho que provavelmente há poucas pessoas usando o Netlify tão intensamente quanto o próprio Netlify.

Leslie: Sim. Sim. Acho que está certo. Eu olho para o Netlify tanto quando estou construindo quanto quando estou implantando, então estou bastante familiarizado com ele.

Drew: E então no fim de semana você trabalha em um projeto paralelo e se encontra de volta ao Netlify novamente.

Leslie: Sim. Isso é realmente muito verdadeiro. Sim. sim. sim, de fato.

Drew: Você tem algum exemplo de como a direção do produto foi influenciada pelo trabalho que a equipe fez?

Leslie: Sim. Então, lançamos recentemente um novo tipo de painel de aterrissagem para o aplicativo que estamos chamando de Visão geral da equipe. Então, costumava ser quando você entrava no Netlify, você chegava à página do site, que seria basicamente uma longa lista de seus sites. E queríamos dar às pessoas um pouco mais de uma área de controle de missão onde elas pudessem ver muitas informações importantes de relance, ter acesso a coisas que serão mais úteis para elas. E então, esse foi um novo recurso que construímos. Na iteração inicial, estamos tentando lançá-lo rapidamente, temos um pequeno cartão nessa interface do usuário que vincula às suas versões mais recentes. Ele mostra qualquer construção em toda a sua equipe, deve aparecer nesse cartão.

Leslie: E no início, nós realmente não os vinculamos à construção... o próprio log de exibição. Então, era apenas uma lista onde você poderia conferir. Você pode clicar na página de builds para obter uma visão semelhante. Mas eu estava realmente trabalhando em algo no fim de semana, um site pessoal, e eu tinha essa visão geral da equipe ativada e fiquei irritado porque percebi que entrei no Netlify e queria dar uma olhada nessa compilação que estava acontecendo no meu projeto, e eu não podia simplesmente clicar nele e ir direto a ele. Eu tive que clicar na página de builds e depois clicar novamente. Então, no dia seguinte no trabalho, entrei e adicionei essa mudança e vinculei essas construções porque estava me incomodando. Então, esse foi um exemplo de apenas perceber, usando o produto, que havia uma oportunidade muito pequena de melhorá-lo. E nós levamos isso.

Leslie: Mas também temos alguns outros exemplos. Provavelmente um pouco mais impactante. Uma é que adicionamos esse recurso de detecção de formulário. Então, um pouco de fundo, se você não estiver familiarizado, os formulários do Netlify são um recurso do Netlify que permite criar um formulário de front-end. E o Netlify meio que faz todo o trabalho de back-end de gerenciamento de envios. É como seu banco de dados para seu formulário que você construiu em seu frontend. Isso significa que você não precisa escrever nenhum código do lado do servidor ou muito JavaScript extra para gerenciar envios de formulários. Realmente qualquer site que você implantou no Netlify, enquanto sua compilação está acontecendo, nossos bots de compilação estão analisando o HTML do seu site no momento da implantação para detectar basicamente se você tem um formulário Netlify que o Netlify precisa prestar atenção e gerenciar. E essa detecção de formulário, que o bot de compilação está procurando, é habilitada por padrão.

Leslie: Mas o que isso significa é que, como você pode imaginar, isso consome um pouco do seu tempo de construção porque os bots precisam procurar por essa etapa extra. Então, o próprio aplicativo Netlify, na verdade, não estamos usando, não temos nenhum formulário Netlify no aplicativo agora. Então, este é um passo que basicamente está adicionando um pouco ao nosso tempo de construção, mas não necessariamente precisa acontecer. Então, a Netlify realmente criou um novo recurso que permite que qualquer usuário desative essa detecção de formulário. O que isso significa é que você pode desativar essa configuração nas configurações do seu site, os bots de compilação percebem que não há nada que eles precisem procurar, então você economiza um pouco de tempo extra de processamento nas compilações.

Drew: Acho que isso é ótimo em termos de produtividade, porque as coisas terminam um pouco mais rápido.

Leslie: Exatamente.

Drew: Mas também, como um serviço medido, permite que você obtenha mais do tipo de permissão que você tem.

Leslie: Sim. Exatamente. E então, isso foi algo que também ouvimos de alguns de nossos usuários e clientes, e foi algo que notamos também. Era: “Bem, não precisamos dessa etapa extra em nosso próprio produto. Então, existe uma maneira, algo que poderíamos dar a todos os nossos usuários para tornar a vida de todos um pouco mais fácil, tornar a construção de todos um pouco mais rápida se eles não estiverem usando esse recurso?”

Drew: Existe algum perigo... Quer dizer, você diz que não é seu usuário, mas com o Netlify muitas vezes você é seu usuário. Existe o perigo de que, com a intensidade com que você usa o produto, você possa ignorar o tipo de usuário que o está usando muito levemente e tudo pode ficar muito complexo e muito avançado, e se tornar muito difícil obter começou?

Leslie: Essa é uma ótima pergunta. Também desenvolvemos nossa função de pesquisa de usuários na Netlify e nossa função de ciência de dados, e acho que, no geral, confiamos muito mais neles do que em minha experiência anedótica usando e implantando o aplicativo. Mas acho que todos esses dados se juntam para nos permitir ter uma visão melhor de quem está usando o Netlify, com que tipo de usuário estamos falando? Existem pessoas com diferentes tipos de necessidades. Temos pessoas em nossas equipes iniciais que gerenciam blogs e sites pessoais, e também temos grandes empresas, que estão lançando grandes campanhas de marketing e grandes aplicativos da web, não muito diferentes da própria Netlify. Então, é empolgante ver a base de usuários crescer e pensar em todos esses casos de uso e descobrir como podemos atender a todos esses usuários. E certamente usando mais nossa funcionalidade de pesquisa para entender quem são esses usuários, não apenas nossa experiência interna.

Drew: Conte-me, Leslie, sobre o serviço de captura de tela que o Netlify tem? Porque eu achei isso muito interessante.

Leslie: Sim. Na interface do usuário, temos… quando você implanta um site no Netlify, na interface do usuário, temos uma pequena captura de tela que mostra normalmente como é a página inicial do site que você sentiu. É realmente engraçado termos trazido isso à tona, porque eu estava ouvindo Chris Coyier seu episódio no Serverless não muito tempo atrás, e ele estava falando sobre como eles fazem capturas de tela no CodePen também, o que na verdade não é tão diferente de como o Netlify faz isso. Mas basicamente executamos o Puppeteer para capturar essa captura de tela do site do usuário, e a maneira como tudo é executado é configurado com uma função Netlify. Então, este é novamente um exemplo de nós dogfood nosso próprio produto. Então, essencialmente, usamos esse ponto final que é uma função Netlify dentro de nosso próprio aplicativo para retornar a URL dessa imagem da captura de tela, que podemos servir no aplicativo.

Drew: Então as funções do Netlify são a implementação do Netlify de uma função sem servidor, não são? Onde você basicamente solta um arquivo JavaScript em uma pasta designada como parte de sua fonte, e então isso fica disponível para ser executado como uma função de nuvem.

Leslie: Sim, exatamente.

Drew: Super inteligente, não é?

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

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

Leslie: Yeah. Sim.

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

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

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

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

Leslie: Yikes.

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

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

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

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

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

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

Leslie: Yeah, definitely.

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

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

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

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

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

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

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

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

Leslie: Have a great day?