Fundamentos do JAMstack: o que, o que e como

Adoramos ultrapassar os limites da web, por isso decidimos tentar algo novo. Você provavelmente já ouviu falar do JAMstack — a nova pilha da Web baseada em JavaScript, APIs e Markup — mas o que isso significa para seu fluxo de trabalho e quando faz sentido em seus projetos?

Como parte da nossa Associação Smashing, realizamos o Smashing TV , uma série de webinars ao vivo, todas as semanas. Sem enrolação - apenas webinars práticos e acionáveis ​​com perguntas e respostas ao vivo, ministrados por profissionais respeitados do setor. De fato, a programação da Smashing TV já parece bastante densa, e é gratuita para os membros do Smashing, junto com as gravações – obviamente .

Pedimos gentilmente a Phil Hawksworth para realizar um webinar explicando o que o JAMStack realmente significa e quando faz sentido, bem como como isso afeta as ferramentas e a arquitetura de front-end. O webinar de uma hora também está disponível. Não poderíamos estar mais felizes em receber Phil como co-MC da nossa próxima SmashingConf Toronto (25 a 26 de junho) e administrar a JAMStack_conf London, que co-organizamos de 9 a 10 de julho deste ano também. Então, vamos ao que interessa!

Phil Hawksworth: Excelente, ok, bem, vamos ao que interessa então. Apenas como um olá muito rápido, quero dizer, eu já disse olá, Scott me deu uma boa apresentação. Mas sim, atualmente trabalho na Netlify, trabalho na equipe de experiência do desenvolvedor lá. Esperamos ter bastante tempo para perguntas e respostas, mas, como Scott mencionou, se você não tiver a chance de fazer perguntas lá, ou se preferir, pode enviar um ping diretamente para mim no Twitter, então meu Twitter lida com é meu nome, é Phil Hawksworth, então a qualquer momento você pode me fazer perguntas sobre o JAMstack ou qualquer coisa no Twitter.

Phil Hawksworth: Mas eu quero começar hoje apenas voltando um pouco no tempo para esta citação que realmente ressoa muito forte comigo. Esta é uma citação do maravilhoso Aaron Schwartz que, é claro, contribuiu muito para o Creative Commons e a web aberta e ele escreveu isso em seu blog em 2002, e ele disse: “Eu me importo em não ter que ficar irritado Servidor AOL, instalações Postgres e Oracle.” servidor AOL, eu tive que olhar para cima para me lembrar que era um servidor web de código aberto na época.

Phil Hawksworth: Mas isso mexe muito comigo. Eu também não quero manter a infraestrutura para manter um blog vivo, e era disso que ele estava falando. E foi neste post em seu próprio blog e foi intitulado “Bake, Don't Fry”. Ele estava escolhendo um termo que alguém que construiu um CMS recentemente começou a usar, e ele meio que popularizou esse termo sobre panificação (Assar, Não Fritar); o que ele está falando lá é pré-renderização em vez de renderização sob demanda, então assar o conteúdo antes do tempo, em vez de fritá-lo sob demanda quando as pessoas vêm e pedem - tirando as coisas do tempo de solicitação e entrando no tempo de construção.

Phil Hawksworth: E quando estamos falando sobre pré-renderização e renderização, o que queremos dizer com isso é que estamos falando sobre geração de marcação. Eu me sinto um pouco constrangido, às vezes, falando sobre o tipo de renderização do servidor ou renderização isomórfica ou muitos desses termos da moda; Fui chamado há alguns anos em uma conferência, Frontiers Conference, em Amsterdã, quando estava falando sobre renderização no servidor e alguém me disse: “Você quer dizer gerar HTML? Apenas algo que produz HTML?” E é isso, claro, o que quero dizer.

Phil Hawksworth: Mas tudo isso ajuda bastante a simplificar o stack. Quando pensamos na pilha a partir da qual servimos sites; Estou tentando simplificar as coisas, estou super interessado em tentar simplificar a pilha. E isso é meio que no coração dessa coisa chamada “JAMstack” e eu quero tentar explicar isso um pouco. O “JAM” no JAMstack significa JavaScript, APIs e Markup. Mas isso não é suficiente para nos ajudar a entender o que isso significa – o que diabos isso realmente significa?

Phil Hawksworth: Bem, o que eu quero tentar fazer na próxima meia hora, é meio que expandir essa definição e dar mais uma descrição do que é o JAMstack. Eu quero falar um pouco sobre o impacto e as implicações do JAMstack, e, você sabe, pensar sobre o que isso pode nos dar sobre por que podemos escolhê-lo. Ao longo do caminho, tentarei mencionar algumas das ferramentas e serviços que serão úteis e, com sorte, encerrarei com alguns recursos nos quais você pode se aprofundar e talvez mencionar alguns primeiros passos para que você em andamento.

Phil Hawksworth: Então, esse é o plano para a próxima meia hora. Mas, eu quero, mais ou menos, voltar a essa noção de simplificar a pilha, porque, espero, as pessoas que se juntarem a isso ou virem assistir a este vídeo mais tarde, talvez você tenha uma noção do que é JAMstack, ou talvez seja um termo completamente novo, e você está apenas curioso. Mas, em última análise, já existem muitas pilhas por aí. Há muitas maneiras que você pode entregar um site. Parece que estamos construindo diferentes tipos de infraestrutura há muito tempo, seja uma pilha LAMP ou a pilha MAMP, ou a - não sei - a pilha MEAN. Há um monte deles flutuando na tela aqui. Há muitos e muitos deles.

Phil Hawksworth: Então, por que diabos precisaríamos de outro? Bem, JAMstack é, como mencionei, JavaScript/API/Markup, mas se tentarmos ser um pouco mais descritivos, JAMstack pretende ser uma arquitetura moderna, para ajudar a criar sites rápidos e seguros e aplicativos dinâmicos com JavaScript/ APIs e marcação pré-renderizada, servidos sem servidores web, e é este último ponto que é algo que o diferencia e talvez o torna um pouco mais interessante e incomum.

Phil Hawksworth: Essa noção de servir algo sem servidores web, que soa mágico ou ridículo, e esperamos descobrir o que ao longo do caminho. Mas para tentar esclarecer isso e descrevê-lo com um pouco mais de detalhes, às vezes é útil compará-lo com o que podemos pensar como uma pilha tradicional ou uma maneira tradicional de servir coisas na web. Então, vamos fazer isso só por um segundo. Vamos apenas explicar, talvez, como uma solicitação pode parecer ao ser atendida em uma pilha tradicional.

