Saiba mais sobre o Web Push Declarativo

Meu nome é Brady Eidson. Sou engineer na equipe WebKit Architecture. Estou animado para falar com vocês sobre os recentes avanços nas notificações por web push.

As notificações por push são uma parte crucial da web moderna, assim como para qualquer plataforma atual.

Começamos a criar notificações por push nas plataformas da Apple em 2009 com o iPhone OS 3. Fomos pioneiros, mas as notificações por push obviamente pertenciam a todas as plataformas. Elas foram adicionadas ao macOS, outras plataformas de desktop e outras plataformas móveis logo depois. Quase da noite para o dia, os apps podiam presumir que as notificações por push estavam integradas à plataforma.

No início, ajustávamos continuamente como o push funcionava para que os apps nativos encontrassem o ponto ideal para desenvolvedores e usuários. Sabíamos desde o início que as notificações por push pertenciam à web e queríamos ser ponderados nos detalhes. Adicionamos a Notificação por Push do Safari ao Safari 7. Os desenvolvedores adotaram o Push do Safari, e os usuários se envolveram, então sabíamos que algo estava acontecendo. O Push do Safari exigia integração com os sistemas da Apple, então não podíamos padronizá-lo de modo que outros navegadores pudessem implementar. Todos os navegadores precisavam de notificações por push. A comunidade de padrões da web ficou trabalhando no web push, e o primeiro navegador o lançou um ou dois anos depois.

Para os padrões da web, foi uma era de foco intenso em recursos JavaScript. O web push original foi projetado para ser extremamente flexível, 100% impulsionado pelo código JavaScript que você escreve. Temos orgulho de extrair o máximo desempenho ao executarmos JavaScript, mas, como todo engenheiro de software sabe, qualquer código que seja preciso escrever e manter é mais sujeito a bugs do que não escrever código algum.

E, mesmo em um mecanismo JavaScript no limite da eficiência, executar qualquer código é menos eficiente que não fazer nada.

Outra desvantagem dessa abordagem é a privacidade. Dados de site são um vetor para rastrear os usuários durante a navegação. É por isso que a Prevenção de Rastreamento Inteligente limita o tempo de vida do JavaScript necessário para o web push original.

Com as notificações por push do iOS, macOS e Safari, a própria mensagem por push contém uma descrição padronizada da notificação visível pelo usuário. Nenhum código específico de app precisa ser desenvolvido ou executado para exibi-la.

Os apps nativos nem precisam do código no dispositivo para exibir uma notificação por push. Apps que o iOS descarregou exibem suas notificações sem problemas.

Ao adicionar o web push original aos navegadores, observamos algo interessante. Mesmo com a flexibilidade oferecida pelos padrões, muitos sites enviam mensagens por push em JSON simples de analisar, e o JavaScript do Service Worker o traduz para a chamada da API para mostrar a notificação. Dado o longo histórico com notificações por push para iOS, macOS e Safari, isso fazia sentido para nós. E isso nos deu uma ideia bastante objetiva. Se declarar a notificação antecipadamente em JSON for um caso comum, poderíamos evoluir o web push para atender você onde estiver.

Ao remover a etapa que depende de você escrever um código, você obtém os mesmos benefícios que os apps nativos tiveram desde o início.

O web push declarativo tem facilidade de uso, eficiência e transparência. Usar é tão simples quanto enviar mensagens por push em um formato padronizado, e a configuração quase não requer código.

Nós o projetamos tendo em mente a web aberta, envolvendo a comunidade de padrões. Ele também foi projetado para ser compatível com versões anteriores de navegadores. O web push declarativo é realmente um avanço progressivo para a web. Se você já domina o web push original, os conceitos que você conhece continuam válidos.

Como ele se baseia em padrões estabelecidos, abordaremos o que há de novo no web push declarativo revisando partes do web push original. Vamos começar com uma visão geral de alto nível do web push original.

Ele depende quase inteiramente do JavaScript na forma de um Service Worker instalado. Um Service Worker contém o código que manipula eventos por "push" para exibir notificações.

