Deusiel da Cunha de Souza - freeCodeCamp.org

Por que a raiz de um domínio não pode ser um CNAME — e outras definições sobre o DNS

Deusiel da Cunha de Souza — Tue, 03 Jan 2023 21:00:00 +0000

Artigo original: Why a domain’s root can’t be a CNAME — and other tidbits about the DNS

Este artigo usará a pergunta acima para explorar DNS, dig, registros A, registros CNAME e registros ALIAS/ANAME da perspectiva de um iniciante. Vamos começar.

Primeiro, alguns conceitos

Domain Name System (DNS): o sistema geral para converter um nome de domínio inteligível para humanos (como "example.com") em um endereço IP (93.184.216.34). O endereço IP é de um servidor (geralmente, um servidor da web) onde são armazenados os arquivos necessários para exibir uma página da web.
Servidor DNS (também conhecido como servidor de nomes): usa o software do DNS para armazenar informações sobre endereços de domínio. Existem vários níveis — aqueles pertencentes a cada provedor de serviços de internet, root (13 no total em todo o mundo), domínios de primeiro nível (em inglês, "TLD" – por exemplo, ".com") e servidores DNS de nível de domínio.
Nome de domínio: o domínio (example) combinado com o TLD (.com). O termo 'domínio' é frequentemente usado como sinônimo do nome de domínio, embora sejam diferentes. Quando você compra um "domínio" de uma empresa de registro ou revendedor, você compra os direitos de um nome de domínio específico (como "example.com") e quaisquer subdomínios que desejar criar (meu-site.example.com, mail.example.com etc.).

Fluxo de consulta de alto nível

O fluxo de alto nível do que acontece quando você digita "example.com" em seu navegador pode ser simplificado para remover os saltos para os servidores ISP, root e DNS de TLDs, conforme vemos abaixo:

Simplificação do fluxo de uma requisição DNS. Mais detalhes podem ser consultados aqui (texto em inglês).

Um domínio normalmente tem dois ou mais servidores de nome, contendo registros relacionados ao nome de domínio (como "example.com").

Muitos tipos de registros podem ser armazenados, a maioria dos quais pode ter várias entradas por tipo:

A: Registros de endereço que mapeiam o nome de domínio para um endereço IP
CNAME: Registro de Nome Canônico. Usado para apelidar um nome de domínio (ou nome de subdomínio) para outro. Veremos isso em mais detalhes posteriormente.
MX: registros do Mail eXchange que informam aos agentes de entrega de e-mail onde eles devem entregar seu e-mail
TXT: registros de texto flexíveis, para armazenar strings para uma variedade de usos
SOA: Registro Singular de Início de Autoridade mantido no nível superior do domínio. Contém informações específicas necessárias sobre o domínio, como por exemplo, seu servidor de nomes principal

Quando seu dispositivo envia uma consulta que chega a um servidor de nomes, o servidor procura no nó de registro do domínio um registro A e o endereço IP armazenado associado (example.com: 93.184.216.34). Esse endereço é, então, retornado ao dispositivo para ser usado para enviar uma solicitação ao servidor da web correto para recuperar a página da web ou o recurso solicitado.

Usando o 'dig'

dig (explorador de informações de domínio – do inglês Domain Information Groper) é uma ferramenta de linha de comando para consultar servidores DNS. Esse comando geralmente é usado para solução de problemas ou, como agora, para entender mais sobre a configuração de um sistema.

$ dig example.com resulta em uma resposta longa impressa no terminal, cuja saída padrão é detalhada aqui (texto em inglês). Dela, temos interesse apenas em ver a SEÇÃO DE RESPOSTAS(do inglês, ANSWER SECTION).

;; ANSWER SECTION:
example.com.       72703      IN     A       93.184.216.34

Podemos ver que example.com retorna um registro A de 93.184.216.34. Às vezes, os domínios terão mais de um registro A, se mais de um servidor da web puder fornecer as informações necessárias.