Phil Hawksworth: Então, neste cenário, temos alguém abrindo um navegador da web e fazendo uma solicitação para ver uma página. E talvez essa solicitação atinja um CDN, mas provavelmente, mais provavelmente, atingiu alguma outra infraestrutura que estamos hospedando – como as pessoas que possuem este site. Talvez tenhamos tentado garantir que isso seja dimensionado sob muita carga porque, obviamente, queremos uma visão muito popular e bem-sucedida. Então, talvez tenhamos um balanceador de carga, que tenha alguma lógica nele, que atenderá essa solicitação a um dos vários servidores da Web que provisionamos, configuramos e implantamos. Pode haver vários desses servidores.

Phil Hawksworth: E esses servidores executarão alguma lógica para dizer: “Ok, aqui está nosso modelo, precisamos preenchê-lo com alguns dados”. Podemos obter nossos dados de um dos vários servidores de banco de dados que executarão alguma lógica para procurar alguns dados, devolvê-los ao servidor da Web, criar uma visualização que, em seguida, passaremos de volta pelo balanceador de carga. Talvez, ao longo do caminho, ligando para a CDN, armazenando alguns ativos na CDN, e devo esclarecer, uma CDN é uma rede de entrega de conteúdo, portanto, uma rede de máquinas distribuídas pela Internet para tentar obter o serviço de solicitação o mais próximo possível para o usuário e adicionar coisas, como cache.

Phil Hawksworth: Então, podemos armazenar alguns recursos lá e, finalmente, retornar uma visualização no navegador, nos olhos do usuário, que pode experimentar o site que construímos. Então, obviamente, isso é uma simplificação excessiva ou uma visão muito geral de como podemos atender uma solicitação em uma pilha tradicional. Se compararmos isso com o JAMstack, que está atendendo as coisas de uma maneira um pouco diferente, é assim que pode parecer.

Phil Hawksworth: Então, novamente, no mesmo cenário, estamos começando em um navegador da web. Estamos solicitando uma visualização da página, e essa página já está em uma CDN. Ele serve estaticamente a partir daí, então é devolvido ao usuário, no navegador, e pronto. Então, obviamente, uma visão muito simplificada, mas logo de cara, você pode começar a ver as diferenças aqui em termos de complexidade. Em termos de lugares que precisamos gerenciar código, codificar profundamente, todas essas coisas diferentes. Então, para mim, um dos principais atributos de um JAMstack é que isso significa que você está construindo um site capaz de ser servido diretamente de um CDN, ou mesmo de um servidor de arquivos estático. CDN é algo que podemos querer implementar para lidar com a carga, mas, em última análise, isso pode ser servido diretamente de qualquer tipo de servidor de arquivos estático, tipo de infraestrutura de hospedagem estática.

Phil Hawksworth: O JAMstack, mais ou menos, oferece uma oportunidade de reduzir a complexidade. Apenas comparando essas duas partes do diagrama às quais voltaremos algumas vezes, ao longo da próxima meia hora, você pode ver que é uma oportunidade para reduzir a complexidade e reduzir o risco. Então, isso significa que podemos começar a aproveitar alguns dos benefícios de servir ativos estáticos, e falarei sobre o que são um pouco mais adiante. Mas você pode estar olhando para isso e pensando: "Bem, ótimo, mas esse não é apenas o novo nome para sites estáticos?" Isso é uma coisa razoável para mim quando digo: “Vamos servir as coisas estaticamente”.

Phil Hawksworth: Mas eu quero voltar a isso. Eu quero falar um pouco mais sobre isso, mas antes de tudo, eu quero, meio que, falar sobre essa noção de pilhas e o que diabos é uma pilha, afinal? E eu penso em uma pilha como as camadas de tecnologia que entregam seu site ou aplicativo. E não estamos falando sobre o pipeline de construção ou o processo de desenvolvimento, mas certamente a maneira como atendemos os sites pode ter um grande impacto em como desenvolvemos e implantamos coisas e assim por diante.

Phil Hawksworth: Mas aqui, estamos falando sobre a pilha de tecnologia, as camadas de tecnologia, que realmente entregam seu site e seu aplicativo aos usuários. Então, vamos fazer outra pequena comparação. Vamos falar sobre a pilha LAMP por um segundo.

Phil Hawksworth: A pilha LAMP, você deve se lembrar, é composta de um servidor web apache, para fazer coisas como o roteamento HCP e o serviço de ativos estáticos. PHP, para algum pré-processamento, processamento de hipertexto tão bonito; aplicando a lógica, talvez construindo as visualizações para os modelos e o que você tem. E tem algum acesso aos seus dados, pelo meu NISQL, e então o LINUX é o sistema operacional que fica por baixo de tudo isso, mantém tudo isso respirando. Podemos agrupar isso em conjunto como este servidor web. E podemos ter muitos desses servidores, mais ou menos, sentados juntos para servir um site.

Phil Hawksworth: Essa é uma visão meio tradicional da pilha LAMP, e se compararmos com a pilha JAM, bem, aqui há uma mudança crítica. Aqui, estamos realmente subindo de nível, em vez de pensar no sistema operacional e pensar em como executamos a lógica para entregar um site. Aqui estamos supondo que vamos servir essas coisas estaticamente. Então, estamos fazendo o roteamento ACP e o serviço de ativos de um servidor estático. Isso pode ser feito razoavelmente. Ficamos muito bons nisso, ao longo dos anos, criando maneiras de entregar sites estáticos ou ativos estáticos.

Phil Hawksworth: Isso pode ser um CDN e, novamente, falaremos sobre isso em um momento. Mas a área de interesse para nós, está acontecendo mais no navegador. Então, aqui é onde nossa marcação é entregue e analisada. É aqui que o JavaScript pode ser executado, e isso está acontecendo no navegador. De muitas maneiras, o navegador se tornou o tempo de execução da web moderna. Em vez de ter o tempo de execução na própria infraestrutura do servidor, agora elevamos isso um nível, mais próximo do usuário e no navegador.

