Olá Habitantes! Crie aplicativos da Web dinâmicos usando Express, um componente-chave da pilha de desenvolvimento Node / JavaScript. Ethan Brown descreve como trabalhar com o Express 5 construindo um aplicativo completo. O livro cobre todos os estágios e componentes - da renderização do servidor ao desenvolvimento de API para trabalhar com aplicativos de página única (SPA). O Express é o meio termo entre uma estrutura bem estabelecida e nenhuma estrutura, portanto, ele deixa você com alguma liberdade em suas escolhas arquitetônicas. Este livro fornecerá as melhores soluções para desenvolvedores front-end e back-end que usam o Express. Aprenda a olhar para o desenvolvimento da web de um novo ângulo! - Crie um sistema de modelos para exibir dados dinâmicos. Saiba mais sobre objetos de solicitação e resposta, middleware e roteamento de URL.- Criar uma simulação do ambiente de produção e testar nele. - Aprenda o armazenamento de longo prazo de informações em bancos de dados de documentos usando MongoDB e em bancos de dados relacionais usando PostgreSQL. - Compartilhe seus recursos com outros programas graças à API. - Construir aplicativos seguros usando autenticação, autorização e HTTPS. - Integre com redes sociais, habilite geolocalização e muito mais. - Implemente um plano para lançar e manter seu aplicativo. - Domine habilidades críticas de depuração.- Construir aplicativos seguros usando autenticação, autorização e HTTPS. - Integre com redes sociais, habilite geolocalização e muito mais. - Implemente um plano para lançar e manter seu aplicativo. - Domine habilidades críticas de depuração.- Construir aplicativos seguros usando autenticação, autorização e HTTPS. - Integre com redes sociais, habilite geolocalização e muito mais. - Implemente um plano para lançar e manter seu aplicativo. - Domine habilidades críticas de depuração.
Redes de distribuição de conteúdo
Quando você coloca seu site em produção, os ativos estáticos devem ser carregados em algum lugar da Internet. Você pode estar acostumado a colocá-los no mesmo servidor onde todo o seu HTML dinâmico é gerado. Nosso exemplo até agora também usou esta abordagem: o servidor Node / Express, iniciado pelo comando node meadowlark.js, atende a todos os tipos de recursos HTML e estáticos. No entanto, se você deseja otimizar o desempenho do seu site (ou mantê-lo no futuro), precisará da capacidade de hospedar recursos estáticos em uma rede de distribuição de conteúdo (CDN). CDN é um servidor otimizado para fornecer recursos estáticos. Ele usa cabeçalhos especiais (sobre os quais aprenderemos mais em breve) que permitem o cache do navegador.
Além disso, um CDN pode incluir otimização geográfica (geralmente chamada de cache de borda), o que significa que o conteúdo estático será entregue a partir do servidor mais próximo de seu cliente. Embora a Internet seja muito rápida (é claro, ela não funciona na velocidade da luz, mas perto dela), os dados serão entregues ainda mais rápido a uma distância de centenas de quilômetros do que milhares. A economia de tempo é insignificante em cada caso individual, mas quando multiplicada pelo número de usuários, solicitações e recursos, rapidamente se torna impressionante.
A maioria de seus recursos estáticos serão referenciados em visualizações HTML
<link> CSS-, <script> — JavaScript, <img> ,
É uma prática comum ter links estáticos em CSS, geralmente na propriedade background-image. Finalmente, os recursos estáticos às vezes são referenciados em JavaScript, por exemplo, o código JavaScript pode alterar ou inserir tags dinamicamente.
<img>
ou as propriedades da imagem de fundo.
Não se preocupe com o compartilhamento de recursos entre domínios (CORS) ao usar um CDN. Os recursos externos carregados em HTML não estão sujeitos às regras CORS: você só precisa habilitar o CORS para recursos carregados via Ajax (consulte o Capítulo 15).
Projetando para um CDN
Como você usa um CDN depende da arquitetura do seu site. A maioria das redes de entrega de conteúdo permite que você defina regras de roteamento para determinar para onde enviar solicitações de entrada. Embora você possa definir regras de roteamento bastante complexas, geralmente se resume a enviar solicitações de recursos estáticos para um local (geralmente fornecido por seu CDN) e solicitações de endpoint dinâmicas (páginas dinâmicas ou endpoints de API) para outro.
A escolha e a configuração de um CDN é um tópico vasto que não abrangerei aqui, mas darei algumas informações básicas para ajudá-lo a configurar o CDN de sua escolha.
A abordagem mais simples para estruturar seu aplicativo é tornar os recursos dinâmicos e estáticos facilmente distinguíveis. Isso manterá suas regras de roteamento de CDN o mais simples possível. Embora isso possa ser alcançado usando subdomínios (por exemplo, recursos dinâmicos são servidos de meadowlark.com e recursos estáticos de static.meadowlark.com), esta abordagem adiciona complexidade adicional e complica o desenvolvimento local. Uma maneira mais fácil é usar caminhos de solicitação: por exemplo, tudo que começa com / public / é um recurso estático e todo o resto é dinâmico. A abordagem pode ser diferente se você estiver gerando conteúdo com o Express ou usando o Express para fornecer uma API para um aplicativo de página única.
Site de renderização do lado do servidor
Se você usar o Express para renderizar HTML dinâmico (em outras palavras, tudo que começa com / static /) são recursos estáticos e todo o resto é dinâmico. Com essa abordagem, todos os seus URLs (gerados dinamicamente) serão como você deseja (a menos que eles comecem com / static /, é claro!), E todos os seus recursos estáticos serão prefixados com / static /:
<img src="/static/img/meadowlark-logo-1.png" alt="Meadowlark Logo">
<a href="/about">Meadowlark Travel</a>.
Até agora neste livro, usamos middleware estático, como se todos os recursos estáticos estivessem dispostos no diretório raiz. Assim, ao colocar o recurso estático foo.png na pasta pública, nos referimos a ele no caminho da URL /foo.png, e não em /static/foo.png. Claro, é possível criar um subdiretório estático dentro do diretório público existente e a URL para /public/static/foo.png será /static/foo.png, mas isso não é muito inteligente. Felizmente, o middleware estático nos permite evitar isso especificando um caminho diferente ao chamar app.use:
app.use('/static', express.static('public'))
Agora, no ambiente de desenvolvimento, podemos usar a mesma estrutura de URL da exploração. Se o conteúdo da pasta pública e do CDN estiverem sincronizados, você pode fazer referência a recursos estáticos em ambos os locais e alternar perfeitamente entre o desenvolvimento e a produção.
Ao configurar o roteamento para o CDN (você precisará consultar a documentação do CDN), o roteamento terá a seguinte aparência.
Aplicativos de página única Os aplicativos de página
única geralmente são o oposto de sites renderizados do lado do servidor: apenas a API será passada para o servidor (por exemplo, qualquer solicitação começando com / api), todo o resto é passado para armazenamento de arquivo estático.
No Capítulo 16, você viu que pode criar um assembly para operar seu aplicativo que incluirá todos os recursos estáticos carregados no CDN. Em seguida, você só precisa ter certeza de que sua configuração de roteamento de API está correta. Desta forma, você terá o seguinte roteamento.
Agora que aprendemos como estruturar um aplicativo para fazer a transição perfeita do desenvolvimento para a produção, vamos ver o que realmente acontece no cache e como ele otimiza o desempenho.
Armazenando recursos estáticos em cache
Esteja você usando Express ou CDN para servir recursos estáticos, vale a pena entender os cabeçalhos de solicitação HTTP que o navegador usa para determinar quando e como armazenar recursos estáticos em cache.
- Expira / Cache-Control. Esses dois cabeçalhos informam ao seu navegador a quantidade máxima de tempo que um recurso pode ser armazenado em cache. O navegador os leva a sério: se eles dizem para armazenar algo por um mês, ele simplesmente não fará o download novamente por um mês, desde que permaneça no cache. É importante entender que o navegador pode excluir uma imagem do cache antes da data de expiração por motivos que você não pode controlar. Por exemplo, o usuário pode limpar manualmente o cache ou o navegador pode excluir seu recurso para liberar espaço para os recursos que o usuário visita com mais frequência. Você só precisa de um desses cabeçalhos. Expires é mais amplamente suportado, por isso é preferível usá-lo. Se o recurso está no cache e ainda não expirou,o navegador não executará a solicitação GET, o que melhorará o desempenho, especialmente em dispositivos móveis.
- Última modificação / ETag. Fornece um tipo de controle de versão: se o navegador precisar verificar um recurso, ele verificará essas tags antes de carregar o conteúdo. A solicitação GET para o servidor ainda será executada, mas se os valores retornados nesses cabeçalhos demonstrarem ao navegador que o recurso não foi alterado, o navegador não prosseguirá com o download do arquivo. Como o nome sugere, Last-Modified permite definir a data em que um ativo foi modificado pela última vez. ETag permite que você use uma string arbitrária, geralmente uma string de versão ou um hash de conteúdo.
Ao emitir recursos estáticos, use o cabeçalho Expires e Last-Modified ou ETag. O middleware estático integrado do Express instala Cache-Control, mas não processa Last-Modified ou ETag. Portanto, é adequado para desenvolvimento, mas não para operação.
Se você optar por hospedar seus ativos estáticos em um CDN, como Amazon CloudFront, Microsoft Azure, Fastly, Cloudflare, Akamai ou StackPath, você receberá um bônus: a maioria desses detalhes será tratada para você. Você poderá fazer ajustes finos, embora as configurações padrão em qualquer um desses serviços também sejam adequadas.
Modificando o conteúdo estático
O armazenamento em cache melhora significativamente o desempenho do seu site, mas não sem consequências. Em particular, se qualquer um dos recursos estáticos mudar, os clientes podem não ver a mudança até que as versões em cache do navegador tenham expirado. O Google recomenda o armazenamento em cache por um mês, de preferência um ano. Imagine um usuário que visita seu site todos os dias através do mesmo navegador: ele pode ver suas atualizações somente depois de um ano!
Obviamente, essa não é uma situação desejável, mas você não pode dizer a seus usuários para limpar o cache. A solução para esse problema é desabilitar o impedimento de cache. Este truque lhe dará controle sobre quando o navegador deve recarregar o recurso. Este método simplesmente adiciona algumas informações de versão ao nome do arquivo. Quando você atualiza um recurso, o nome do recurso muda e o navegador sabe que deve baixá-lo. Normalmente, isso equivale a controlar as versões do recurso (main.2.css ou main.css? Version = 2) ou adicionar algum tipo de hash (main.e16b7e149dccfcc399e025e0c454bf77.css). Qualquer que seja o método usado, ao atualizar um recurso, seu nome muda e o navegador sabe como carregá-lo.
Você pode fazer o mesmo com recursos multimídia. Vamos pegar nosso logotipo (/static/img/meadowlark_logo.png). Se o colocarmos em um CDN para maximizar o desempenho, definindo o período de retenção para um ano e, em seguida, alterando o logotipo, os usuários podem não ver a mudança por um ano. No entanto, se renomearmos o logotipo para /static/img/meadowlark_logo-1.png e refletir essa mudança em HTML, o navegador terá que baixá-lo, pois parece ser um novo recurso.
Se você escolheu uma estrutura de aplicativo de página única, como criar-reagir-app ou similar, então, no estágio de construção, uma montagem de recursos prontos para uso será criada com hashes adicionados a eles.
Se você está começando do zero, provavelmente deseja dar uma olhada nos construtores (que é o que está por trás das estruturas de aplicativos de página única). JavaScript, CSS e alguns outros tipos de recursos estáticos serão agrupados no menor número possível de assemblies e o resultado será minimizado o máximo possível. A personalização da compilação é um tópico vasto, mas felizmente há uma boa documentação sobre ele. Abaixo estão os colecionadores mais populares disponíveis atualmente.
- Webpack (https://webpack.js.org/). Um dos primeiros colecionadores a alcançar um progresso real. Ele ainda tem muitos apoiadores. É muito complexo e há um preço a pagar por essa complexidade: a curva de aprendizado é íngreme. No entanto, este packer é bom para aprender o básico.
- Parcel (https://parceljs.org/). Apareceu recentemente e fez muito barulho. É extremamente bem documentado, muito rápido e, o mais importante, tem a curva de aprendizado mais curta. É adequado se você precisar fazer o trabalho rapidamente e sem complicações.
- Rollup (https://rollupjs.org/). Ele fica em algum lugar entre o Webpack e o Parcel. Como o Webpack, é robusto e rico em recursos. É mais fácil começar do que o Webpack, porém, mas não tão fácil quanto o Parcel.
Resumo
Apesar de sua aparente simplicidade, os recursos estáticos são muito complicados. No entanto, eles constituem a maior parte dos dados transmitidos aos visitantes, portanto, o tempo gasto para otimizá-los será recompensado com juros.
Uma solução viável para recursos estáticos, não mencionada anteriormente, é expor os recursos estáticos a um CDN e sempre usar a URL completa para o recurso em visualizações e CSS. Essa abordagem tem a vantagem de ser muito simples, mas se você quiser hospedar uma hackatona de uma semana em uma cabana na floresta sem acesso à Internet, está em apuros!
A montagem e a minificação cuidadosas são outra área em que você pode economizar tempo se os ganhos de desempenho do aplicativo não justificarem o esforço. Em particular, se você tiver apenas um ou dois arquivos JavaScript em seu site e todo o CSS estiver no mesmo arquivo, você pode pular a construção, mas os aplicativos do mundo real tendem a crescer com o tempo.
Qualquer que seja o método que você escolher para fornecer recursos estáticos, aconselho você a carregá-los separadamente, de preferência em um CDN. Se te parece problemático, garanto-te: não é tão difícil como parece. Especialmente se você gastar um pouco de tempo no sistema de implantação de antemão, para que a implantação de recursos estáticos em um local e aplicativos em outro seja automática.
Se você está preocupado com o custo de hospedagem em um CDN, recomendo que você dê uma olhada nos valores que está pagando atualmente pela hospedagem. A maioria dos provedores de hospedagem cobra muito dinheiro pelo tráfego, mesmo que você não saiba sobre isso. No entanto, se de repente seu site for listado no Slashdot e você experimentar o efeito slashdot, poderá receber uma conta de hospedagem completamente inesperada. A hospedagem CDN é geralmente configurada de forma que você pague apenas pelo que usar. Por exemplo, o site que administro para uma empresa local de médio porte usa cerca de 20 GB de tráfego por mês, enquanto as taxas de hospedagem estática (que é um site com muita mídia) são de apenas alguns dólares por mês.
Os benefícios de colocar recursos estáticos em um CDN são substanciais, e o custo e a inconveniência de fazer isso são mínimos, portanto, recomendo fortemente que você escolha esse caminho.
Com certos truques de JavaScript no navegador, você pode usar o LESS não compilado. No entanto, essa abordagem pode levar a consequências negativas em termos de desempenho, portanto, não recomendo usá-la.
Mais detalhes sobre o livro podem ser encontrados no site da editora
» Índice
» Trecho
Para Habitantes desconto de 25% no cupom - JavaScript
Mediante o pagamento da versão em papel do livro, é enviado um e-book por e- correspondência.