Mobile Back-End as a Service (MBaaS)
Uma comparação entre CloudKit e Firebase
Hoje em dia, desenvolvedores de aplicativos independentes e startups não conseguem ter especialistas back-end dedicados para manter tudo funcionando. Há uma incessante necessidade de desenvolver e testar rapidamente os apps para se adequarem ao mercado de produtos antes de investir em suas próprias infra-estruturas e serviços.
Para solucionar da melhor forma este obstáculo, surgiu o MBaaS (Mobile Back-End as a Service), uma plataforma fácil e rápida que provê serviços, os quais a maioria dos apps necessitam:
- Autenticação para identificar os consumidores
- Armazenamento de dados
- Serviços de notificação
Alguns MBaaS possuem também como diferencial funções de analytics e gerenciamento de anúncios.
Não faz muito tempo, há seis anos, os serviços necessários no desenvolvimento de aplicativos eram realizados através de soluções caseiras ou tecnologias de terceiros muito acima do orçamento disponível. Ocorreu uma aparente lacuna: como os desenvolvedores de apps podem desenvolver soluções rapidamente que possam tirar proveito dos recursos mais recentes em um dispositivo móvel e gerenciar comandos de serviço complexos? Foi assim que o MBaaS nasceu.
O MBaaS veio para oferecer um conjunto de soluções que permitem o rápido desenvolvimento de apps sofisticados. Não há necessidade de um desenvolvedor hospedar seu próprio servidor de notificação push, bancos de dados em nuvem em escala ou monitorar análises de aplicativos.
O primeiro líder nesse mercado foi a empresa Parse, no entanto o Facebook comprou em 2013 e acabou descontinuando o produto no começo de 2017. Atualmente, este mercado está mais dividido, sendo seus líderes: Google Firebase e Apple CloudKit, seguidos de Kinvey e Amazon Web Services (AWS) mas neste artigo iremos focar no Firebase e CloudKit.
A premissa do MBaaS é bem básica: dar aos desenvolvedores fácil acesso aos serviços de back-end, os quais serão reusados em uma variedade de aplicações. A ideia principal é que desenvolvedores não precisam reinventar a roda toda vez que vão desenvolver algum aplicativo, ou seja, não é necessário aprender todas as peculiaridades para trabalhar no servidor. Esta reciclagem e reuso de código e tecnologia resulta em menos tempo e dinheiro gastos no projeto. Por ser uma solução “as-a-service” é teoricamente fácil de implementar e as empresas e desenvolvedores precisam pagar apenas pelo que realmente usam de serviços e espaço na nuvem.
iCloud
A Apple lançou os serviços do CloudKit em 2015 como parte de suas atualizações do iOS 8, começou um pouco fraco mas aos poucos está melhorando cada vez mais devido à importância que a Apple dá ao iCloud e como utiliza esta tecnologia nos seus aplicativos nativos (Fotos, Notas, entre outros), o que deixa muito difícil que este serviço ser descontinuado.
As principais funcionalidades do CloudKit é prover autenticação, banco de dados público e privado e armazenamento estruturado de arquivos, além de servidor para envio de push notifications. No entanto estes serviços estão disponíveis apenas para dispositivos iOS, contudo, o CloudKit JS possibilita que os dados sejam acessados pela web também, só que, infelizmente, a autenticação continua sendo pelo iCloud, portanto não é possível usar CloudKit ao tentar usar Android.
Infelizmente, o CloudKit pecou em não dar o suporte para login com redes sociais, mesmo possuindo uma tabela de usuário, não há nenhum mecanismo embutido para o usuário se conectar através das redes sociais e nem é possível guardar a informação destes usuários na tabela mencionada previamente. A única alternativa que resta é fazer todo este processo manual e armazenar em uma tabela diferente
A documentação do CloudKit é bem interessante com ótimos vídeos da WWDC (World Wide Developer Conference) de 2014, assim como a documentação que provê excelentes exemplos de código e conselhos sobre como usar a plataforma.
A precificação do CloudKit é muito atrativa, aparenta ser “free forever”, contando com muito espaço e benefícios. A faixa de entrada vai até os 100 mil usuários ativos por mês, fornecendo uma quantidade generosa de transferência e armazenamento de dados gratuitos, facilitando a criação, o teste e a expansão do seu aplicativo. Abaixo há o que a faixa de entrada oferece:
A capacidade altera conforme a quantidade de usuários ativos por mês e a versão free vai até 10 milhões usuários, nesta faixa, os benefícios vão para 10 TB de base de dados, 200 TB de transferência de dados, 1 PB de asset storage, tudo isso com 400 requisições por segundo. Após os 10 milhões de usuários, começa-se a pagar pela quantidade que é usada a mais. Abaixo há uma relação explicando melhor esses preços
- Storage: $ 0,03 / GB
- Banco de Dados: $ 3,00 / GB
- Transferência de arquivos: $ 0,10 / GB
- Requisições por segundo: $ 100 / 10 requisições
Ao utilizar o CloudKit fica uma dúvida sobre a utilização da base de dados privada e qual é a capacidade, se utiliza a espaço do iCloud do usuário ou do próprio aplicativo. Após ler as minúcias da documentação é possível ver que o iCloud provê para cada usuário 5 GB de armazenamento para o banco de dados privado com a opção de upgrade para 2 TB.
Uma das grandes vantagens do CloudKit é a possibilidade de automaticamente e de forma segura autenticar o usuário, isso ocorre pelo fato de como a Apple aproveita a conta iCloud do usuário. Um exemplo prático: como o usuário precisa se logar no iCloud para realizar o download, assim que ele entrar no app ele já está autenticado e o CloudKit utiliza essas informações de um jeito que é conveniente para o usuário e, ao mesmo tempo, respeitando a segurança e privacidade do usuário. Além de melhorar extremamente a UX porque o usuário ao abrir o app não precisa colocar nenhuma informação de conta, é o jeito mais fácil de autenticação para o desenvolvedor lidar.
Firebase
Em 2016, a Google lançou o Firebase com os mais diversos recursos, os quais são divididos em três núcleos principais: desenvolver, crescer e ganhar (permeando tudo o que um app pode necessitar em seu ciclo de vida). Desde o primeiro momento, o Firebase mostra-se como uma ferramenta bem completa que pode auxiliar até os apps mais parrudos.
A primeira impressão do Firebase é uma ferramenta bem vasta e completa a qual possui uma boa documentação e ótimos vídeos de explicações iniciais, certamente depois de alguns vídeos você estará certo de que esta é a ferramenta suprema para desenvolvimento do seu aplicativo. O site é uma maravilha do marketing, contudo, se for preciso de algo mais específico, infelizmente, a documentação não está muito bem atualizada em Swift.
Como a maioria dos MBaaS, ele possui os principais recursos: autenticação, banco de dados e hospedagens de aplicações. Além disso, o Firebase possui alguns diferenciais como banco de dados realtime e hospedagem para aplicações iOS, Android e Web. O portfólio de funcionalidades do Firebase é impressionante, indo desde o armazenamento de arquivos a análise de crashes do seu aplicativo e indexação do conteúdo do seu aplicativo no Google. Caso se interesse em saber mais, não há lugar melhor do que o próprio site do Firebase, mas abaixo há um breve resumo sobre as mais importantes:
A primeira categoria de funcionalidades é desenvolvimento e engloba as seguintes funções:
- Banco de dados realtime: qualquer alteração nos dados é vista no mesmo momento
- Autenticação: autentica usuários nos mais diversos serviços (Facebook, Google, email, GitHub e Twitter)
- Cloud Functions: pode configurar o servidor com eventos baseados em triggers (está em versão beta no momento que foi escrito o artigo)
- Cloud Messaging: sistema de envio de push notification
- Storage: armazenamento de arquivos
- Hospedagem: Android, iOS ou até mesmo Web
- Test lab: testa o aplicativo
- Crash Reporting: analisa os crashs do aplicativo e relata minuciosamente o que ocorreu
Já no de crescimento do app, temos:
- Analytics: plataforma poderosa do Google voltada para o ambiente mobile, a qual pode-se obter informações do uso do aplicativo e do envolvimento do usuário
- App Indexing: coloca o app na pesquisa do Google, ou seja, se o usuário já tiver o app instalado, ele pode abri-lo através de uma pesquisa na web
- Configuração remota: pode-se atualizar o app sem ter que publicar uma nova versão
- Dynamic link: pode-se criar um link que leva o usuário até uma parte específica do aplicativo
E, por fim, o núcleo de ganhar:
- AdMob: plataforma de anúncios do Google com o intuito de monetizar o app com publicidade dentro do app
A maior preocupação de todos é que o Firebase pode encarecer bastante, atitude que já tomou recentemente, quando seu preço aumentou. Antes, o Firebase era o “queridinho” dos MBaaS, pois a precificação tinha um modelo “free forever” com preços mensais escaláveis, ou seja, aumentam à medida que a escala de uso aumenta. Atualmente, foi mantida a precificação escalável, mas o preço aumentou e a versão free foi simplificada, mas de qualquer forma, muitos dados devem ser armazenados antes que o Firebase cobre algo pelo serviço. O que ainda é mais preocupante é que essa mudança de preço foi realizada sem nenhum aviso, não há o que esperar do futuro.
O Firebase, atualmente possui três planos: Free (Spark Plan), Intermediário (Flame Plan) e conforme o uso (Blaze Plan). Abaixo há um comparativo da precificação com a feature mais utilizada, mas no site é possível ver detalhadamente.
Desenvolvimento do app com ambas tecnologias
A comparação entre o iCloud e o Firebase logo se torna injusta, pois são serviços diferentes voltados para resolver problemas diferentes. Enquanto o CloudKit tem como principais funcionalidades: armazenar informações de maneira assustadoramente segura e confiável, o Firebase foca na rapidez, trazendo informações atualizadas em tempo real.
Essas diferenças se tornam aparentes quando tentamos desenvolver um mesmo aplicativo com ambas as ferramentas, o Grocr, um aplicativo de lista de compras colaborativo.
Desenvolvimento com iCloud
O desenvolvimento com o CloudKit é relativamente simples, pois a lógica e estrutura se assemelha à linguagem SQL, mas utiliza uma sintaxe diferente para as queries, a qual possui métodos simples e auto explicativos.
O CloudKit permite criar, ler, atualizar e deletar os “Records” com facilidade. “Record” é o equivalente a uma linha em uma tabela SQL, o qual é criado e gerenciado pelo dashboard online do iCloud.
No CloudKit, tudo que é realizado pode ser visto através do CloudKit Dashboard, por exemplo criar e editar informações. A estrutura do modelo é representada como seções de “Record Type”e a informação em si é armazenada em Zonas. Há uma Default Zone para o banco de dados público e outra Default Zone para o privado.
Além disso, o CloudKit Dashboard permite visualizar o que o que está incluído na sua equipe (depende de privilégios para executar tal atividade) e também configurar um armazenamento de dados para trabalhar no modo de desenvolvimento e produção.
Desenvolvimento com o Firebase
O primeiro contato com o Firebase é um pouco confuso, além de ser um ambiente noSQL, a sua estrutura é baseada em observadores, que são criados para ficar monitorando uma parte específica do JSON e caso aquele item, ou um de seus filhos seja alterado, será executado a closure especificada na criação do observer, e tudo isso de forma assíncrona. No caso da programação em Swift, esses problemas serão resolvidos com o auxílio da documentação do firebase, tutoriais, muito suor e lágrimas.
Comparativo (demonstrativo) prático entre iCloud e Firebase
Create:
iCloud
Firebase
Read:
iCloud
Firebase
Update:
iCloud
Firebase
Delete:
iCloud
Firebase
A comparação entre os dois serviços é difícil, pois se tratam de plataformas muito diferentes tanto em execução quanto propósito. O Firebase é adicionado ao projeto por meio de Cocoa Pods, enquanto o CloudKit é um framework nativo, que requer somente um import e é incrivelmente fácil integrar em aplicativos iOS. O processo mencionado de instalar o Firebase no projeto utilizando Cocoa Pods é bem complicado, cheio de passos que são fáceis de serem esquecidos. A melhor forma de realizar a instalação é seguir o passo a passo disponível na documentação.
Trabalhar com o Firebase requer que o desenvolvedor esteja confortável com a programação por closures, as quais serão executadas quando o observer (funciona como um listener dos padrões de projeto) do Firebase perceber uma alteração, enquanto no iCloud as informações têm de ser ativamente recuperadas e atualizadas no aplicativo, fazer um observer manual. Devido a essas diferenças, o código para as duas versões do aplicativo ficaram bem diferentes, dificultando a comparação ainda mais, pois enquanto o Firebase lida com referências às informações salvas em forma de nós, o CloudKit salva em forma de registros em uma tabela.
De qualquer forma, como CloudKit e Firebase são diferentes na implementação entre si, dificulta a comparação de métodos específicos, o interessante é comparar o projeto como um todo. Para melhor entendimento do assunto, sinta-se à vontade para inspecionar o código e tirar suas próprias conclusões, entre nas páginas do GitHub do projeto realizado no artigo com CloudKit e com Firebase.
Conclusão
Escolher qual MBaaS você deve usar no seu projeto depende muito das funcionalidades que o seu projeto demanda, se for necessário um serviço multiplataforma ou uma base de dados extremamente rápida e ágil, Firebase é a solução, se a sua necessidade é uma base de dados comum, extremamente segura e de fácil manuseio, recomendamos o iCloud.
Deve-se tomar cuidado ao escolher o Firebase como seu MBaaS, ele com certeza é a opção mais atrativa, o que leva a ser escolhido erroneamente como a solução ideal. Por outro lado, o iCloud é mais atraente quando se pensa em segurança e longo termo.
Diferentemente do Firebase, o CloudKit não é possível implementar tarefas que sejam executadas diretamente no servidor, ou seja, não há uma lógica no servidor. Outra divergência é que o CloudKit não exporta os dados, já o Firebase consegue exportar em JSON. Assim como o CloudKit não suporta Analytics, serviço o qual pode-se monitorar o que é feito no aplicativo, relatório de crash, notifica as atividades realizadas pelos usuários, entre outros.
Como o Firebase possui um futuro incerto e que pode mudar sua precificação repentinamente, é importante ter em mente que não se pode depender de uma tecnologia em específico, e essa é uma preocupação a se ter independentemente da escolha do MBaaS. É interessante que a arquitetura do projeto esteja muito bem modularizada, evitando ser encurralado em um serviço específico. Deve-se construir a aplicação de um jeito que se possa trocar de um serviço de MBaaS para outro a qualquer momento, seja Firebase, CloudKit ou até outros.
