Tornando o Firebase Serverless – aplicativos móveis e da Web facilitados

Os aplicativos móveis e da Web geralmente exigem um servidor de back-end. Os aplicativos da Web exigem um servidor da Web para fornecer conteúdo. Os aplicativos também precisam armazenar perfis de usuário e mídia, como imagens e vídeos. A comunicação entre o aplicativo e o servidor geralmente é feita usando uma API, que geralmente é REST.

Os aplicativos são codificados em uma variedade de idiomas. Um aplicativo iOS é escrito em Swift ou Objective-C. Os aplicativos Android são escritos em Java ou Kotlin. Os aplicativos da Web são escritos em HTML, CSS, JavaScript e muitas vezes estruturas complexas, como Angular ou React. Os desenvolvedores front-end precisam conhecer as linguagens relevantes e suas ferramentas de desenvolvimento associadas.

Os servidores de back-end são escritos em uma variedade de linguagens, incluindo Go, Java, PHP e Python. Cada uma dessas linguagens tem seu próprio conjunto de bibliotecas para facilitar a escrita de aplicativos complexos.

A maioria dos desenvolvedores se considera desenvolvedores front-end ou back-end. Desenvolvedores full-stack que são proficientes em ambas as funções são relativamente raros.

A execução e manutenção de um servidor back-end tem seus próprios desafios. Os servidores precisam ser construídos, atualizados e submetidos a backup. Os servidores também precisam ser protegidos para evitar perda acidental ou mal-intencionada de dados ou acesso a dados confidenciais. Além disso, os servidores precisam ter nomes de host e endereços IP atribuídos para que possam ser conectados.

O que é Firebase?

O Firebase começou como uma arquitetura de mensagens móveis que foi adquirida pelo Google. Desde então, evoluiu para ser um conjunto de mais de 25 componentes que interoperam com o Google Cloud Platform.

O Firebase consiste em kits de desenvolvimento de software (SDKs), que permitem que desenvolvedores de dispositivos móveis e da Web acessem a funcionalidade da nuvem de maneira simples, segura e confiável. Eles compensam automaticamente a conectividade de rede ruim. Há um console da Web do Firebase para ativar, administrar e proteger componentes. Há também ferramentas de linha de comando e APIs REST para uso mais aprofundado.

Alguns componentes do Firebase são mais conhecidos que outros. Existem poucas dependências entre os componentes, o que permite a adoção incremental da funcionalidade. A autenticação e a análise do Firebase são as mais usadas.

O Firebase evoluiu para se tornar uma plataforma que permite que desenvolvedores de front-end para dispositivos móveis e web desenvolvam aplicativos completos sem a necessidade de servidores de back-end. Aprimoramentos recentes facilitaram muito as soluções sem servidor que fornecem uma alternativa viável, escalável e econômica às soluções de servidor de máquina virtual em nuvem.

Planos de preços e faturamento do Firebase

O plano de faturamento básico do Firebase, chamado Spark, é gratuito. Existem limites para o uso de recursos da nuvem, mas eles são bastante generosos. É possível executar um aplicativo de tamanho razoável sem incorrer em cobranças.

Um site com conteúdo de até 1 GB e transferências de menos de 10 GB/mês pode ser hospedado no plano Spark. O Firestore permite até 1 GB de dados e tráfego de rede de até 10 GB/mês. Os limites de armazenamento em nuvem são de até 5 GB de dados e downloads de até 1 GB/dia.

Se o aplicativo precisar de mais recursos, será necessário um plano de cobrança pago, como o pagamento conforme o uso. Os limites gratuitos do plano Spark ainda se aplicam. Os encargos faturáveis ​​são bastante baixos. Os preços podem ser encontrados na página de preços do Firebase.