Então você precisa de uma assinatura por push. Ela contém informações que o servidor precisa para acessar o navegador do usuário, como o URL a ser usado para enviar uma mensagem por push. Em resposta a um movimento do usuário, o JavaScript solicita uma assinatura por push e a envia ao servidor para uso posterior.

Na hora de enviar uma notificação, você usa o URL na assinatura para enviar uma mensagem por push. Em navegadores do WebKit, você enviará para o mesmo Apple Push Notification Service que alimenta nossos apps nativos, mas não precisa de uma conta de desenvolvedor da Apple para usar essas assinaturas.

A mensagem chega ao navegador, que procura o Service Worker responsável e o inicia. O navegador envia um evento por push para esse Service Worker, que inclui todos os dados enviados em sua mensagem por push.

O Service Worker analisa a mensagem e constrói uma chamada do JavaScript para a API showNotification, que exibe a notificação.

Mais tarde, quando o usuário toca ou clica nessa notificação, o navegador inicia novamente o Service Worker adequado, se ainda não estiver em execução, e envia um evento notificationclick para ele. O manipulador, então, tem a tarefa de fazer algo útil, que é quase sempre abrir uma janela para um URL.

É assim que o web push original funciona hoje. A maioria das etapas descritas é manipulada por JavaScript que você precisa escrever e o navegador precisa executar.

Embora o web push declarativo não elimine completamente o JavaScript, ele chega perto. O único JavaScript necessário no web push declarativo é essa assinatura por push, não precisando mais de um Service Worker.

Depois de enviar uma mensagem por push declarativo, o navegador a recebe como antes e a analisa, procurando por JSON válido.

Ele garante que o JSON descreva uma notificação visível do usuário válida e, então, a exibe automaticamente.

O navegador também sabe como lidar automaticamente com toques ou cliques na notificação. Abordaremos como o navegador sabe o que fazer em breve, mas antes voltaremos ao JavaScript necessário para obter essa assinatura por push. Vamos ver como esse código era antes, com o web push original, e como ele é agora, com o web push declarativo.

Isso parecerá familiar para aqueles que já usaram o web push original antes.

Como mencionei, o web push original requer um Service Worker instalado antes de prosseguir. Tendo o registro do Service Worker, você poderá acessar o objeto PushManager em resposta a um movimento do usuário para solicitar uma assinatura por push.

O código para obter uma assinatura por push com web push declarativo é quase o mesmo de antes, mas, como nenhum Service Workers é necessário, o PushManager também está disponível no objeto window.

E aqui acontece a magia. Se usar web push declarativo puro, esse é todo o código que você precisa escrever. O web push declarativo define um formato JSON padrão para mensagens por push. Aqui está um exemplo de mensagem válida mínima da ferramenta de infraestrutura crítica de nossa equipe, o app da web Browser Pets.

Ele inclui uma entrada obrigatória descrevendo uma notificação visível do usuário.

Essa notificação deve ter o texto do título e um URL para onde navegar se o usuário tocar ou clicar na notificação.

Essa entrada superior é o valor mágico para uma mensagem por push declarativo. Sempre deve haver uma chave web_push com o valor 8-0-3-0.

O 8030 é o padrão RFC original da Internet Engineering Task Force para mensagens por web push, e achamos extremamente improvável que alguém o incluísse.

Lembre que cobrimos o fluxo de uma mensagem por push declarativo através do navegador.

Procurar a chave mágica faz parte desse fluxo.

O que acontece se o navegador tentar analisar JSON a partir da mensagem por push e falhar? Nesse caso, ele retorna ao web push original, usando um Service Worker para manipular a mensagem.

Ele também retornará ao web push original se o JSON não tiver a chave mágica.

E se a mensagem por push contiver JSON e tiver a chave mágica, mas não descrever uma notificação válida?

Nesse caso, o navegador simplesmente não fará nada, descartando a mensagem. Mas se a mensagem por push passar por todas essas verificações, o navegador exibirá a notificação automaticamente.