Phil Hawksworth: Quando se trata de acessar dados, bem, isso está acontecendo por meio de, possivelmente, APIs externas, fazendo chamadas via JavaScripts para essas APIs externas para obter acesso ao servidor, ou podemos pensar em APIs como APIs do navegador, podendo interagir com JavaScript com recursos ali mesmo no seu navegador.

Phil Hawksworth: De qualquer forma, a chave aqui sobre o JAMstack é que, estamos falando de coisas que são pré-renderizadas: elas são servidas estaticamente e então, elas podem ser progressivamente aprimoradas no navegador para fazer uso de APIs do navegador, JavaScripts , e o que você tem.

Phil Hawksworth: Então, vamos fazer essa pequena comparação lado a lado aqui. Novamente, eu só quero reiterar que o JAMstack subiu um nível para o navegador. E se virmos os dois lados deste diagrama, com a pilha LAMP à esquerda e efetivamente, a pilha JAM à direita, você pode até pensar que, bem, mesmo quando estávamos construindo coisas com a pilha LAMP, ainda estávamos saída de marcação. Ainda estamos produzindo JavaScript. Ainda podemos estar acessando APIs. Então, de muitas maneiras, o JAMstack é quase como um subconjunto do que estávamos construindo antes.

Phil Hawksworth: Eu costumava falar algumas vezes sobre o JAMstack como a pilha garantida, porque ela garante um conjunto de ferramentas e tecnologias que precisamos para entregar um site. Mas, de qualquer forma, é uma maneira muito simplificada de entregar um site que, de certa forma, elimina a necessidade de que as coisas executem e executem a lógica no servidor no momento da solicitação.

Phil Hawksworth: Então, isso pode fazer muitas coisas. Isso pode, de certa forma, simplificar as implantações e, novamente, retornarei a este diagrama de tempos em tempos. Se pensarmos em como implantamos nosso código e nosso site, para cada implantação, desde a primeira, por todo o ciclo de vida de desenvolvimento, por toda a vida do site. Na pilha tradicional, podemos ter que alterar a lógica e o conteúdo de cada caixa nesse diagrama.

Phil Hawksworth: Considerando que, no JAMstack, quando estamos falando de implantação, estamos falando de levar as coisas para a CDN, levar as coisas para o servidor estático, e é isso que a implantação implica. A compilação, o tipo de lógica que executa a compilação — que pode ser executada em qualquer lugar. Isso não precisa ser executado no mesmo ambiente que hospeda o servidor web. Na verdade, não! Ele inicia a chave para o JAMstack. Colocamos a separação no que acontece no momento da solicitação, atendendo a esses ativos estáticos, versus o que acontece no momento da compilação, que pode ser sua lógica que você executa para compilar e depois para a implantação.

Phil Hawksworth: Então, esse tipo de dissociação é fundamental, e voltarei a isso mais tarde. Somos muito bons em servir arquivos estáticos, e levar coisas para uma CDN ou para o sistema de arquivos (o servidor de arquivos) é um lugar que vimos um grande avanço nos últimos anos. Existem muitas ferramentas e processos, agora, que podem nos ajudar a fazer isso muito bem. Apenas para citar alguns serviços que podem atender bem aos ativos estáticos e fornecer fluxos de trabalho para levar sua compilação a esse ambiente, eles são os suspeitos usuais de que você pode imaginar os grandes provedores de infraestrutura de nuvens, como Azure, AWS e Google Cloud.

Phil Hawksworth: Mas então, há outros. Então, o superior à direita é um serviço chamado Surge, que existe há alguns anos. Ele permite que você execute um comando em seu ambiente de compilação e implante seus ativos em seu ambiente de hospedagem. Netlify, o próximo abaixo, é onde eu trabalho e fazemos praticamente a mesma coisa, mas também temos automação diferente. Eu poderia entrar nisso outra hora. E o de baixo, outro site de ambiente de hospedagem estático, chamado Now.

Phil Hawksworth: Então, há várias opções diferentes para fazer isso, e todos esses espaços fornecem ferramentas diferentes para chegar ao CDN o mais rápido possível. Implantando seus sites da maneira mais perfeita possível. E todos eles têm algo em comum onde eles estão desenvolvendo o princípio de executar algo localmente. Costumo pensar em um gerador de site estático como algo que podemos executar em uma compilação que, quando executamos, leva coisas como conteúdo e modelos e talvez dados de diferentes serviços e produz algo que pode ser servido estaticamente.

Phil Hawksworth: Podemos visualizar isso localmente em nosso servidor estático. Algo que é meio simples de fazer em qualquer ambiente de desenvolvimento local e, em seguida, o processo de implantação é levar isso para o ambiente de hospedagem e, idealmente, para uma CDN para obter, mais ou menos, escala. Então, com esse tipo de base estabelecida, quero abordar um equívoco comum quando se trata de sites JAMstack. E não fiz nenhum favor a mim mesmo ao abrir isso descrevendo os sites JAMstack como JavaScript, APIs e Markup. Porque o equívoco comum é que todo site JAMstack tem que ser JavaScript e APIs, e Markup, mas esse tipo de coisa que negligenciamos é que não precisamos usar todos os três - cada um deles é meio que , opcional. Podemos usar tanto ou tão pouco quanto quisermos. Da mesma forma que um site de pilha LAMP não precisaria necessariamente atingir um banco de dados. Agora, eu construí coisas no passado que são servidas por um servidor apache, em uma máquina Linux, e estou usando PHP, mas não estou acessando um banco de dados e não começaria a renomear uma pilha necessariamente para isso.

Phil Hawksworth: Então, se pensarmos no que é um site JAMstack, pode ser um monte de coisas diferentes. Pode ser algo construído com um gerador de site estático, como Jekyll, extraindo conteúdo de arquivos YAML para criar um site que não tenha JavaScript, não acesse APIs e o servimos em algo, como GitHub Pages. Ou seria um site JAMstack. Ou talvez estejamos usando um gerador de site estático, como Gatsby, que é, em vez de um ambiente Ruby para Jekyll, agora este é um gerador de site estático JavaScript construído no ecossistema React.

Phil Hawksworth: Isso pode estar puxando conteúdo novamente e está organizando arquivos Markdown. Pode ser enriquecedor com chamadas para APIs, APIs do GraphQL. Pode estar fazendo coisas no navegador, como fazer hidratação JavaScript de preencher templates ali mesmo no navegador. E pode ser servido no Amazon S3. Isso é um site JAMStack? Sim, absolutamente!