Tem mais! Se tentarmos alguns outros exemplos, logo veremos que outro registro comum aparece: CNAME.

$ dig www.skyscanner.net:

;; ANSWER SECTION:
www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net.
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.

e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

Usar o sinalizador +short nos permite ver claramente o caminho formado:

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net.
e11316.a.akamaiedge.net.
23.217.6.192

CNAME

Um registro CNAME permite que um nome de domínio seja usado como um apelido para outro domínio canônico (verdadeiro).

Quando o servidor DNS retorna um registro CNAME, ele não o retorna ao client. Em vez disso, ele procurará novamente o nome de domínio retornado e, por sua vez, retornará o endereço IP do registro A. Essa cadeia pode continuar com muitos níveis de CNAME profundos, mas sofre pequenos impactos de desempenho de várias pesquisas antes do armazenamento em cache.

Um exemplo simples disso pode ser se você tiver um servidor onde guarda todas as suas fotos. Você pode acessá-lo normalmente através de photos.example.com. No entanto, você também pode querer permitir o acesso via photographs.example.com. Uma maneira de tornar isso possível é adicionar um registro CNAME que aponte photographs para photos. Isso significa que, quando alguém visitar photographs.example.com, receberá o mesmo conteúdo que photos.example.com.

Usando a consulta $ dig photography.example.com, veríamos:

photographs.example.com    IN   CNAME photos.example.com
photos.example.com         IN   A     xx.xxx.x.xxx

É importante observar que o CNAME é aquela parte do lado direito. O lado esquerdo é o nome do apelido ou rótulo.

Outro uso comum é para o subdomínio www. Depois de comprar example.com, você provavelmente também desejará que os usuários que digitem www.example.com vejam o mesmo conteúdo.

Vale a pena notar aqui que example.com pode ser chamado de ápice, raiz ou nome de domínio puro.

Uma opção seria configurar outro registro A, apontando para o mesmo endereço IP de example.com. Isso é totalmente válido e é o que o site real example.com faz, mas não escala bem. O que acontece se você precisar atualizar o endereço IP para o qual example.com aponta? Você também precisaria atualizá-lo para o subdomínio www e qualquer outro que possa usar.

Se um registro CNAME foi usado como apelido para www.example.com para apontar para example.com, apenas o domínio raiz teria que ser atualizado, já que todos os outros nós apontam para ele.

Limitações do CNAME

Na época em que os padrões de DNS foram escritos, algumas regras foram estabelecidas para reger seu uso. RFC 1912 e RFC 2181 estabelecem que:

Os registros SOA e NS são obrigatórios no domínio raiz
Os registros CNAME só podem existir como registros únicos e não podem ser combinados com nenhum outro registro de recurso (com exceção dos registros DNSSEC SIG, NXT e KEY RR)

Isso exclui um CNAME de ser usado no domínio raiz, pois isso faria com que as duas regras se contradissessem.

O importante aqui é que se trata de uma limitação contratual, não técnica. É possível usar um CNAME na raiz, mas pode resultar em erros inesperados, pois está quebrando o contrato de comportamento esperado.

Um exemplo disso é relatado pela Cloudflare, descrevendo problemas que eles encontraram com os servidores de e-mail do Microsoft Exchange depois de usar um CNAME em seu domínio raiz:

Os domínios geralmente designam os servidores que lidam com seus e-mails por meio do que é conhecido como registro MX. O problema era que os servidores Exchange… podiam pegar o CNAME no registro raiz e não respeitar adequadamente o CNAME definido no registro MX. Você não pode realmente culpar o Exchange. Eles estavam operando sob as suposições estabelecidas pela especificação do DNS.