Um título de notificação e um URL de navegação são os requisitos mínimos de uma notificação válida. Mas se você tem experiência com o web push original, sabe que o JavaScript tem muito mais opções ao criar uma notificação. O web push declarativo dá suporte para todas.

Aqui, especificamos um corpo para a mensagem, uma tag de notificação e solicitamos que a plataforma reproduza o som de notificação padrão, se possível. São apenas exemplos, tudo que é respaldado pelo dicionário NotificationOptions padrão W3C é respeitado aqui.

E tem mais. Selos de app, para coisas como contagens não lidas, tendem a estar junto com as notificações, por isso as mensagens por push declarativo também dão suporte à atualização integrada do selo do app.

É um verdadeiro alívio ver quantas notificações o navegador agora pode exibir automaticamente. Mas às vezes suas necessidades são mais específicas e você não pode depender do navegador para tudo.

Aprendemos essa lição com o push nativo no iOS e no macOS, e os apps que usam o framework UserNotifications têm esse recurso há algum tempo. Embora essas mensagens por push sempre descrevam uma notificação visível, o app pode optar por refiná-la para algo mais útil.

O web push declarativo também dá suporte a isso, na forma de processamento opcional por um Service Worker. Por que isso é tão importante? Isso é útil quando você tem padrões extremamente altos para a precisão de suas notificações. Por exemplo, o servidor do Browser Pets pode notificar que o usuário tem 7 mensagens não lidas, sem saber que o usuário já leu 3 delas. O JavaScript no dispositivo do cliente pode atualizar a notificação para ajudar o usuário.

Às vezes, matematicamente, não é possível incluir o texto de notificação. Os usuários do Browser Pets esperam criptografia de ponta a ponta de nível mundial ao enviar mensagens diretas entre si, e uma chave no dispositivo do cliente é a única forma de decodificar a notificação. Vamos ver como fica. Esta é a aparência do JSON de notificação para uma típica mensagem direta do Browser Pets.

O JSON contém os dados que foram criptografados no dispositivo do remetente. O dispositivo do usuário tem a chave para descriptografar esses dados e pode fazer isso usando o Service Worker opcional.

O JSON também inclui uma entrada que indica que "mutable" está definido como verdadeiro. As mensagens por push declarativo costumam ser manipuladas automaticamente, mas essa entrada informa ao navegador que essa notificação precisa ser processada pelo Service Worker.

Este é o JavaScript que o Browser Pets usa para descriptografar mensagens diretas.

Demos ao nosso Service Worker um manipulador de eventos por push, como se fosse um requisito com o web push original.

Uma novidade é que, se o evento que está sendo enviado se originar de um push especificado como mutable, o evento terá uma cópia da notificação proposta pelo JSON declarativo.

Ao inspecionar essa notificação, conseguimos identificar que se trata de uma mensagem direta e também acessar os dados criptografados.

Lembra o nosso fluxograma para web push declarativo? Depois de validar a descrição da notificação, o navegador procura a entrada "mutable".

Se for ausente ou false, o navegador exibirá a notificação automaticamente.

Se for verdadeira, e se o Service Worker mostrar uma notificação de substituição, o navegador usará a substituição em vez do texto sem formatação da mensagem por push.

Portanto, se o Service Worker descriptografar a mensagem direta e substituir a notificação proposta, o navegador exibirá a mensagem descriptografada.

Mas se ele não conseguir descriptografar a mensagem e, portanto, não oferecer uma substituição, a notificação de texto simples original será usada em seu lugar.

A notificação declarativa também será usada nos casos em que o Service Worker não puder ser iniciado, seja porque os recursos de privacidade o removeram ou porque o dispositivo está sob pressão de recursos. O web push declarativo usa o JavaScript opcional do Service Worker assim como o web push original requer o Service Worker. Isso nos leva possivelmente à parte que eu mais gosto. Vamos analisar a compatibilidade retroativa.