Phil Hawksworth: Passando para um gerador de site estático diferente, Hugo, que é construído com Go! Novamente, podemos estar organizando conteúdo em arquivos Markdown, adicionando interações no navegador usando JavaScript. Talvez não chamando nenhuma API externa e talvez hospedando isso no Google Cloud. É JAMstack? Absolutamente! Você vê, eu estou construindo um tema aqui. Usando algo como Nuxt, outro gerador de site estático, agora integrado ao ecossistema View. Talvez isso esteja puxando conteúdo de diferentes arquivos adjacentes? Novamente, podemos estar usando interações JavaScript no navegador, talvez chamando APIs para fazer coisas como comércio eletrônico, servindo a outro site estático. Outra infraestrutura de hospedagem como o Netlify, é um JAMstack? Sim, ele é!

Phil Hawksworth: Mas podemos até ir, você sabe, para este lado da escala também. E pense em um aplicativo da web feito à mão e progressivo que construímos artesanalmente, enrolado à mão, JavaScript que construímos nós mesmos. Estamos empacotando tudo com o webpack. Talvez estejamos usando tokens da Web JavaScript e chamando APIs para fazer autenticação, interagindo com diferentes APIs de navegador, hospedando-o no Azure. Sim, isso também é JAMstack!

Phil Hawksworth: E, você sabe, todas essas coisas, e muitas outras, podem ser consideradas JAMstack, porque todas compartilham um atributo em comum e nenhuma delas é atendida com um servidor de origem. Nenhum deles precisa atingir um servidor que execute a lógica no momento da solicitação. Eles estão sendo servidos como ativos estáticos e, posteriormente, enriquecidos com JavaScript e chamadas para APIs.

Phil Hawksworth: Então, novamente, eu só quero reiterar que um JAMstack significa que ele pode ser servido diretamente do CDN. Então, eu quero apenas chamar a atenção para alguns dos impactos e implicações disso, porque por que queremos fazer isso? Bem, a primeira noção é sobre segurança, e temos uma área de superfície bastante reduzida para ataque aqui. Se pensarmos (voltando a este diagrama antigo novamente), os lugares onde podemos ter que lidar com um ataque, temos que proteger coisas como o balanceador de carga, os servidores da web, os servidores de banco de dados. Todas essas coisas, temos que garantir que não sejam penetradas por nenhum tipo de ataque e, de fato, pela CDN.

Phil Hawksworth: Se quanto mais peças pudermos tirar desse quebra-cabeça, menos lugares poderão ser atacados e menos lugares teremos que proteger. Ter poucas partes móveis para atacar é realmente muito valioso. Na Netlify, operamos nossas próprias CDNs, então temos o luxo de poder monitorar o tráfego que chega, e mesmo que todos os sites hospedados na Netlify, todos os sites JAMstack que você possa imaginar, nenhum deles têm uma página de administração do WordPress neles porque é completamente dissociada. Não há administrador do WordPress, mas vemos um enorme volume de tráfego, sondando coisas como WP Admin, procurando maneiras de entrar, procurando vetores de ataque.

Phil Hawksworth: Eu realmente amo algumas das coisas que Kent C. Dodds fez. Não sei se você conhece a comunidade React, provavelmente já encontrou Kent C. Dodds no passado. Ele não usa WordPress, mas ainda encaminha essa URL, a WPAdmin. Acho que ele costumava encaminhá-lo para um vídeo de Rick Roll no YouTube. Ele certamente está trollando pessoas que foram sondar por isso. Mas, o ponto é, ao desacoplar as coisas dessa maneira e, meio que movendo as coisas que acontecem, construir o tempo do que acontece no tempo da solicitação, podemos reduzir drasticamente nossa exposição. Não temos peças móveis no momento do pedido. As partes móveis são completamente desacopladas no momento da construção. Potencialmente, completamente, bem, necessariamente em uma infraestrutura completamente diferente.

Phil Hawksworth: Isso, claro, também tem impacto no desempenho. Voltando ao nosso velho amigo aqui, os lugares em que podemos tentar melhorar o desempenho na pilha aqui, quando há lógica que precisa ser executada nesses lugares diferentes. A maneira como isso geralmente acontece nas pilhas tradicionais é que elas começam a adicionar camadas, adicionar camadas estáticas, para melhorar o desempenho. Então, em outras palavras, tente encontrar maneiras de começarmos a nos comportar como se fosse estático. Não precisa executar essa lógica em cada nível da pilha para acelerar as coisas. Então, estamos começando a introduzir coisas como cache em toda a infraestrutura e lugares óbvios que podemos encontrar para fazer isso no servidor web, em vez de executar essa lógica, queremos servir algo imediatamente sem executar essa lógica.

Phil Hawksworth: Então, é como um passo em direção a ser pseudo-estático. Da mesma forma, em servidores de banco de dados, queremos adicionar camadas de cache às consultas cache-com. Mesmo no saldo baixo, todo o CDN, você pode pensar como um cache. Mas na pilha tradicional, precisamos descobrir como gerenciar esse cache, porque nem tudo será armazenado em cache. Então, há alguma lógica sobre. O que precisa ser preenchido dinamicamente versus o que pode ser armazenado em cache. E no modelo JAMstack, tudo é armazenado em cache. Tudo é armazenado em cache a partir do momento em que a implantação é concluída, para que possamos pensar nisso de forma completamente diferente.

Phil Hawksworth: Isso, então, começa a, de certa forma, sugerir escala também. E por escala, estou falando, como lidamos com grandes cargas de tráfego? As pilhas tradicionais começarão a adicionar infraestrutura para escalar. Então, sim, para o cache. Estamos começando a colocar em prática nossa pilha tradicional. Isso vai ajudar – até certo ponto. O que normalmente acontece é que, para lidar com grandes cargas de tráfego, começaremos a expandir a infraestrutura e começar a adicionar mais servidores, mais peças para lidar com essas solicitações, custando essas coisas e estimando que a carga é uma grande sobrecarga e pode ser uma dor de cabeça para quem faz arquitetura técnica. Certamente foi para mim, e é por isso que eu estava começando a me inclinar muito mais para a abordagem JAMstack, onde eu só sei que tudo é servido a partir do CDN, que é projetado por padrão para lidar com escala, para lidar com o desempenho imediatamente .