Aqui, você vê a desvantagem que pode aparecer em vários softwares de servidor ou bibliotecas. Como existe um padrão para que um CNAME seja o único registro em um nó, nenhum outro registro é procurado. Todos os outros registros serão ignorados silenciosamente, sem aviso ou mensagens de erro. Mesmo que um registro MX tenha sido definido para receber e-mail, o MX será ignorado como se não existisse porque o CNAME é avaliado primeiro. O mesmo é verdadeiro se houvesse um registro A: o CNAME teria precedência e o registro A não seria lido.

A internet moderna

Então, por que isso é um problema? Por que você desejaria usar um CNAME para seu domínio raiz? Certamente, esse é o fim do caminho ao procurar o endereço IP do servidor da web que hospeda seu conteúdo?

No cenário moderno da internet, esse não é mais o caso. O mundo é muito diferente de quando os padrões de DNS foram escritos.

Você pode optar por usar um provedor de plataforma como serviço (do inglês, PaaS), como o Heroku, e armazenar conteúdo em seus servidores da web. Você controla o conteúdo, mas não a infraestrutura. O provedor de PaaS faz o trabalho pesado da manutenção da rede. Eles normalmente fornecem um URL (`my-app.herokuapp.com`) que é um subdomínio de seu domínio raiz. Você pode visualizar os endereços IP dos servidores da web em que seu conteúdo está. Eles, no entanto, estão totalmente sob o controle do provedor de PaaS e serão alterados sem aviso prévio.

A escala e a frequência das alterações de back-end feitas pelo provedor de PaaS podem dificultar a manutenção do registro A do domínio raiz apontando para um único endereço IP. Idealmente, você gostaria de fazer isso:

example.com      IN   CNAME    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.example.com      IN   CNAME    my-app.herokuapp.com.
www.example.com  IN   CNAME    my-app.herokuapp.com.

para permitir que o Heroku (ou seu provedor de host escolhido) gerencie a atualização do registro A para a qual o CNAME aponta sem nenhuma alteração feita por você. No entanto, como sabemos agora, isso quebra a especificação do DNS e, portanto, é uma péssima ideia.

É possível simplesmente implementar um redirecionamento 301/302 de example.com para www.example.com. Porém, essa instrução ocorre no servidor da web (portanto, ainda tem o problema de precisar usar um registro A fixo no DNS para apontar para esse servidor da web) ou um redirecionamento de provedor de DNS personalizado (que sofre complicações com HTTPS).

Isso também tem o efeito colateral de alterar o domínio que você vê na barra de URL, o que você pode não querer. Este método destina-se a quando seu site foi movido permanentemente ou quando você está tentando preservar as classificações de SEO, em vez de resolver o problema de apontar para um back-end de mudança complexo de maneira escalável.

A solução

Vários provedores de DNS já desenvolveram soluções personalizadas para contornar esse problema, incluindo:

ALIAS em DNSimple
ANAME em DNS Made Easy
ANAME em easyDNS
CNAME (virtual) em CloudFlare

Esses são todos os tipos de registro virtual que fornecem comportamento semelhante ao CNAME, sem nenhuma das desvantagens. A implementação exata pode diferir, mas, em um alto nível, quando o servidor DNS vê um desses tipos de registro virtual, ele age como um resolvedor de DNS. Ele segue a cadeia criada pelo apelido até resolver em um registro (ou registros) A e retornar esses registros A ao servidor DNS. Isso "achata" a cadeia CNAME nos registros A retornados e é indistinguível da consulta enviada. A consulta vê apenas um registro A puro, que não quebra a especificação do DNS e não apresenta nenhuma das desvantagens de um CNAME.

Esses registros virtuais podem ficar ao lado de outros registros na raiz, sem medo de comportamentos não intencionais. Dependendo do método de resolução de DNS do provedor ao seguir a cadeia CNAME, eles também podem ter benefícios de desempenho ao armazenar em cache pesquisas anteriores.

Para uma configuração simples de DNS, configuraríamos conforme abaixo. Essa solução tem todas as vantagens da técnica de apelidar ou rotular um nome de domínio e nenhum dos riscos de usá-lo no nível raiz.