Hoje, a maioria dos mecanismos de navegação dá suporte ao web push original e muitos sites já o usam. Embora a ampla adoção do web push declarativo seja melhor para todos, asseguramos que seria fácil adotá-lo mantendo suas notificações em todos os navegadores. Para muitos que já usam o web push original e fazem uma análise simples de JSON para exibir uma notificação, eu diria que o formato das mensagens por push evoluiu aos poucos, conforme as necessidades cresceram e se tornaram mais complexas. Foi assim que o Browser Pets se desenvolveu ao longo dos anos. Quando a equipe do WebKit começou a trabalhar com o web push declarativo, queríamos que o Browser Pets fornecesse as notificações mais eficientes e confiáveis possíveis. Mas é claro que o push deve continuar funcionando em todos os navegadores. Vou repassar como fizemos a atualização.

A notificação JSON do Browser Pets evoluiu organicamente com o tempo.

A princípio, incluía apenas o texto do título para a notificação.

Originalmente, todos os cliques de notificação abriam o app principal Browser Pets, mas então adicionamos essa entrada clickURL para configurar onde o clique de notificação pode ir.

Depois, alguns engineers notaram que o corpo do texto da notificação era importante.

Assumo a responsabilidade pela próxima mudança – sugeri que as notificações reproduzissem o som de alerta do sistema, sempre que possível.

O engineer seguinte percebeu que estávamos basicamente configurando as notificações com um dicionário NotificationOptions padrão da web, e decidiu colocar isso no código explicitamente. Evidentemente, eles não voltaram para atualizar as opções anteriores.

Esse formato JSON ad-hoc tem todos os bits e partes que compõem uma chamada de API para showNotification, apenas com nomes e estrutura diferentes.

Reorganizá-lo para corresponder ao formato padrão declarativo foi trivial.

Também foi fácil renomear cada propriedade para o nome padrão encontrado em um dicionário NotificationOptions.

Quando adicionamos a chave mágica para informar ao navegador que esta era uma mensagem por push declarativo, recebemos notificações automáticas em navegadores mais recentes compatíveis.

Voltando àquele JSON ad-hoc. Com o web push original, a mensagem por push é apenas parte da história. O Service Worker precisa fazer algo com ela. Aqui está o Service Worker original do Browser Pets. Cada argumento que amontoamos nesse JSON precisava ser retirado pelo nome e tínhamos que criar um dicionário NotificationOptions para a eventual chamada para showNotification.

Agora lembre-se de como é a mensagem por push declarativo.

Por design, o elemento essencial de uma mensagem declarativa que descreve a notificação é, em si, um dicionário válido de NotificationOptions. Então, ao reformatarmos nossa mensagem por push para ser um JSON declarativo válido, reescrever nosso Service Worker para lidar com isso é simples.

Retiramos o elemento "notification" do JSON, extraímos o título e os passamos para showNotification no estado em que se encontram.

Após refatorar a mensagem por push JSON e o manipulador de eventos por push do Service Worker, as mensagens do web push aproveitam os recursos de todos os navegadores.

Os navegadores que dão suporte a web push declarativo lidam com eles de forma confiável e eficiente.

E os navegadores que não dão suporte a web push declarativo lidam com eles por meio do JavaScript que você escreve, assim como as mensagens do web push originais. Estamos empolgados com o web push declarativo e esperamos que ele funcione para todos. Experimente no Safari 18.5 e posterior no macOS ou em apps da web salvos na tela de início no iOS 18.4 e iPadOS 18.4 e posterior.

Se estiver dando suporte ao web push no seu app pela primeira vez, poderá optar pelo formato declarativo desde o dia 1. Se já usa o web push, este é o melhor momento para iniciar a transição. Afastar-se do formato legado de notificação por push do Safari, que por si só é declarativo, nunca foi tão fácil. Ao adotá-lo, mantenha à mão os recursos associados a esta sessão para dar feedback à comunidade de padrões da web ou ao projeto WebKit.

Você também pode consultar essas sessões para saber detalhes de como nossos navegadores dão suporte ao web push em geral, além de mais novidades do Safari e do WebKit este ano.

Agradecemos sua participação.