Phil Hawksworth: Então, também quero dar um aceno à experiência do desenvolvedor e ao impacto que isso pode ter lá. Agora, a experiência do desenvolvedor nunca deve ser vista como algo que supera a experiência do usuário, mas acredito que uma boa experiência do desenvolvedor pode reduzir o atrito, pode permitir que os desenvolvedores façam um trabalho muito melhor na construção de ótimas experiências do usuário!

Phil Hawksworth: Então, quando pensamos sobre onde vive a experiência do desenvolvedor e onde estão as áreas de preocupação para um desenvolvedor aqui: bem, em uma pilha tradicional, podemos precisar pensar em como obter o código para todos esses diferentes partes da infra-estrutura, e como todos eles funcionam juntos. No mundo do JAMstack, na verdade, estamos falando dessa caixa aqui embaixo. Você sabe, como executamos a compilação e eles, como automatizamos uma implantação para obter algo servido em primeiro lugar? E o bom é que, no modelo JAMstack, o que você faz nessa compilação depende completamente de você.

Phil Hawksworth: Esse é um espaço de problemas muito bem definido, porque, em última análise, você está tentando construir algo que pode servir diretamente de uma CDN. Você quer pré-renderizar algo, usando as ferramentas que quiser: seja um gerador de site estático construído em Ruby ou Python ou JavaScript ou Go ou PHP, você tem a liberdade de fazer essa escolha. E assim, isso pode criar um ambiente muito mais agradável para você trabalhar. E também, cria uma oportunidade de ter confiança real do desenvolvedor porque um atributo real dos sites JAMstack é que eles podem ser servidos muito mais facilmente como implementação imutável e atômica.

Phil Hawksworth: E eu quero, meio que, pular fora dos slides apenas por um momento, para descrever o que isso significa, porque uma implantação imutável e uma implantação atômica podem… (isso pode soar um pouco como marketing), mas o que vou fazer é entrar no meu navegador. Agora... na verdade, vou voltar por um segundo. Deixe-me... apenas faça isso.

Phil Hawksworth: Aqui estamos. Isso será mais fácil. Pulando direto para a página. Agora, Scott, você vai me dizer, Scott, se você não consegue ver meu navegador, eu espero. Agora, supondo que todos possam ver meu navegador.

Scott: Tudo parece bom.

Phil Hawksworth: Excelente! Muito obrigado!

Phil Hawksworth: Então, o que estou fazendo aqui é usar o Netlify como exemplo, como exemplo do serviço. Mas, esse é um atributo comum a sites que podem ser hospedados, estaticamente. Então, quando falamos sobre uma implantação imutável, o que queremos dizer é que, em vez de cada implantação de código ter que tocar muitas partes diferentes da infraestrutura e alterar muitas coisas, aqui não estamos alterando o estado do site em o servidor. Estamos criando uma instância totalmente nova do site para cada implantação que aconteceu. E podemos fazer isso porque o site é uma coleção de ativos estáticos.

Phil Hawksworth: Aqui, estou analisando a implantação que aconteceu no meu próprio site. Eu vou te dar um mimo. Aí está você, é o que parece. É apenas um blog, não parece nada particularmente notável ou emocionante. É um blog gerado estaticamente, mas o que tenho aqui é cada implantação que já aconteceu, vive perpetuamente, porque é uma coleção de ativos estáticos que são servidos a partir de uma CDN. Agora, eu poderia voltar até onde minha história pode me levar e ir e olhar para o site, como era... quando foi isso? Isso foi em agosto de 2016. E por ser um conjunto de ativos estáticos, podemos hospedar isso em seu próprio URL que vive perpetuamente e, se eu quisesse, poderia decidir entrar e publicar isso desdobramento, desenvolvimento.

Phil Hawksworth: Então, agora, qualquer pessoa que esteja olhando meu site, se eu voltar ao meu site aqui, se eu atualizar essa página, agora isso está sendo servido diretamente da CDN com os ativos que estavam lá antes. Agora posso navegar novamente. Aqui você pode ver. Olha, eu estava falando sobre isso, eu estava usando esses termos terríveis como renderização isomórfica e falando sobre o JAMstack em 2016. Então, agora é isso que está sendo veiculado ao vivo no meu site. Novamente, porque existem implantações mútuas que vivem para sempre. Eu vou colocar minha própria paz de espírito, eu vou - esta é a primeira página? Sim. Vou voltar para minha última implantação. Vou ter que fechar de novo, e me levar de volta ao mundo real. Deixe-me apenas ter certeza de que está tudo bem.

Phil Hawksworth: Ok! Excelente! Então, agora, isso está de volta a servir minha versão anterior ou minha versão mais recente do site. Eu vou voltar ao keynote. Então, isso é possível porque as coisas são imutáveis ​​e atômicas. A parte atômica disso significa, novamente, que a implantação está completamente contida. Portanto, você nunca chega ao ponto em que alguns dos ativos estão disponíveis no servidor da Web, mas alguns deles não. Somente quando tudo está lá em contexto e tudo está lá, completo, alternamos a veiculação do site para a nova versão. Novamente, esse é o tipo de coisa que você pode fazer com muito mais facilidade se estiver construindo coisas como um site JAMstack que serve diretamente da CDN como um monte de ativos.

Phil Hawksworth: Percebi que meu cronômetro foi reiniciado, depois de ir e voltar da palestra, então acho que tenho cerca de seis ou sete minutos restantes. Diga-me, Scott, se...

Scott: Então, sim, ainda estamos bem por cerca de dez minutos.

Phil Hawksworth: Dez minutos? Ok, maravilhoso!

Scott: Não há pressa.

Phil Hawksworth: Obrigado, isso deve ser bom!

Phil Hawksworth: Então, apenas mudando de assunto um pouco e falando sobre APIs e serviços (já que as APIs fazem parte do JAMstack), o tipo de serviço que podemos usar é principalmente o JAMstack. Você sabe, podemos estar usando serviços que construímos internamente, ou podemos estar usando serviços comprados. Existem muitos provedores diferentes que podem fazer coisas por nós, e isso é porque essa é a experiência deles. Por meio de APIs, podemos estar extraindo conteúdo de sistemas de gerenciamento de conteúdo como um serviço, e há vários provedores diferentes para isso, que se especializam em oferecer uma ótima experiência de gerenciamento de conteúdo e, em seguida, expor o conteúdo por meio de API, então você costumava ser capaz de atraí-los.