example.com      IN   ALIAS    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.

Obrigado por ler este artigo!

Como sempre, estou aberto a quaisquer correções ou tópicos adicionais.

Referências (todas em inglês)

What is a DNS Server
Set Up a DNS Name Server
Páginas de suporte do DNSimple e blog do ALIAS
Suporte do Cloudflare e blog do CNAME
dig HowTo
Várias publicações ótimas no Stack Overflow ou no StackExchange
Entradas bem-escritas da Wikipédia
Blog da Netlify "To www or not www"

Como tornar o seu site da web em uma aplicação para dispositivos móveis com 7 linhas de JSON

Deusiel da Cunha de Souza — Wed, 31 Aug 2022 21:00:00 +0000

Artigo original: How to Turn Your Website into a Mobile App with 7 Lines of JSON

por Ethan

Uma nova abordagem para transformar o mecanismo da web em aplicações para dispositivos móveis nativas

E se fosse dito a você que as 7 linhas de JSON acima, de cor laranja, seriam tudo que é preciso para transformar um site da web em uma aplicação para dispositivos móveis? Não há a necessidade de reescrever seu site da web usando alguma API de framework somente para fazê-lo se comportar como uma aplicação para dispositivos móveis. Usaremos seu site como ele está e o tornaremos uma aplicação para dispositivos móveis, apenas alterando o URL.

E se, apenas ajustando um pouco o JSON, você pudesse acessar todas as APIs nativas, componentes de interface de usuário nativos e transições de visualização nativas prontas para uso?

Aqui está um exemplo inicial de como seria:

Observe como eu incorporei uma página da web do github.com, mas que, no resto do layout, são todos componentes nativos da interface de usuário, como o cabeçalho de navegação e a barra de guias inferior. A transição é automaticamente nativa sem que você precise reescrever o site usando alguma API.

Antes de eu explicar como isso funciona, você poderia se perguntar: "Isso é legal, mas você pode fazer algo significativo além de apenas exibir a página web em um quadro (frame) de aplicação nativa?"

Ótima pergunta, porque esse é o tema principal desta publicação. Tudo o que você precisa fazer é criar um canal de comunicação bidirecional contínuo entre a visualização web e a aplicação, de modo que a aplicação principal possa acionar qualquer função JavaScript dentro da visualização web e a visualização web possa buscar dados no exterior para chamar APIs nativas.

Aqui está um exemplo do quê estamos falando:

O gerador de QR code em ação

Observe que esta visualização contém:

Cabeçalho de navegação nativo, completo com funcionalidade de transição integrada
Uma visualização web, que incorpora uma aplicação da web geradora de código QR
Um componente de entrada de bate-papo nativo na parte inferior

Tudo isso pode ser descrito apenas ajustando alguns dos atributos do JSON que vimos acima.

Finalmente, observe que o código QR muda à medida que você insere algo na caixa de texto do bate-papo. Essa caixa de texto aciona uma função do JavaScript dentro da aplicação para a web de código QR que gera novamente a imagem.

Nenhum framework tentou resolver fundamentalmente esse problema de "integração perfeita da visualização da Web em aplicações nativas" porque todos estão focados em escolher o lado 100% nativo ou 100% HTML5.

Sempre que você ouve alguém falar sobre o futuro das aplicações para dispositivos móveis, provavelmente ouve: "Será a abordagem do HTML5 que vence? Ou será a nativa?"

Nenhum deles vê nativo ou html como coisas que poderiam coexistir ou, até, criar sinergia e alcançar coisas que não seriam facilmente possíveis de outro modo.

Neste artigo será explicado:

Por que misturar o mecanismo da web com componentes nativos é normalmente uma boa ideia.
Por que uma integração perfeita de HTML e nativo não é fácil e como eu implementei uma.
Mais importante ainda, como VOCÊ pode usá-la para criar sua própria aplicação instantaneamente.

Por que você usaria HTML em uma aplicação nativa?