As máquinas virtuais executadas na nuvem incorrem em cobranças enquanto estão em execução, mesmo que não estejam sendo usadas. As soluções sem servidor do Firebase são dimensionadas para zero. Isso significa que os recursos são efetivamente executados apenas quando em uso e não incorrem em cobranças quando não estão em uso. Isso é ideal para aplicações para negócios sazonais, como aluguel de temporada ou eventos periódicos, como shows. Haveria muita atividade seguida de meses de inatividade.

Como configurar o Firebase

Uma conta de e-mail é necessária para autenticação. Uma conta de e-mail do Google é preferível. Eles podem ser criados em https://mail.google.com.

Uma conta do Google Cloud Platform (GCP) também é necessária. Um teste gratuito está disponível aqui. Isso lhe dá crédito de $ 300, que está disponível por um ano. É necessário um cartão de crédito como prova de identidade. O Google pode cobrar US$ 1 e depois reembolsá-lo. O cartão de crédito será debitado mensalmente se o faturamento estiver ativado e os recursos faturáveis ​​forem usados. Existem também empresas provedoras do Google que atuam como intermediárias para cobrança. Você paga ao provedor pelo uso da nuvem e ele paga ao Google. Eles têm seus próprios planos de cobrança e podem oferecer uma avaliação gratuita.

É importante monitorar a seção de cobrança do console de nuvem com frequência para monitorar o uso. É fácil manter recursos como armazenamento ativos quando não são necessários, o que pode gerar custos consideráveis ​​ao longo do tempo.

Os projetos do Firebase também são projetos do GCP. Você pode criar um projeto do GCP e importá-lo para o Firebase ou criar um projeto do Firebase, que também criará um projeto do GCP. O console do Firebase está aqui.

Uma configuração diferente é necessária para diferentes tipos de aplicativos. Os principais são Android, iOS e aplicativos da web. As instruções de configuração podem ser encontradas nos Guias oficiais do Firebase.

As ferramentas do Firebase Command Line Interface (CLI) são necessárias para algumas operações. Eles exigem que o Node.js e a ferramenta npm estejam instalados. Se estiver executando no macOS ou Linux, o comando npm precisará ser executado com sudo .

sudo npm install -g firebase-tools

Autenticação e autorização

A autenticação Firebase é talvez o componente Firebase mais usado. Os usuários podem selecionar um ou mais mecanismos de autenticação. São endereços de e-mail e senha, números de telefone e provedores de identidade federada Google, Facebook, Twitter e GitHub. Qualquer número de mecanismos de autenticação pode ser ativado.

A IU do Firebase solicita ao usuário o mecanismo a ser usado:

O Firebase fornece interfaces de usuário para autenticação que podem ser invocadas a partir de algumas linhas de código no lado do cliente. Existem também APIs para fazer a autenticação manualmente. Na autenticação bem-sucedida, é gerado um token de identidade que pode ser usado para validação de back-end.

As APIs permitem que os usuários administrativos gerenciem usuários programaticamente. As operações incluem:

• Criando, atualizando e excluindo usuários
• Procure usuários por critérios de pesquisa, como endereço de e-mail ou número de telefone
• Acesse informações como data de criação da conta e data e hora do último login
• Valide endereços de e-mail e números de telefone sem precisar usar os fluxos de trabalho existentes

A maioria dos aplicativos móveis e da Web deseja que um grande número de usuários faça login em seus aplicativos. Por exemplo, qualquer pessoa com uma conta do Google Mail pode se autenticar em qualquer aplicativo que permita a autenticação do Google. É necessária uma forma de autorização para restringir o acesso ao aplicativo a determinados usuários. Isso pode ser feito facilmente armazenando associações entre endereços de e-mail e funções de acesso no armazenamento de dados. Na autenticação bem-sucedida, o endereço de e-mail é pesquisado no armazenamento de dados. Se o usuário existir com as funções corretas, o acesso será concedido; caso contrário, o usuário será desconectado à força.

Hospedagem Firebase