Phil Hawksworth: Da mesma forma, existem diferentes maneiras de servir ativos. Pessoas como Cloudary são ótimas nisso, por fazer otimização de imagem, servindo ativos diretamente para seus sites, novamente, por meio de APIs. Ou e-commerce? Você sabe, existem lugares como Stripe ou Snipcart que podem nos fornecer API, para que não tenhamos que construir esses serviços nós mesmos e entrar em questões muito complexas que surgem ao tentar construir um mecanismo de comércio eletrônico. Da mesma forma, identidade, de pessoas como Auth0 que estão usando Oauth. Existem muitos serviços disponíveis e podemos consumir essas coisas por meio de APIs, seja no navegador ou em tempo de compilação, ou às vezes, uma combinação de ambos.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. Hello everyone. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. Certo? It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth: Eu realmente gosto, porque o termo JAMstack pode ser realmente enganoso, porque está tentando cobrir tantas coisas diferentes e o ponto que eu estava tentando, provavelmente martelei muitas vezes naquele slide, é que pode ser todos os tipos das coisas. É tão amplo, mas a chave é pré-renderizar e hospedar o núcleo dos sites estaticamente. É muito fácil para nós entrar em guerras religiosas sobre onde precisa ser um site React. Tem que ser um aplicativo React, para ser um site JAMstack, ou é um aplicativo React, então não pode ser JAMstack. Mas, na verdade, o cerne disso é, se você usa JavaScript ou não, se você está chamando APIs ou não, se você pré-renderiza e coloca as coisas em um host estático que pode ter muito desempenho, esse é o núcleo do JAMstack.

Vitaly: Sim, com certeza.

Phil Hawksworth: Temos muita sorte que os navegadores estão ficando muito mais capazes, e as APIs que estão dentro dos próprios navegadores podem nos permitir fazer muito mais também. Então, isso meio que abre as portas ainda mais, mas não significa que tudo o que construímos como um site JAMstack tem que fazer uso de tudo. Dependendo do que estamos tentando entregar, é assim que devemos começar a escolher as ferramentas com as quais estamos jogando para implantar essas coisas.

Vital: Com certeza. Temos Doran aqui. Doran, acho que sei, Doran. Tenho a sensação de que conheço Doran. Ele está perguntando: “Você espera que o serverless gravite em direção à integração perfeita com o JAMstack a partir de [inaudível 00:44:36]? O que é referido como o A no JAM.

Phil Hawksworth: Essa é uma ótima pergunta, porque eu acho que as funções sem servidor são - elas funcionam tão bem com sites JAMstack, porque de muitas maneiras, na verdade, acho que alguém uma vez me perguntou se os sites JAMstack são sem servidor, e então eu me contorci sobre essa pergunta, porque serverless é um termo tão carregado. Mas, de muitas maneiras, é ótimo porque eu estava falando, várias vezes, sobre não haver servidor de origem. Não há infraestrutura de servidor para você gerenciar. Na verdade, uma vez escrevi um post no blog chamado “Web Serverless”, porque o mundo precisa de outro termo da moda, não é?

Phil Hawksworth: E realmente, o objetivo disso era, sim, estamos construindo coisas sem servidores. Não queremos ter que gerenciar esses servidores, e funções sem servidor, ou funções como serviço, se encaixam perfeitamente nisso. Portanto, nos casos em que você precisa de uma API para a qual deseja fazer uma solicitação, onde realmente não é sensato fazer essa solicitação diretamente do navegador. Assim, por exemplo, se você tiver segredos ou chaves nessa solicitação, talvez não queira que essas solicitações – essas informações – sejam expostas no cliente. Mas certamente podemos fazer proxy dessas coisas e, normalmente, tradicionalmente, o que precisamos fazer é ativar um servidor, ter alguma infraestrutura que efetivamente estava fazendo pouco mais do que lidar com solicitações, adicionar autenticação de segurança a ele e transmitir essas solicitações , fazendo proxy deles de volta.

Phil Hawksworth: As funções sem servidor são perfeitas para isso. Eles são absolutamente ideais para isso. Então, às vezes penso em funções sem servidor, ou funções de um serviço, quase como uma escotilha de fuga, onde você só precisa de alguma lógica em um servidor, mas não quer ter que criar uma infraestrutura inteira. E você pode fazer mais e mais com isso, e ajustar os pipelines de desenvolvimento para fluxos de trabalho de desenvolvimento, para funções como um serviço que está amadurecendo. Está ficando mais acessível para os desenvolvedores JavaScript poderem construir essas coisas. Então, sim, eu realmente acho que essas duas coisas combinam muito bem.

Vitaly: Tudo bem, essa é uma resposta muito abrangente. Na verdade, participei de uma palestra recentemente, onde um engenheiro de front-end da Amazon estava falando sobre as funções serverless e Lamda que eles estão usando - eu estava quase sumindo. Ele estava sempre falando sobre Docker, Kubernetes e todas essas coisas, Devox World, eu estava sentado lá, pensando: “Como ele foi parar lá. Não entendo o que está acontecendo!” Eu não tinha ideia do que está acontecendo.

Phil Hawksworth: Exatamente, mas a questão é que costumava ser o… eu era… eu aceitei que não entendia nada desse mundo, mas não tinha nenhum desejo, já que era para uma disciplina totalmente diferente . E essa disciplina ainda é muito importante. Você sabe, pessoas que estão projetando infraestrutura – isso ainda é muito importante. Mas, parece, agora, que estou tentado. Como alguém com experiência em desenvolvimento front-end, como desenvolvedor JavaScript, estou muito mais tentado a querer jogar nesse mundo, porque as ferramentas estão chegando mais perto de mim.

Phil Hawksworth: É muito mais provável que eu possa usar algumas dessas coisas, e entregar as coisas com segurança, em vez de apenas como um experimento meu, que é onde eu costumava pintar. Então, parece que estamos nos tornando mais poderosos como desenvolvedores da web, o que é emocionante para mim.

Vitaly: Tipo Power Rangers, hein?