Antes de prosseguirmos, vamos primeiro discutir se isso é mesmo uma boa ideia e quando você pode querer adotar essa abordagem. Aqui estão alguns casos de uso em potencial:

1. Usar recursos nativos da web

Algumas partes da sua aplicação podem ser implementadas com mais qualidade usando o mecanismo da web. Por exemplo, o Websocket é um recurso nativo da web projetado para o ambiente da web. Nesse caso, faz sentido usar o mecanismo da web integrado (WKWebView para iOS e WebView para Android) em vez de instalar uma biblioteca de terceiros que essencialmente "emula" o Websocket.

Não há a necessidade de código adicional para fazer algo que podemos fazer livremente, o que nos leva ao próximo tópico.

2. Evitar o uso de arquivos binários muito grandes

Você pode querer incorporar rapidamente recursos que, de outro modo, exigiriam uma enorme biblioteca de terceiros.

Por exemplo, para incorporar um gerador de imagem de código QR nativamente, você precisará instalar alguma biblioteca de terceiros que aumentará o tamanho do arquivo binário. Se você, no entanto, usar o mecanismo de visualização da web e uma biblioteca JavaScript por meio de um simples

Vamos criar um barra de navegação com a tag nav. Então, uma div com a classe .container, onde ficarão todos os cartões que vamos adicionar depois com JavaScript.

Agora que terminamos essa parte, vamos estilizar nosso aplicativo com CSS.

Estilização

Aqui, como de costume, começamos importando as fontes de que vamos precisar. Então, vamos redefinir alguns comportamentos (e valores) que são padrão em nosso navegador.

No arquivo css/style.css

@import url("https://fonts.googleapis.com/css?family=Nunito:400,700&display=swap");
* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}
body {
  background: #fdfdfd;
  font-family: "Nunito", sans-serif;
  font-size: 1rem;
}
main {
  max-width: 900px;
  margin: auto;
  padding: 0.5rem;
  text-align: center;
}
nav {
  display: flex;
  justify-content: space-between;
  align-items: center;
}
ul {
  list-style: none;
  display: flex;
}

li {
  margin-right: 1rem;
}
h1 {
  color: #e74c3c;
  margin-bottom: 0.5rem;
}

Então, vamos limitar o tamanho do elemento main para largura máxima de 900px (900 pixels) para fazer com que ele apareça bem em telas mais largas.

Para a barra de navegação, queremos que o logotipo fique à esquerda e os links à direita. Então, para a tag nav, depois de torná-la um "contêiner flex", usamos justify-content: space-between; para alinhá-las.

No arquivo css/style.css

.container {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr));
  grid-gap: 1rem;
  justify-content: center;
  align-items: center;
  margin: auto;
  padding: 1rem 0;
}
.card {
  display: flex;
  align-items: center;
  flex-direction: column;
  width: 15rem auto;
  height: 15rem;
  background: #fff;
  box-shadow: 0 10px 20px rgba(0, 0, 0, 0.19), 0 6px 6px rgba(0, 0, 0, 0.23);
  border-radius: 10px;
  margin: auto;
  overflow: hidden;
}
.card--avatar {
  width: 100%;
  height: 10rem;
  object-fit: cover;
}
.card--title {
  color: #222;
  font-weight: 700;
  text-transform: capitalize;
  font-size: 1.1rem;
  margin-top: 0.5rem;
}
.card--link {
  text-decoration: none;
  background: #db4938;
  color: #fff;
  padding: 0.3rem 1rem;
  border-radius: 20px;
}

Teremos alguns cartões. Por isso, o elemento com a classe .container será mostrado como grid. E, com a propriedade grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)), podemos, agora, fazer nossos cartões ficarem responsivos, então eles podem usar pelo menos 15rem de largura se houver espaço suficiente para isso (ou 1fr se não houver espaço para 15rem).