A hospedagem do Firebase permite que o conteúdo da Web estático, que inclui JavaScript, seja hospedado na nuvem sem a necessidade de um servidor da Web. O conteúdo é armazenado em cache nas bordas de uma Rede de Entrega de Conteúdo (CDN) global. Isso permite acesso rápido ao conteúdo de qualquer lugar do mundo.

Um ou mais sites podem ser hospedados adicionando-os à seção Hosting de um projeto do Firebase no Firebase Console. O conteúdo é entregue por SSL e recebe dois URLs no formato [https://site-name.web.app] e https://site-name.firebaseapp.com, em que site-name é o nome do projeto ou um nome do site especificado pelo usuário.

É muito fácil ter o site hospedado a partir do seu próprio nome de domínio, desde que você possa alterar os registros DNS do domínio. Você adiciona seu nome de domínio a um site no Firebase Console. Em seguida, você receberá um registro DNS TXT, que deve ser adicionado ao DNS do seu domínio para provar ao Google que você é o proprietário do domínio. Assim que o registro TXT estiver visível, você poderá obter registros DNS A para o site. Um certificado SSL é provisionado automaticamente para o site. Depois que o certificado for provisionado, o site estará disponível globalmente. Em princípio, pode levar várias horas para atualizações de DNS e provisionamento de certificados. Na prática, o processo pode ser concluído em 20 minutos.

Para adicionar conteúdo à hospedagem, primeiro crie um diretório para o site e cd nele a partir da linha de comando. Em seguida, faça login no Firebase e inicialize o diretório do projeto.

 firebase login firebase init

Você será solicitado a selecionar um projeto e quais serviços ao cliente são necessários. Os serviços sempre podem ser adicionados posteriormente e não precisam ser selecionados nesta fase.

Crie um arquivo chamado firebase.json , que define o diretório raiz do site e os arquivos a serem excluídos. Você também precisará de um arquivo .gitignore para excluir arquivos do controle de versão.

 { "hosting": { "public": "public", "ignore": [ "firebase.json", "**/.*", "**/node_modules/**" ] } }

Em seguida, copie o conteúdo estático no diretório público. Por fim, implante o site na nuvem.

 firebase deploy

Para alterar o conteúdo da web, basta alterar os arquivos de conteúdo e emitir o comando deploy. Cada implantação aparece como uma versão no Firebase Console. Você pode reverter para uma versão anterior com um único clique.

O Firebase Hosting também pode reescrever URIs em arquivos, Cloud Functions e Cloud Run. Isso simplifica muito as coisas, pois não é necessário atribuir um domínio a esses serviços. As regravações são definidas adicionando uma seção de regravações à seção de hospedagem do firebase.json. A implantação de hospedagem falhará se o serviço não existir.

 { "hosting": { "public": "public", "rewrites": [ { "source": "/xxx", "destination": "/profile.html" }, { "source": "/yyy", "function": "profile" }, { "source": "/api{,/**}", "run": { "serviceId": "cloud-api", "region": "europe-west1" } } ] } }

Armazenamento de dados

O Firebase fornece APIs de cliente para acessar o armazenamento de dados baseado em nuvem. Existem três tipos de armazenamento:

• Banco de dados em tempo real
• Cloud Firestore
• Armazenamento na núvem

Isso permite que clientes móveis e da Web armazenem e recuperem dados sem a necessidade de um servidor.

Banco de dados em tempo real

O Realtime Database é um banco de dados NoSQL hospedado na nuvem. Os dados no Realtime Database são sincronizados automaticamente em tempo real para todos os dispositivos conectados. Funciona em várias plataformas para Android, iOS e web. Os dados são armazenados como uma estrutura de árvore JSON. As regras de segurança podem ser definidas para controlar o acesso de leitura e gravação aos dados.

Cada dispositivo mantém uma cópia local do banco de dados. Isso significa que os dados estão disponíveis quando não estão conectados à rede. Na reconexão, as cópias locais e baseadas em nuvem dos dados são sincronizadas.

Os dados são lidos por aplicativos usando um ouvinte. Um ouvinte escuta em um nó na árvore JSON. Sempre que os dados são alterados no console ou por outro usuário, o retorno de chamada do ouvinte é chamado com o novo valor de dados. O Realtime Database também oferece suporte a consultas. Cada consulta retorna um nó e todos os seus nós filhos.

As regras de segurança por padrão não permitem acesso aos dados. As regras podem ser adicionadas globalmente ou a nós individuais do objeto JSON. As regras de segurança controlam o acesso de leitura e gravação aos dados e podem realizar a validação.

O Realtime Database é mais adequado para pequenos pedaços de dados que não exigem uma estrutura de dados profundamente aninhada. O limite gratuito é de 1 GB de dados.

Cloud Firestore

O Cloud Firestore é visto como o substituto do Realtime Database. Ele estende a funcionalidade do Realtime Database. Os dados não estão em uma árvore JSON, mas em uma coleção hierárquica de documentos. Cada documento consiste em um conjunto de pares chave-valor e subdocumentos opcionais. As consultas permitem filtragem e classificação mais complexas e retornam apenas documentos completos. As consultas não retornam subdocumentos.

O Cloud Firestore substituirá em breve o Cloud Datastore. Ele pode ser executado no modo Datastore ou no modo nativo. Todos os aplicativos do Datastore serão migrados automaticamente para o Cloud Firestore.

O Cloud Firestore é mais adequado para dados relativamente pequenos. Ele pode ter uma estrutura de dados profundamente aninhada. O limite gratuito é de 1 GB de dados.

Armazenamento na núvem

O Cloud Storage serve para armazenar arquivos como imagens e videoclipes. Os clientes móveis e da Web podem usar o Firebase para fazer upload e download de arquivos diretamente de e para a nuvem sem a necessidade de um servidor de back-end. O limite gratuito é de 5 GB de dados.

Funções de nuvem

O Cloud Functions é uma tecnologia importante para criar aplicativos sem servidor. Uma função de nuvem pode ser escrita em JavaScript, TypeScript, Python ou Go, que é implantada diretamente na nuvem do Google. Uma função é acionada por uma solicitação HTTP ou por um evento na nuvem, como gravação no Cloud Storage.

Uma Função de Nuvem só pode lidar com uma solicitação por vez, mas a nuvem dimensiona automaticamente a função replicando-a. Uma Função do Cloud escrita em Python usa a biblioteca Flask para processar solicitações HTTP. A função recebe um objeto de solicitação como parâmetro e retorna o corpo da resposta.

Um simples Python Cloud Function requer um diretório de trabalho e o ponto de entrada vai no arquivo main.py .

 def simple_cloud_function(request): return "It worked"

As dependências são gerenciadas pelo pip e vão para um arquivo chamado requirements.txt .

 Flask==1.0.2

Uma função é implantada usando a ferramenta de linha de comando gcloud . Ele especifica o nome da função, o idioma e o gatilho.

 gcloud functions deploy simple_cloud_function --runtime python37 \ --trigger-http

A URL da função é exibida na implementação e pode ser encontrada executando o comando describe.

 gcloud functions describe simple_cloud_function Url: https://europe-west1-project-id.cloudfunctions.net/simplecloud_function

O Cloud Functions pode chamar as APIs do Google Cloud e do Firebase para fornecer funcionalidade de back-end. Eles fornecem informações de log sobre a inicialização da execução e o tempo de execução. Logs adicionais podem ser facilmente adicionados. Os registros podem ser visualizados na IU do Stackdriver Logging e por meio da ferramenta de linha de comando gcloud .

 gcloud functions logs read simple_cloud_function

As funções podem ser visualizadas e excluídas no Console do Google Cloud.

O Cloud Functions é melhor usado para operações que ocorrem com pouca frequência. Um exemplo de uso é criar uma miniatura quando uma imagem é carregada no Cloud Storage. O limite gratuito é de 125.000 invocações por mês.

Cloud Run

O Cloud Run é uma funcionalidade adicionada recentemente que facilita muito os aplicativos sem servidor. Ele permite que os contêineres do Docker sejam executados na nuvem sem precisar fazer uma configuração de infraestrutura complexa. Ele pode ser executado no modo gerenciado, que usa o tempo de execução Knative, que é construído no Kubernetes. Ele também pode ser executado no Anthos, que também é construído no Kubernetes, mas permite que os contêineres sejam executados em nuvens e até mesmo em seu próprio data center. Não há necessidade de configurar e gerenciar um cluster Kubernetes, pois tudo é feito automaticamente.

Qualquer aplicativo que possa ser integrado a imagens do Docker pode ser gerenciado pelo Cloud Run. Ele dimensiona automaticamente o número de contêineres com base na demanda. Ele também é reduzido para zero quando o serviço não está sendo usado. Os serviços não utilizados não são cobrados.

Os contêineres do Docker precisam executar um servidor da Web para responder a solicitações HTTP. O serviço Python usará o Flask. O ponto de entrada estará em app.py .

 from flask import Flask, request app = Flask(__name__) @app.route('/api/profile') def profile(): page = ''' Page content ''' return page

O aplicativo precisa de um Dockerfile para criar a imagem.

 FROM python ENV APP_HOME /app WORKDIR $APP_HOME COPY . . ENV PORT 8080 RUN pip install Flask gunicorn firebase-admin CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 app:app

Os contêineres do Cloud Run são implantados diretamente na nuvem.

 gcloud run deploy --image=image_name --platform=managed \ --region=europe-west1 --allow-unauthenticated

Se o nome do serviço, a plataforma, a região ou a permissão não autenticada não estiverem definidos na configuração do projeto ou fornecidos na linha de comando, eles serão solicitados. Quando a implantação for concluída, a URL do serviço será exibida. O URL também pode ser obtido usando o comando gcloud.

 gcloud run services list SERVICE REGION URL LAST DEPLOYED BY LAST DEPLOYED AT cloud-api europe-west1 https://cloud-api-h42ifbxkyq-ew.a.run.app [email protected] 2020-02-05T10:53:30.006Z

A URL contém um número aleatório difícil de gerenciar. É aqui que as regras de reescrita do Firebase Hosting se tornam mais úteis.

Os serviços podem ser visualizados e excluídos no Console do Google Cloud.

O Cloud Run é ideal para hospedar uma API REST. Os limites gratuitos mensais são 180.000 segundos de CPU, 360.000 GB de segundos de memória, 2 milhões de solicitações e 1 GB de saída de rede. O limite de saída de rede gratuita só se aplica se o serviço for implantado em uma região da América do Norte.

Autenticação

Por padrão, os contêineres do Cloud Functions e do Cloud Run são públicos e podem ser acessados ​​por qualquer pessoa na Internet. Usando as regras do IAM no Console do Cloud, os serviços podem ser restritos a membros do projeto, Grupos do Google e endereços de e-mail individuais.

Se houver restrições, o acesso não autorizado é proibido. Para habilitar o acesso, um token de identidade deve ser adicionado aos cabeçalhos da solicitação. O token de identidade pode ser obtido usando o comando gcloud ou durante o processo de autenticação do Firebase.

 gcloud auth print-identity-token

Um cabeçalho de autorização é necessário.

 Authorization: Bearer id-token

Resumo

O Google Cloud Platform e o Firebase oferecem uma variedade de produtos que facilitam muito o desenvolvimento de aplicativos móveis e da Web. A necessidade de um servidor de back-end pode ser completamente eliminada, permitindo que os clientes acessem a funcionalidade da nuvem diretamente ou implantando o código de back-end na nuvem usando o Cloud Functions ou o Cloud Run.

Os aplicativos existentes podem ser migrados para serverless de forma incremental. Na verdade, a forma como a tecnologia está evoluindo pode significar que as soluções tradicionais de servidores baseados em máquinas virtuais não serão mais necessárias.