Vitaly: Uma coisa que eu quero perguntar a você, no entanto, e isso é algo que já discutimos, talvez, uma semana atrás, mas eu ainda queria trazer isso à tona, porque a única coisa que você mencionou na sessão foi a noção de ter uma instância autônoma de cada implantação, o que é muito legal. A questão, porém, é se você tem uma tarefa grande, com dezenas de milhares de páginas, você realmente não quer reimplantar tudo, todas as vezes. Então, essencialmente, se você tiver, tipo, se estiver usando principalmente o lado estático das coisas. Então, tivemos essa ideia por um tempo e eu sei que isso é realmente algo que você mencionou da última vez. A ideia de implantações atômicas.

Vitaly: Onde você realmente, literalmente, recebeu algum tipo de div entre duas versões diferentes de instantâneos da configuração. Então, se você diz, mude o cabeçalho em todos os lugares, então, é claro, cada página precisa ser reimplantada. Mas se você alterar, talvez, um componente, como digamos, carrossel, que talvez afete apenas 1.000 páginas, faria sentido reimplantar 15.000 páginas. Mas apenas este 1000. Então, podemos chegar lá? É uma ideia mágica que está por aí, ou é algo bastante tangível, neste momento?

Phil Hawksworth: Acho que esse é, provavelmente, o Santo Graal para geradores de sites estáticos e esse tipo de modelo porque, certamente, você identificou provavelmente o maior obstáculo a ser superado. Ou o maior teto em que você esbarra. E são sites que têm muitos, dezenas de milhares ou centenas de milhares, ou milhões de URLs – a noção de que a construção pode se tornar muito longa. Ser capaz de detectar quais URLs serão alterados, com base em uma alteração de código, é um desafio. Não é intransponível, mas é um grande desafio. Entender o que é o gráfico de dependência em todo o site e, em seguida, implantá-lo de forma inteligente — isso é muito difícil de fazer.

Phil Hawksworth: Porque, como você mencionou, uma mudança de componente pode ter implicações de longo alcance, mas você – é difícil, sempre, saber como isso vai funcionar. Portanto, existem vários geradores de sites estáticos, os projetos que estão colocando algum peso por trás desse desafio e tentando descobrir como eles fazem a regeneração parcial e as compilações incrementais. Estou muito animado com a perspectiva de que isso possa ser resolvido dia, mas no momento, é definitivamente um grande desafio. Você pode começar a fazer coisas como tentar compartilhar seu site de forma lógica e pensar novamente em algo semelhante ao problema da migração. Bem, esta seção que eu conheço é independente em termos de alguns dos ativos que ela usa ou do tipo de conteúdo que mora lá, para que eu possa implantá-los individualmente.

Phil Hawksworth: Mas isso não é o ideal para mim. Esse não é realmente o cenário perfeito. Uma das abordagens que explorei um pouco, apenas como prova de conceito, é pensar em como você faz as coisas, como fazer uso inteligente de 404s. Então, por exemplo, um grande caso de uso para sinais muito grandes, talvez sites de notícias, quando eles precisam de um URL quando uma notícia de última hora acontece, eles precisam ser os primeiros a implantá-lo lá. Eles precisam obter um URL lá em cima. Coisas como a BBC News, você verá que a notícia chegará ao site e, em seguida, ao longo do tempo, eles adicionarão a ela, de forma incremental, mas chegar primeiro é fundamental. Então, ter uma compilação que leva 10 minutos, 20 minutos, seja lá o que for, pode ser um problema.

Phil Hawksworth: Mas, se o conteúdo for abstraído e talvez usado para ser chamado de uma API. Mencionei sistemas de gerenciamento de conteúdo que são abstratos, como Contentful ou Sanity, ou um monte deles. Qualquer coisa que tenha uma API de conteúdo muda para essa estrutura de conteúdo que acionará uma compilação e passaremos pela execução, mas a outra coisa que pode acontecer é que, bem, se você publicar sua URL para isso e depois divulgar essa URL , mesmo que a compilação não tenha sido executada, se alguém acessar esse URL, se a primeira parada em seu 404 for em vez de dizer "Nós não temos isso", é na verdade acessar essa API diretamente, então, você pode dizer , "Bem, a compilação ainda não foi concluída para preencher isso, mas posso fazer isso no cliente." Eu posso ir diretamente para a API, pegar isso, preenchê-lo no cliente.

Vitaly: Hmm, interessante.

Phil Hawksworth: Então, mesmo enquanto a construção ainda está acontecendo, você pode começar a preencher essas coisas. E então, uma vez que a compilação esteja concluída, é claro que não atingiria um 404. Você atingiria aquela página em execução estaticamente. Então, existem técnicas e estratégias para lidar com isso, mas ainda assim, é uma resposta muito longa e desconexa, me desculpe, mas minha conclusão é, sim, isso é um desafio. Dedos cruzados, vamos obter melhores estratégias.

Vitaly: Sim, isso é ótimo. Então, eu estou pensando, então, neste momento, nós realmente não estamos pensando, não apenas qual o desempenho em termos de entrega de conteúdo, mas aqueles em desempenho em termos de velocidade de construção. Como a implantação do edifício. Então, isso também é algo que estamos investigando, há um bom tempo também.

Vitaly: Mais uma coisa que eu queria te perguntar. Então, isso é interessante, como essa técnica que você mencionou. Como você aprende sobre isso? Isso é apenas algo que as pessoas tendem a publicar em seus próprios blogs ou, é algum meio ou há um repositório central onde você pode obter algum tipo de estúdio de caso, de como o JAMstack - como as empresas se moveram durante o descarregamento ou não conseguiram se mudar para JAMstack.

Phil Hawksworth: Então, está amadurecendo um pouco esse cenário, no momento. Quero dizer, alguns desses exemplos, eu acho, estou em uma posição muito afortunada, trabalho em algum lugar em que estou desempenhando um papel que estou jogando com os brinquedos, criando maneiras interessantes de usá-lo e começar a experimentar com eles. Então, essas provas de conceitos são, mais ou menos, coisas que eu experimento e tento lidar com esses desafios. Mas o, eu meio que mencionei anteriormente, um estudo de caso que foi mostrado na conferência JAMstack em Nova York e, certamente, eventos como esse, estamos começando a ver as melhores práticas ou práticas do setor e abordagens do setor sendo discutidas nesses tipos de eventos. E, certamente, quero ver mais e trabalhar em mais estudos de caso para chegar a lugares como Smashing Magazines, para que possamos compartilhar essas informações com muito mais facilidade.