E para fazer nossos cartões ficarem ainda mais bonitos, nós duplicamos o efeito de sombra no elemento com a classe .card e usamos object-fit: cover no .card--avatar para evitar que a imagem estique demais.

Agora, está muito melhor. Porém, ainda não temos dados para mostrar.

Vamos consertar isso na próxima seção.

Exibição dos dados com JavaScript

Note que usei imagens grandes, que demoram algum tempo para carregar. Isso mostrará a você, da melhor forma, o poder dos service workers.

Como disse antes, a classe .container conterá nossos cartões. Portanto, precisamos selecioná-la com nosso código JavaScript.

No arquivo js/app.js

const container = document.querySelector(".container")
const coffees = [
  { name: "Perspiciatis", image: "images/coffee1.jpg" },
  { name: "Voluptatem", image: "images/coffee2.jpg" },
  { name: "Explicabo", image: "images/coffee3.jpg" },
  { name: "Rchitecto", image: "images/coffee4.jpg" },
  { name: " Beatae", image: "images/coffee5.jpg" },
  { name: " Vitae", image: "images/coffee6.jpg" },
  { name: "Inventore", image: "images/coffee7.jpg" },
  { name: "Veritatis", image: "images/coffee8.jpg" },
  { name: "Accusantium", image: "images/coffee9.jpg" },
]

Então, criamos um array de cartões com os nomes e imagens.

No arquivo js/app.js

const showCoffees = () => {
  let output = ""
  coffees.forEach(
    ({ name, image }) =>
      (output += `
              
                
                ${name}
                Taste
              
              `)
  )
  container.innerHTML = output
}

document.addEventListener("DOMContentLoaded", showCoffees)

Com o código acima, podemos fazer um loop no array e renderizar os elementos no nosso arquivo HTML. E, para fazer tudo funcionar, esperamos até que o conteúdo do DOM (Modelo de Objeto de Documentos) termine de carregar para que possamos executar o método showCoffees.

Já fizemos muito, mas, por agora, temos somente um aplicativo web tradicional. Então, vamos mudar isso na próxima seção, introduzindo algumas funcionalidades de Aplicativo Web Progressivo.

Manifesto do Aplicativo Web

O manifesto do aplicativo web é um simples arquivo em formato JSON, que informa ao navegador sobre o seu aplicativo web. Esse manifesto informa como o aplicativo deve se comportar quando for instalado no dispositivo móvel do usuário ou no seu desktop. E, para mostrar a opção de adicionar à tela inicial, é obrigatório ter o manifesto.

Agora que já sabemos o que é um manifesto, vamos criar um novo arquivo chamado manifest.json (o nome precisa ser esse) na pasta raiz. Então, vamos adicionar o bloco de código abaixo.

No arquivo manifest.json

{
  "name": "Dev'Coffee",
  "short_name": "DevCoffee",
  "start_url": "index.html",
  "display": "standalone",
  "background_color": "#fdfdfd",
  "theme_color": "#db4938",
  "orientation": "portrait-primary",
  "icons": [
    {
      "src": "/images/icons/icon-72x72.png",
      "type": "image/png", "sizes": "72x72"
    },
    {
      "src": "/images/icons/icon-96x96.png",
      "type": "image/png", "sizes": "96x96"
    },
    {
      "src": "/images/icons/icon-128x128.png",
      "type": "image/png","sizes": "128x128"
    },
    {
      "src": "/images/icons/icon-144x144.png",
      "type": "image/png", "sizes": "144x144"
    },
    {
      "src": "/images/icons/icon-152x152.png",
      "type": "image/png", "sizes": "152x152"
    },
    {
      "src": "/images/icons/icon-192x192.png",
      "type": "image/png", "sizes": "192x192"
    },
    {
      "src": "/images/icons/icon-384x384.png",
      "type": "image/png", "sizes": "384x384"
    },
    {
      "src": "/images/icons/icon-512x512.png",
      "type": "image/png", "sizes": "512x512"
    }
  ]
}

