O dia de hoje marca o lançamento da primeira versão Canário do Android Studio 4.3, juntamente com o plug-in do Android para Gradle (AGP) versão 7.0.0-alpha01. Com esse lançamento, estamos ajustando a numeração da versão para nosso plug-in Gradle, dissociando-o do esquema de controle de versões do Android Studio e pulando dois números inteiros. Nesta postagem do blog, explicaremos os motivos dessa mudança e faremos uma prévia de algumas mudanças importantes que estamos fazendo nas novas APIs e DSL do plug-in do Android para Gradle em incubação.
Com o AGP 7.0.0, estamos adotando os princípios do controle de versões semântico. Isso significa que apenas as mudanças de versões principais afetarão a compatibilidade com a API. Pretendemos lançar uma versão principal por ano, assim que a Gradle introduzir sua própria versão principal anual.
Além disso, no caso de uma alteração interruptiva, garantiremos que a API removida seja marcada com @Deprecated com aproximadamente um ano de antecedência e que sua substituição seja disponibilizada ao mesmo tempo. Isso dará aos desenvolvedores cerca de um ano para migrar e testar plug-ins com a nova API antes que a antiga seja removida.
O alinhamento à versão do Gradle é também o motivo pelo qual estamos pulando as versões 5 e 6 e passando diretamente para o AGP 7.0.0. Esse alinhamento indica que o AGP 7.x deve funcionar com as APIs do Gradle 7.x. Embora ele também possa ser executado no Gradle 8.x, isso não é garantido e dependerá da remoção, na versão 8.x, de APIs das quais o AGP depende.
Com essa mudança, o número da versão do AGP será dissociado do número da versão do Android Studio. No entanto, continuaremos lançando o Android Studio e o plug-in do Android para Gradle juntos, por enquanto.
A compatibilidade entre o Android Studio e o plug-in do Android para Gradle continua inalterada. Como regra geral, os projetos que usam versões estáveis do AGP podem ser abertos com versões mais recentes do Android Studio.
Ainda é possível usar a linguagem de programação Java versão 8 com o AGP 7.0.0-alpha01, mas estamos mudando a versão mínima exigida da linguagem de programação Java para o Java 11, a partir do AGP 7.0.0-alpha02. Estamos anunciando isso logo no início da programação da versão Canário e muitos meses antes da versão estável para que os desenvolvedores tenham tempo para se prepararem.
Essa versão do AGP também introduz algumas mudanças em APIs. Como lembrete, várias APIs que foram introduzidas no AGP 4.1 foram marcadas como em incubação e estavam sujeitas a mudanças. Na verdade, no AGP 4.2, algumas dessas APIs foram modificadas. As APIs atualmente em incubação não seguem o ciclo de suspensão de uso que explicamos acima.
Segue um resumo de algumas mudanças importantes nas APIs.
Vamos dar uma olhada em algumas dessas mudanças. Segue uma amostra de bloco onVariants direcionada ao build de lançamento. O bloco onVariants é alterado para beforeVariants e usa um seletor de variante neste exemplo.
```
android {
…
//onVariants.withName("release") {
// ...
//}
}
androidComponents {
val release = selector().withBuildType(“release”)
beforeVariants(release) { variant ->
...
Da mesma forma, o bloco onVariantProperties é alterado para onVariants.
//onVariantProperties {
androidComponents.onVariants { variant ->
Observe que essa personalização geralmente é feita em um plug-in e não deve ser posicionada em build.gradle. Estamos deixando de usar funções com receptores, que eram adequadas à sintaxe do DSL, mas não são necessárias no código do plug-in.
Planejamos tornar essas APIs estáveis com o AGP 7.0.0, e todos os autores de plug-ins devem migrar para o novo androidComponents. Se você quiser evitar ter que lidar com essas mudanças, use apenas APIs estáveis nos plug-ins e não dependa de APIs marcadas como em incubação.
Caso deseje saber mais sobre outras mudanças dessa versão, não deixe de dar uma olhada nas notas da versão.
Java é marca registrada da Oracle e/ou de suas afiliadas.
O plug-in Android Kotlin Extensions Gradle (não confundir com o Android KTX) foi lançado em 2017 e trouxe duas novas conveniências para o desenvolvimento no Android com o Kotlin:
Depois disso, lançamos a vinculação de visualizações para Android, uma biblioteca com suporte oficial altamente integrada ao conjunto de ferramentas de criação do Android e que fornece funcionalidade similar à das propriedades sintéticas do Kotlin. Apesar de continuarmos recomendando o Parcelize, várias desvantagens surgiram com o uso das propriedades sintéticas do Kotlin:
A JetBrains é a desenvolvedora original do plug-in Android Kotlin Extensions e, junto com eles, discutimos os prós e contras de continuarmos mantendo as propriedades sintéticas: sempre que possível, nos esforçamos para garantir o suporte de longo prazo a APIs, mas queremos orientar os desenvolvedores para práticas recomendadas que permitam bases de código saudáveis e, consequentemente, usuários satisfeitos.
Ao longo do próximo ano, nossas equipes, em conjunto, suspenderão o uso das propriedades sintéticas de forma a continuar dando suporte à nossa opção recomendada, a vinculação de visualizações. Veja o que isso significa:
O período de suspensão começa com o Kotlin 1.4.20, lançado hoje. O android-kotlin-extensions continuará a existir por pelo menos um ano, mas será removido em uma versão futura do Kotlin, durante ou depois de setembro de 2021. No longo prazo, continuaremos mantendo o plug-in kotlin-parcelize, e você poderá continuar registrando problemas relacionados ao Parcelize no Rastreador de problemas do Android Studio.
O público-alvo de um app pode ser dividido em três grupos básicos: os não engajados (atraídos pela estratégia de aquisição), os que se tornam mais engajados (encorajados pela estratégia de retenção) e os que se tornam menos engajados (redirecionados pela estratégia de desligamento de usuários). Uma vez que todos eles envolvem diferentes estratégias, faz sentido pensar em aquisição, retenção e desligamento de usuários como áreas totalmente diferentes, embora o combate ao desligamento de usuários seja, muitas vezes, negligenciado por ser visto como mitigado pelo aumento da aquisição ou solucionado pelo aumento da retenção de usuários engajados.
Em um artigo anterior [LINK], discutimos como os desenvolvedores podem configurar uma estratégia de retenção eficaz visando aumentar a probabilidade de reter usuários engajados (confira também o relatório completo, que apresenta um detalhamento maior). Mas, não importa o quanto a estratégia e o app sejam bons, alguns dos usuários acabarão sendo desligados.
O desligamento de um usuário está associado a uma perda para as empresas que vai além da perda óbvia de potencial de receita. Se o desligamento for precoce, o custo de aquisição do usuário será totalmente perdido e, embora seja possível reengajar um usuário desligado, isso pode ser mais caro e demorado do que adquirir um novo.
Como resultado, em vez de tentar reengajar um usuário - o que envolve superar diretamente todos os problemas que levaram ao desligamento - é muito melhor ver se algo pode ser feito antecipadamente para impedir que ele se desligue.
Como agir antes que seja tarde demais?
Evitar o desligamento de usuários significa agir antes que isso aconteça, criando um sistema de aviso que permita identificar os sinais de desligamento e agir antes da ocorrência. Os usuários não se desengajam do dia para a noite. Antes do desligamento, a maneira como eles interagem com o app começa a mudar de formas identificáveis e mensuráveis. Para identificar esses alertas vermelhos, veja nos próprios dados quais comportamentos são demonstrados por usuários que se desligam:
O Quickbooks usa modelagem detalhada para desconstruir os comportamentos dos usuários recentemente desligados. Eles criam "perfis de risco dos usuários" que destacam quais comportamentos estão correlacionados à alta probabilidade de desligamento.
Esses perfis consistem em 200 a 300 comportamentos diferentes no app, incluindo falta de interação com recursos, número de dias de inatividade e não atingimento da métrica estrela-guia. Para saber como definir essa métrica, confira este artigo.
A realização desses "post-mortems" permite ao Quickbooks intervir imediatamente com retoques personalizados de comportamentos desejáveis, reduzindo o risco de desligamento dos usuários.
Depois de criar indicadores de desligamento de usuários, você pode identificar usuários em risco e ajudá-los a se reconectar ao app. O usuário precisa voltar a enxergar o valor do app. Isso pode ser reforçado por meio de lembretes úteis dos recursos aos quais eles já tinham acesso ou gerando empolgação com lançamentos futuros.
Uma das formas de se fazer isso é lembrar aos usuários o que eles já conquistaram com a ajuda do app. O Yazio garante continuamente que o progresso dos usuários seja rastreado de forma visível e celebrado com regularidade, como uma medida para evitar o desligamento. Eles utilizam barras de progresso e telas comemorativas para motivar os usuários a continuar atingindo suas metas.
Não deixe de personalizar o conteúdo o máximo possível para que o usuário se sinta valorizado. O Mobills envia mensagens adaptadas aos usuários com engajamento reduzido, oferecendo presentes e mensagens encorajadoras.
O Lifesum também envia mensagens adaptadas. No entanto, eles destacam o que o usuário pode estar perdendo. Eles se concentram nos lembretes de recursos-chave e no destaque de recursos menos conhecidos que podem convencer o usuário a manter o engajamento.
Se o app utilizar um modelo de assinatura, a janela de renovação é sempre um risco em potencial. O mais importante aqui é agir com base nos sinais certos, no momento certo. Para isso, identifique comportamentos que indicam o desligamento de usuários nas semanas ou nos meses antes do final da assinatura e em que momento eles ocorrem. Você talvez encontre sinais antes do que esperava.
Além disso, não deixe de oferecer outras opções além do cancelamento e comunique-as claramente aos usuários. Eles talvez simplesmente não saibam que existem opções mais acessíveis, de baixo contato ou baseadas em anúncios. Não dê aos usuários motivos para cancelamento!
Ao comunicar ofertas, considere o reenquadramento do valor. A renovação pode ser um assunto delicado. Pode ser necessário testar diferentes mensagens para saber o que funciona melhor com os usuários. Uma mensagem direta sobre os custos, benefícios e opções pode fazer com que o usuário se sinta com mais poder. A comparação do custo com equivalentes do mundo real pode dar alguma perspectiva - o Yazio mostra que o custo mensal de sua assinatura é menor que o de uma xícara de café por dia e do que alguns produtos alimentícios.
E, como sempre, as mensagens personalizadas fazem com que o usuário se sinta valorizado. Durante o fluxo de cancelamento, o Quickbooks mostra o que o usuário já conquistou por meio do app (por exemplo, o controle de 1.000 milhas) e destaca os recursos que estavam sendo pagos, mas que ainda não foram utilizados.
Ao longo das etapas acima, você talvez descubra padrões diferentes de comportamento que levam ao desligamento de usuários e representam grupos de usuários distintos e suas barreiras. Para alguns desses grupos, o desligamento pode ser inevitável. Eles podem representar usuários que não compreendem a proposta de valor do app ou que simplesmente já não o acham útil. Concentre-se nos grupos de usuários que gerarão valor para você em vez de naqueles que você identificar como tendo níveis baixos de atividade, apesar de vários esforços de reengajamento. Lembre-se de que é impossível erradicar completamente o desligamento de usuários.
Esperamos que este artigo ajude você a configurar uma estratégia de minimização do desligamento de usuários. As táticas acima são ferramentas úteis para manter engajados os usuários que estão "em cima do muro" - uma parte essencial do crescimento sustentável de um app - e também para uma estratégia de aquisição e retenção. Para obter mais informações sobre esses tópicos, consulte os recursos abaixo:
Este é o Now in Android, seu guia atualizado de novidades e fatos importantes do mundo de desenvolvimento no Android.
A série MAD Skills continua rolando, com conteúdo técnico sobre Modern Android Development. Wojtek Kaliciński e Ben Weiss postaram alguns episódios na segunda série sobre App Bundles. Até agora, vimos conteúdo sobre assinatura de apps do Google Play, como criar seu primeiro App Bundle e entrega de recursos do Google Play. Confira os vídeos e artigos abaixo para saber mais.
Em uma série sobre Android App Bundles, é natural falar sobre assinatura de apps, porque o Google Play gera APKs para download nos dispositivos dos usuários, e esses APKs precisam ser assinados para que possam ser instalados. Este vídeo fala sobre as etapas para ativar a assinatura de um app no Play Console, incluindo opções para ter uma chave gerada pela Google ou fazer upload de uma chave própria.
Certifique-se de conferir o artigo relacionado de Wojtek, que fala das perguntas comuns sobre a assinatura de apps no Google Play:
Answers to common questions about App Signing by Google Play
O vídeo de Ben fala sobre as etapas da criação de um App Bundle, que pode ser feita no Android Studio ou pela linha de comando e sobre seu upload para o Play Console. Ele também mostra como usar as ferramentas do Play Console para explorar informações sobre o bundle carregado.
Este episódio mostra como usar o Android Studio para modularizar seu aplicativo e como selecionar módulos para download no momento da instalação (com condições opcionais que determinam se será feita a instalação ou não) ou sob demanda. Ben também fornece alguns detalhes sobre como usar as APIs para solicitar a instalação de módulos sob demanda.
Ou em formato de artigo:
Configuring your app for Play Feature Delivery
Neste episódio final, Wojtek explica como usar as ferramentas disponíveis para testar um bundle e os APKs resultantes, incluindo o bundletool para testes locais e também o Play Console para testes de uploads.
Há vários artigos e documentos vinculados na descrição do vídeo, portanto, não deixe de conferi-los para ter ainda mais informações sobre o tópico.
Fique ligado no conteúdo final sobre App Bundles, na próxima semana, quando teremos uma sessão de Perguntas e respostas ao vivo, na quinta-feira (um link de vídeo ao vivo do YouTube será exibido na playlist e faremos um tweet solicitando perguntas antes do evento).
Para ver o conteúdo atual, não deixe de conferir a playlist do MAD Skills no YouTube, os artigos no Medium ou esta página de destino útil, a qual fornece acesso a todo o conteúdo. A próxima série começa na semana que vem: fique ligado!
Dentre todas as versões Alfa, Beta e RC incrementais das bibliotecas do AndroidX, algumas versões estáveis importantes foram lançadas recentemente, e eu gostaria de falar sobre elas.
Não é sempre que falamos sobre o Kotlin. Mas, quando falamos, falamos muito. Vários artigos e vídeos sobre o Kotlin foram postados recentemente:
Florina Muntenescu adicionou mais um episódio da atual série Vocabulário do Kotlin, desta vez sobre as classes de dados do Kotlin. As classes de dados permitem criar facilmente uma estrutura para a manutenção de dados com menos código boilerplate, contando com o Kotlin para gerar automaticamente as funções equals() e hashCode() apropriadas. Você também tem a desestruturação das propriedades da classe sem a necessidade de configurações adicionais, juntamente com copy(). Como de costume nos episódios de Vocabulário do Kotlin, Florina explora o bytecode descompilado das classes de dados para explicar como tudo isso funciona nos bastidores.
Data classes — the classy way to hold data
Falando em Vocabulário do Kotlin, Murat Yener postou uma sequência de seu artigo anterior sobre o recurso delegate do Kotlin. Desta vez, ele discute dos delegates fornecidos pela biblioteca padrão do Kotlin: lazy, observable, vetoable e notNull.
Built-in Delegates
A resposta curta é… sim!
Mas, para dar uma explicação mais completa, Florina postou este artigo para responder a algumas das principais perguntas que recebemos dos desenvolvedores relacionadas ao investimento em treinamento e desenvolvimento no Kotlin. Ele inclui links para recursos de aprendizado importantes.
Devo aprender a usar o Kotlin para Android e outras Perguntas frequentes
Neste artigo, Florina discute alguns dos motivos pelos quais os apps Kotlin são menos propensos a erros do que aqueles que não são escritos em Kotlin. Ela fala sobre alguns apps e casos de uso específicos que corroboram essa afirmação, mas também discute alguns dos motivos pelos quais essa linguagem permite um código mais robusto, incluindo nulidade, hashCode() != equals() e muito mais. Confira a postagem para ver todos os detalhes.
Menos falhas e mais estabilidade com o Kotlin
Desde o último Now in Android, publicamos outro episódio do Android Developers Backstage. Confira no link abaixo ou acesse seu cliente de podcast favorito:
Romain Guy, Tor Norbye e eu conversamos com Colin White, da Instacart, sobre sua biblioteca de carregamento de imagens de código: Coil. Batemos um papo sobre carregamento de imagens, desempenho, código aberto e o uso do Kotlin e das corrotinas que compõem essa biblioteca criada inicialmente com o Kotlin.
Episódio 151: Image Loading with Coil
Isso é tudo, por enquanto. Não deixe de aprender sobre os App Bundles. Faça o download das últimas versões do AndroidX. Leia os mais recentes artigos sobre o Kotlin. Ouça o episódio mais recente do podcast do ADB. Em breve, voltaremos com a próxima atualização do universo dos desenvolvedores Android.
Para comemorar o Dia da Consciência Negra, conversamos com fundadores e desenvolvedores brasileiros de aplicativos, jogos e websites. Conheça as suas trajetórias no mundo da tecnologia e escute dicas e histórias.
Junte-se a nós para celebrar as histórias desses desenvolvedores, ou compartilhe a sua própria história usando #DevsDoBrasil. Você também pode experimentar alguns desses aplicativos, bem como outros criados por desenvolvedores negros, nesta coleção da Google Play Store
Vitor Eleotério, Rio de Janeiro (RJ), Engenheiro de Software do iFood, um aplicativo de entrega de comida no Brasil. Sempre gostou de tecnologia, mas os colegas costumavam zombar dele e desencorajá-lo. Vitor ouviu diversas vezes que seria um ótimo segurança por ser alto e forte. As pessoas diziam que TI era só para quem nasceu em berço de ouro. Com sua paixão e trabalho árduo, ele provou que todos estavam errados. Agora, ele quer motivar outras pessoas a também seguir seus sonhos.
Priscila Aparecida Ferreira Theodoro, São Paulo (SP), Engenheira de Software da Centauro, grande varejista de artigos esportivos no Brasil. Seu primeiro contato com tecnologia aconteceu enquanto trabalhava em uma instituição que ensina programação. Aos 38 anos, Priscila decidiu mudar completamente a carreira e aprendeu a programar. Ela agora ensina programação para mulheres, é mentora de jovens e está envolvida em um projeto de podcast para mulheres desenvolvedoras.
Marcos Pablo, Porto Alegre (RS), Cofundador e CTO da G4IT Solutions, uma plataforma que ajuda as empresas a gerenciar e automatizar o trabalho das equipes que trabalham na rua. Foi a mãe quem o encorajou a entrar no mundo da tecnologia quando ele estava no colégio. Aos 19 anos, Marcos já administrava uma pequena empresa de tecnologia.
Iago Silva Dos Santos, Salvador (BA), Cofundador & CEO do Trazfavela Delivery, uma plataforma para entregas de produtos. Ele queria ajudar sua comunidade, incluindo motoristas, varejistas e pessoas que queriam um acesso mais fácil aos produtos. A TrazFavela é uma das primeiras empresas a receber investimentos do Google Black Founders Fund no Brasil.
Tiago Santos, Araraquara (SP), Fundador e CEO do Husky, um aplicativo
para profissionais brasileiros receberem pagamentos internacionais. Como desenvolvedor de software que trabalha com clientes internacionais, Tiago experimentou em primeira mão como era difícil receber pagamentos no exterior. Com seu amigo Mauricio Carvalho, ele criou o aplicativo para que os profissionais possam se concentrar na carreira em vez de perderem tempo com tarefas burocráticas.
Ronaldo Valentino da Cruz, Londrina (PR), Cofundador & CEO da Oktagon, um estúdio de games que produz títulos e jogos independentes. Aprendeu a programar aos 14 anos e começou a trabalhar com desenvolvimento de jogos em 2002 na Universidade Federal Tecnológica do Paraná. A empresa já lançou títulos mid-core bem recebidos e trabalhou com publicadoras e clientes no mundo todo.
Nohoa Arcanjo Allgayer, São Paulo (SP), Cofundadora & CMO da Creators.LLC, uma rede que conecta talentos da indústria criativa com potenciais clientes. Para Nohoa, não foi uma decisão fácil abandonar seu confortável emprego corporativo para abrir esta startup. Agora ela está orgulhosa do risco que correu, pois isso abriu um mundo de oportunidades e aprendizados sem fim. Ela participou do Programa de Residência Google para Startups e a Creators.LLC foi uma das primeiras startups a receber capital do Google Black Founders Fund no Brasil.
Samuel Matias, Recife (PE), Engenheiro de Software do iFood. Ele se tornou um desenvolvedor em 2015 e é bastante ativo na comunidade Flutter. Samuel frequentemente compartilha seus aprendizados dando palestras e escrevendo artigos online.
Aline Bezzoco, Rio de Janeiro (RJ), Fundadora & Desenvolvedora do Tá tudo bem? - um aplicativo de prevenção do suicídio. Ela acredita que o melhor da tecnologia é a capacidade de criar soluções para ajudar as pessoas. Seu aplicativo ajuda aqueles que lutam com problemas de saúde mental a se sentirem mais calmos, menos ansiosos e a pedirem socorro.
Egio Arruda Junior, Goiânia (GO), Cofundador & CEO da EasyCrédito, uma plataforma que facilita empréstimos. O principal foco é ajudar quem ainda nem tem uma conta em banco. Egio é apaixonado por inovação e está sempre procurando criar algo novo. Participou de dois programas do Google for Startups (Residency e Accelerator).
Márcio Dos Santos, Seattle (EUA), Cofundador & CTO da Facio, uma plataforma de crédito
e educação financeira para colaboradores no Brasil. Entre amigos e familiares, não havia uma pessoa que tinha cursado o Ensino Superior. Márcio decidiu estudar Ciências da Computação por amar videogames. Um professor da Universidade o escolheu para fazer estágio nos Estados Unidos. Atualmente radicado em Seattle, nos Estados Unidos, Márcio gosta de ser procurado e ajudar quem está em início de carreira.
Danielle Monteiro, São Paulo (SP), Engenheira de Dados e Fundadora da Dani.Academy, uma plataforma educacional com cursos gratuitos e pagos sobre dados, arquitetura, NoSQL e infraestrutura. Ela foi a primeira da família a entrar e terminar uma faculdade. Já ganhou muitos prêmios dentro e fora do Brasil e é mentora do Google for Startups. Danielle é apaixonada por retribuir à sociedade compartilhando seus conhecimentos por meio do blog, palestras, cursos e artigos.
----
Essas são apenas algumas das histórias inspiradoras que mostram que o mundo da tecnologia não é para poucos, mas para todos. Juntos, podemos criar mudanças e ver mais pessoas negras encontrando oportunidades em tecnologia. Comemore essas histórias compartilhando esse vídeo: youtu.be/k5J-XamMhGI – youtu.be/k5J-XamMhGI
Se você disponibiliza imagens de contêineres públicos usando o Container Registry ou o Artifact Registry, está expondo o ID do projeto e outros detalhes aos usuários que fazem download dessas imagens. No entanto, ao escrever um pequeno middleware e executá-lo sem servidor, você pode personalizar a forma como seu registro funciona.
Neste artigo, quero mostrar como desenvolver e executar um proxy reverso sem servidor para personalizar o comportamento do registro, como para disponibilizar imagens publicamente em um domínio personalizado em vez de no gcr.io.
Disponibilizar imagens de contêiner a partir de um registro de contêiner não é nada de outro mundo. Todos os registros imagens de contêineres, como o Google Container Registry, o Google Artifact Registry ou o Docker Hub, implementam uma especificação de API aberta.
Portanto, quando você efetivamente executa um comando pull, como docker pull gcr.io/google-samples/hello:1.0, o mecanismo de contêiner subjacente (como o Docker Engine) faz algumas chamadas de API REST HTTP ao endpoint, como https://gcr.io/v2/google-samples/hello-app/manifests/1.0, para descobrir detalhes sobre essa imagem e fazer o download dos blobs de camadas. Você pode usar uma ferramenta como o crane para inspecionar mais a fundo como um registro de contêiner funciona ao tentar executar o pull ou push de uma imagem.
docker pull gcr.io/google-samples/hello:1.0
https://gcr.io/v2/google-samples/hello-app/manifests/1.0
Disponibilizar imagens em domínios personalizados é especialmente útil para imagens públicas, como projetos de código aberto. Isso também ajuda a ocultar dos usuários os detalhes do registro subjacente (como gcr.io/*).
Quando você utiliza um registro como o Container Registry ou o Artifact Registry para disponibilizar imagens publicamente, não só expõe os IDs do projeto ao mundo exterior, mas também acaba tendo nomes de imagens realmente longos:
docker pull us-central1-docker.pkg.dev/<project-id>/<registry-name>/<image-name>
No exemplo acima, é possível ver que o nome da imagem de contêiner determina onde está hospedado o registro e, portanto, a qual host são feitas as chamadas da API. Se você fosse criar um registro que disponibiliza imagens no domínio personalizado, como example.com, poderia executar o pull das imagens especificando example.com/IMAGE:TAG como a referência da imagem do contêiner. As solicitações da API, por sua vez, seriam feitas por proxy para o host real do registro.
example.com/IMAGE:TAG
Para criar essa experiência, basta usar o Google Container Registry ou o Artifact Registry existente para armazenar suas imagens e criar um “proxy reverso" por cima dele para encaminhar as solicitações recebidas, ainda disponibilizando o tráfego no nome de domínio personalizado de sua propriedade.
O Cloud Run é uma ótima opção para hospedar um aplicativo como esse no Google Cloud. O Cloud Run é uma plataforma de hospedagem de contêiner sem servidor, e seu preço é especialmente relevante neste caso, já que você só paga por cada solicitação atendida.
Nesse design, você seria cobrado apenas enquanto uma solicitação estivesse sendo atendida (ou seja, quando alguém estivesse recebendo uma imagem por pull), o que pode ser facilmente enquadrado na camada gratuita.
Quando você utiliza esse proxy com o Google Container Registry, não é feito o download das camadas de imagens reais (blobs) da API do registro (em vez disso, é gerado um link de download do Cloud Storage para o pull do tarball da camada). Uma vez que suas camadas, provavelmente com vários gigabytes, não passam por esse proxy, é fácil manter o controle dos custos no Cloud Run.
No entanto, quando isso é utilizado com o Artifact Registry, uma vez que os blobs de camadas da imagem são disponibilizados por meio desse proxy, o custo será mais alto devido às taxas de rede de saída para disponibilizar os blobs maiores e ao “tempo faturável" mais longo no Cloud Run, como resultado do uso do proxy para as respostas maiores durante uma solicitação.
Para realizar essa tarefa, criei um proxy reverso simples utilizando a linguagem de programação Go em cerca de 200 linhas de código. Esse proxy usa o httputil.ReverseProxy e adiciona um tratamento especial à negociação de credenciais para disponibilizar as imagens públicas (e as imagens privadas publicamente, se necessário).
O código de exemplo e as instruções de implantação podem ser encontrados em meu repositório, github.com/ahmetb/serverless-registry-proxy. Para implantar esse proxy no projeto a fim de disponibilizar imagens públicas em um domínio personalizado, consulte o repositório para ter instruções passo a passo. Resumidamente, você precisa:
<YOUR-DOMAIN>/<IMAGE>:<TAG>
Você pode estender a ideia de criar “proxies de middleware" à frente do registro do contêiner e hospedá-los de forma mais econômica em uma plataforma sem servidor, como o Cloud Run, com custos mínimos.
Por exemplo, você pode criar um proxy de registro que disponibilize apenas determinadas imagens ou tags. Da mesma forma, pode criar sua própria camada de autenticação por cima de um registro existente. Como a API do registro é padrão, meu código de exemplo funciona também para outros registros de contêiner, como o Docker Hub. Assim, é possível hospedar um proxy sem servidor no Cloud Run que disponibiliza imagens do Docker Hub ou de qualquer outro registro.
Sinta-se à vontade para examinar o código-fonte e mexer no projeto para estendê-lo de acordo com suas necessidades. Espero que este exemplo de projeto de código aberto também possa ajudar você a disponibilizar um registro de contêiner em um domínio personalizado.
Artigo relacionado
Imagens de contêiner podem ser criadas por meio de uma variedade de métodos, incluindo Buildpacks, Jib e Dockerfiles. Vamos compará-los.
Há pouco mais de três semanas, realizamos nosso primeiro AMP Fest, onde nos reunimos on-line como uma comunidade para compartilhar o que há de mais recente e melhor no mundo do AMP. Desde o lançamento do novo AMP Page Experience Guide até o excelente novo suporte a clientes ao AMP for Email, o AMP Fest apresentou vários desenvolvimentos incríveis em todo o ecossistema do AMP.
Continue lendo para relembrar o AMP Fest e saber tudo sobre as notícias que você pode ter perdido:
Uma das atualizações mais empolgantes do AMP Fest foi o trabalho de criação de ótimas experiências na página. O AMP foi elaborado para ajudar a promover o desenvolvimento de sites voltados para os usuários, e nós acreditamos que o AMP é uma solução econômica e simples para que os editores possam criar uma ótima experiência na página. Alinhados a isso, compartilhamos que 60% dos domínios AMP são aprovados* pelas métricas do Core Web Vitals, em comparação com 12% dos domínios não AMP, segundo os mesmos critérios.
* “aprovação” significa que 75% das páginas de um domínio foram aprovadas segundo as métricas do Core Web Vitals.
Para ajudar a atingir nossa meta de fazer com que todas as páginas do AMP sejam aprovadas nessas métricas, também lançamos o AMP Page Experience Guide, uma nova ferramenta que fornece aos desenvolvedores AMP feedback prático específico ao AMP sobre como melhorar o desempenho de páginas do AMP. Isso garante que, se uma página do AMP não atender aos sinais de experiência na página, nós podemos fornecer feedback prático ou suporte pessoal como um último recurso para ajudar a resolver problemas de desempenho.
Este ano, anunciamos que estávamos fazendo a transição do nome AMP Stories para Web Stories, devido à expansão do universo de criadores e consumidores que estão desfrutando do formato por meio de ferramentas #nocode. Desde o anúncio, vimos que o formato continua sendo adotado por editores e também pelo Web Creators.
Aproveitando esse momento, anunciamos novas atualizações do formato Web Stories, incluindo a funcionalidade personalizável de testes e sondagens, integração de vídeos em 360 e a capacidade de incorporar o Web Stories diretamente a um site com um Story Player de código aberto completo. Isso segue o recente anúncio da equipe do Web Stories na Google, de que o Web Stories está chegando ao Discover, que faz parte do Google app no Android e no iOS e é utilizado por mais de 800 milhões de pessoas todos os meses.
O AMP for Email já está comercialmente disponível há mais de um ano e meio, e continua sendo uma surpresa ver novos casos de uso para o e-mail dinâmico surgindo todos os dias. No AMP Fest, anunciamos que a Verizon Media (Yahoo Mail) lançou sua prévia para desenvolvedores para o AMP e que os e-mails AMP estarão no Salesforce Marketing Cloud no primeiro trimestre de 2021. Estamos muito felizes por ajudar a levar o e-mail dinâmico a milhões de novos usuários.
Os tipos de experiências que os remetentes do AMP for Email proporcionam a seus clientes nos inspiraram e encantaram totalmente e, no AMP Fest, destacamos vários remetentes que estão usando os e-mails AMP para ajudar seus clientes e consumidores a poupar tempo e dinheiro. Assista à palestra abaixo para ver os resultados impressionantes que os e-mails dinâmicos estão gerando para todos os tipos de remetentes de e-mail:
Com tantas ótimas notícias recebidas no evento, foi muito bom poder contar com desenvolvedores AMP e proprietários de sites de todo o mundo que compartilharam suas histórias de implementação do AMP e dicas sobre como tirar o máximo proveito do AMP.
Violeta Rosales, gerente de engenharia de software da Uno TV, nos mostrou como o outlet de notícias digital fez a transição de seu site para ser “AMP First”, além dos benefícios e desafios enfrentados pela Uno TV nessa transição.
Yosuke Furukawa, engenheiro de software sênior da Recruit, nos mostrou dicas para criar um site “AMP First” e falou sobre tópicos relacionados a bibliotecas, como Next.js, e também estratégias operacionais, como o AMP fora do cache.
Antonio González de León, CTO da Televisa Digital, compartilhou lições sobre a transição da Televisa para “AMP First”, além de outras lições que os editores e desenvolvedores iniciantes podem aprender com veteranos do setor de mídia.
Thomas Feldhaus, diretor executivo da JvM TECH, falou sobre como o AMP ajuda as agências a acelerar o processo de produção de seus sites para clientes e ainda a garantir uma qualidade de execução consistentemente alta.
E, por fim, Jason Caldwell, líder de engenharia de expansão da Automattic, compartilhou como a mudança para o “AMP First” ajudou o WordPress.com a elevar as taxas de conversão, reduzir os custos de aquisição e melhorar o desempenho de suas principais páginas de destino.
Houve muitas palestras incríveis que não pudemos destacar neste resumo. Então, não deixe de conferir a playlist do evento para assistir a todas elas novamente e relembrar esse momento incrível. Queremos agradecer a todos que nos ajudaram a fazer desse evento um grande sucesso. O AMP evoluiu muito desde sua introdução, cinco anos atrás, e estamos mais empolgados do que nunca com o brilhante futuro do AMP!
Postado por Alex Durán, marketing de projeto do AMP na Google