Phil Hawksworth: Eu acho que grandes empresas e o espaço corporativo estão adotando gradualmente o JAMstack, em diferentes lugares, de maneiras diferentes, mas o mundo ainda está inclinado a chegar lá, então acho que cada vez que uma empresa o adota e compartilha seus experiência, todos aprendemos com isso. Mas eu realmente quero ver mais e mais desses estudos de caso serem publicados, para que possamos aprender particularmente sobre como esses tipos de desafios são superados.

Vitaly: Tudo bem, então, talvez apenas a última pergunta minha, porque eu sempre gosto de ler perguntas. Então, na terra do JAMstack, se você pudesse mudar alguma coisa, talvez houvesse algo que você adoraria ver, além das implantações. Qualquer outra coisa que estaria realmente fazendo você muito feliz? Isso faria o seu dia? O que seria aquilo? O que está na sua lista de desejos para o JAMstack?

Phil Hawksworth: Que pergunta. Quero dizer, se não tivéssemos falado sobre compilações incrementais, isso seria...

Vital: Nós fizemos. Isso é tarde demais, agora. Este cartão já foi passado. Precisamos de algo mais.

Phil Hawksworth: Então—

Vitaly: O que quero dizer, como em uma plataforma, se você olhar para a plataforma traseira, há tantas coisas interessantes acontecendo. Temos Houdini, temos componentes da web chegando e tudo mais, já que você pode estar mudando todo o cenário de todos os componentes certos. Por outro lado, temos todo esse mundo mágico e chique com SS NGS e, claro, obviamente, também temos aplicativos de página única e tudo mais. Com o que você está mais animado?

Phil Hawksworth: Vou ser obtuso aqui, porque há tanta coisa acontecendo, é emocionante, e há tantos recursos novos que você pode usar no navegador. O que realmente me deixa empolgado são as pessoas mostrando contenção (risos) e, como eu disse, resposta maçante, mas adoro ver grandes execuções que são feitas com contenção, de maneira pensativa – sobre o público mais amplo. É muito divertido e gratificante construir com a nova biblioteca JavaScript mais brilhante ou a nova API do navegador que faz, não sei, recursos de scratch e sniff no navegador, dos quais precisamos desesperadamente, a qualquer momento.

Phil Hawksworth: Mas eu realmente gosto de ver coisas que eu sei que vão funcionar em muitos, muitos lugares. Eles serão realmente eficientes, serão simpáticos aos navegadores existentes - não apenas nas mesas de CEOs e CTOs que compraram os brinquedos elegantes, mas também pessoas que têm dispositivos muito menos potentes, ou eles tenho condições de rede desafiadoras e esse tipo de coisa. Eu gosto de ver experiências interessantes e ricas, entregues de uma forma que simpatiza com a plataforma e compassiva com o público mais amplo, porque acho que a web chega muito mais longe do que nós, os desenvolvedores, que construímos coisas para ela . E fico animado ao ver coisas interessantes sendo feitas, de maneiras que atingem mais pessoas.

Phil Hawksworth: Essa provavelmente não é a resposta que você estava necessariamente—

Vitaly: Ah, esse é um final legal. Muito obrigado. Não, isso é perfeito, isso realmente é. Tudo bem, eu senti que tudo correu bem! Muito obrigado por estar conosco! Estou entregando para Scott!

Phil Hawksworth: Ótimo!

Vitaly: Estou aqui apenas para jogar perguntas e respostas. Então, muito obrigado, Phil! Ainda estou aqui, mas Scott, o palco é seu, agora! Talvez você possa compartilhar conosco o que está por vir na Smashing TV?

Scott: Eu vou, mas primeiro, Phil, mal posso esperar para ver como a implementação da API de raspar e cheirar funcionará. Parece muito interessante. E, Vitaly, o JAMstackify já está feito.

Vitaly: (abatido) Levado?! Podemos comprá-lo?

Scott: Não, existe!

Vitaly: Bem, isso é tarde demais. Eu estou sempre atrasada.

Phil Hawksworth: Isso é excitante à sua maneira.

Vitaly: Essa é a história da minha vida. Eu estou sempre atrasada.

Scott: Membros chegando a seguir, creio eu, quinta-feira, dia 13, temos o meu velho, Zach Leatherman, falando sobre o que ele fala melhor, que são as fontes. Então, ele está falando sobre os Cinco Y's das Implementações de Fontes. E também estou muito interessado no que temos para o dia 19, que é a edição de vídeo, com JavaScript e CSS, com a Eva Faria. Portanto, fique atento a ambos.

Scott: Então, de novo, na próxima quinta-feira, com Zach Leatherman, e depois no dia 19, com Eva, que falará sobre edição de vídeo em JavaScript e CSS. Então, nessa nota, Phil, eu não posso mais vê-lo, você ainda está aí?

Phil Hawksworth: Estou aqui!

Scott: Nesse sentido, muito obrigado a todos! Além disso, alguém está perto da área de Toronto? Ou alguém que já quis visitar Toronto? Temos uma conferência no final de junho e ainda restam alguns ingressos. Então, talvez vejamos alguns de vocês lá.

Vitaly: Muito obrigado a todos!

Vitaly: Ah, a propósito, só mais uma coisa! Talvez Phil tenha mencionado isso, mas também temos a JAMstack Conference em Londres, em julho. Então, isso é algo a se observar também. Mas estou me despedindo e vou pegar minha salada! Não tenho certeza do que você—

Scott: Ok, adeus, pessoal!

Vitaly: Tudo bem, tchau, pessoal.

Isso é um envoltório!

Agradecemos gentilmente aos membros do Smashing do fundo de nossos corações por seu apoio contínuo e gentil - e mal podemos esperar para hospedar mais webinars no futuro.

Além disso, Phil será o MC na SmashingConf Toronto 2019 na próxima semana e na JAMstack_conf — adoraríamos ver você lá também!

Por favor, deixe-nos saber se você acha esta série de entrevistas útil, e quem você gostaria que entrevistássemos, ou quais tópicos você gostaria que abordássemos e nós vamos direto ao assunto.