No final, é só um arquivo JSON com algumas propriedades obrigatórias e outras opcionais.

name: Quando o navegador iniciar a tela de boas-vindas, esse será o nome mostrado na tela de boas-vindas

short_name: Será o nome que aparecerá abaixo do atalho para seu aplicativo na tela inicial

start_url: Será a página mostrada ao usuário quando o seu aplicativo for aberto.

display: Informará ao seu navegador como mostrar o aplicativo. Existem diversas formas de mostrar, como minimal-ui, fullscreen, browser, etc. Aqui, nós usaremos o modo standalone para esconder qualquer coisa relacionada com o navegador.

background_color: Quando o navegador iniciar a tela de boas-vindas, essa será a cor de fundo da tela.

theme_color: Essa será a cor da barra de status quando o app for aberto.

orientation: Informa ao navegador em qual orientação (horizontal ou vertical) mostrar o app.

icons: Quando o navegador carregar a página de boas-vindas, esse será o ícone mostrado na tela. Aqui, eu usei todos os tamanhos para que o app se ajuste a qualquer dispositivo, mas você pode usar um ou dois. Depende da sua escolha.

Agora que nós temos um manifesto de aplicativo web, vamos adicioná-lo ao nosso arquivo HTML.

No arquivo index.html (na tag head)

Como você pode ver, nosso arquivo manifest.json foi importado na tag head. Também importamos alguns outros links para podermos oferecer suporte para sistemas iOS na hora de mostrar ícones e colorir nossa barra de status com nosso tema de cores.

Com isso, agora podemos mergulhar mais fundo na parte final e introduzir o conceito de service worker.

O que é um Service Worker?

Note que Aplicativos Web Progressivos (PWAs) funcionarão apenas em https, porque o service worker pode acessar as requisições e lidar com elas.

Um service worker é um script que seu navegador executa em segundo plano em uma thread separada. Isso significa que ele é executado em um lugar completamente diferente da sua página web. Essa é a razão pela qual ele não pode manipular os elementos do DOM.

Contudo, ele é muito poderoso. O service worker pode interceptar e lidar com requisições de rede, gerenciar o cache para possibilitar o uso off-line ou enviar notificações push para seus usuários.

Então, vamos criar nosso primeiro service worker na pasta raiz e dar a ele o nome de serviceWorker.js (você pode usar o nome que quiser). Porém, você deve colocá-lo na pasta raiz para não limitar o escopo a apenas uma pasta.

Armazenamento (cache) dos arquivos

No arquivo serviceWorker.js

const staticDevCoffee = "dev-coffee-site-v1"
const assets = [
  "/",
  "/index.html",
  "/css/style.css",
  "/js/app.js",
  "/images/coffee1.jpg",
  "/images/coffee2.jpg",
  "/images/coffee3.jpg",
  "/images/coffee4.jpg",
  "/images/coffee5.jpg",
  "/images/coffee6.jpg",
  "/images/coffee7.jpg",
  "/images/coffee8.jpg",
  "/images/coffee9.jpg",
]

self.addEventListener("install", installEvent => {
  installEvent.waitUntil(
    caches.open(staticDevCoffee).then(cache => {
      cache.addAll(assets)
    })
  )
})

Esse código parece intimidador no começo, mas é só JavaScript (então, não se preocupe).

Declaramos o nome do nosso cache staticDevCoffee e os arquivos para salvar no cache. Após fazermos isso, precisamos adicionar um listener ao self.

self é o service worker. Ele nos permite "ouvir" o ciclo de vida dos eventos e fazer alguma coisa quando esses eventos de fato acontecem.

O service worker tem alguns ciclos de vida e um deles é o evento install. Ele é executado quando um service worker é instalado. Ele executa tão logo um worker execute e somente é executado uma vez por service worker.

Quando o evento install é acionado, executamos uma função de retorno (callback), que nos dará acesso ao objeto event.

Armazenar alguma coisa no navegador pode levar algum tempo para terminar, porque é assíncrono.

Então, para lidar com isso, precisamos usar waitUntil() que, como você pode imaginar, vai esperar o carregamento para, então, finalizar.

Uma vez que a API do cache está pronta, podemos executar o método open() e criar nosso cache passando o nome do nosso cache como um argumento, assim: caches.open(staticDevCoffee)

Então, essa função nos retornará uma Promise, que nos ajuda a armazenar nossos arquivos no cache com cache.addAll(assets).

Espero que você ainda esteja comigo.

Agora, armazenamos nossos arquivos no navegador com sucesso. E, na próxima vez em que carregarmos a página, o service worker lidará com as requisições e acessará o cache se estivermos off-line.

Então, vamos acessar nosso cache.

Acesso aos arquivos

No arquivo serviceWorker.js

self.addEventListener("fetch", fetchEvent => {
  fetchEvent.respondWith(
    caches.match(fetchEvent.request).then(res => {
      return res || fetch(fetchEvent.request)
    })
  )
})

Aqui, usamos o evento fetch para obter nossos dados. A função de retorno (callback) nos dá acesso ao fetchEvent. Então, acoplamos respondWith() para modificar a resposta padrão do navegador. Em vez disso (da resposta padrão), a função retorna uma promise, já que a ação de acessar os arquivos pode demorar algum tempo para terminar.

Quando o cache estiver pronto, podemos aplicar caches.match(fetchEvent.request). Isso verificará se alguma coisa no cache corresponde a fetchEvent.request. Para que você saiba, fetchEvent.request é apenas um array de arquivos.

Então, a função retorna uma promise. Finalmente, podemos retornar os resultados, se eles existirem, ou fazer o fetch inicial caso não existam resultados a exibir.

Agora, nossos arquivos podem ser armazenados e acessados pelo service worker, o que melhora o tempo de carregamento das nossas imagens um pouco.

E o mais importante: isso faz com que o nosso app fique disponível off-line.

O service worker, porém, não consegue fazer todo o trabalho sozinho. Precisamos registrá-lo em nosso projeto.

Registro do Service Worker

No arquivo js/app.js

if ("serviceWorker" in navigator) {
  window.addEventListener("load", function() {
    navigator.serviceWorker
      .register("/serviceWorker.js")
      .then(res => console.log("service worker registered"))
      .catch(err => console.log("service worker not registered", err))
  })
}

Aqui, verificamos se o service worker é suportado pelo nosso navegador (ele não é suportado por todos os navegadores).

Então, "ouvimos" o evento de carregamento da página para registrar nosso service worker, passando para ele o nome do arquivo serviceWorker.js para navigator.serviceWorker.register() como parâmetro para registrá-lo.

Com esse ajuste, agora transformamos nosso aplicativo web normal em um PWA.

Conclusões

Através deste artigo, vimos que os PWAs podem ser maravilhosos. Adicionando um manifesto de aplicativo web e um service worker, realmente melhoramos a experiência de usuário do nosso aplicativo web tradicional. Isso ocorre porque os PWAs são rápidos, seguros, confiáveis e, o mais importante de tudo, eles permitem o uso off-line.

Muitos frameworks atuais já vêm com um service worker configurado para nós. Saber como implementá-los com JavaScript puro, no entanto, pode ajudá-lo a entender os PWAs.

Você pode ir mais além com os service workers, como, por exemplo: armazenar arquivos dinamicamente, limitar o tamanho do seu armazenamento e assim por diante.

Obrigado por ler esse artigo.

Você pode ver como o aplicativo ficou aqui e o código fonte aqui.

Leia mais artigos do autor no blog do autor.

Próximos passos (textos em inglês)

Web Manifest Documentation (documentação do manifesto da web)

Service Worker Documentation (documentação do service worker)

Web Manifest Generator (gerador do manifesto da web)

Browser Support (suporte aos navegadores)