Quando eu entrei na mobLee, em 2013, a empresa já tinha desenvolvido alguns aplicativos. Nas primeiras versões, o app era um guia básico da programação do evento, que funcionava como um substituto daqueles guias em papel, com a vantagem de que o organizador podia atualizar as informações em tempo real.
Desde o começo nós tínhamos equipes de desenvolvimento Android e iOS nativos, mas a parte de web não era considerada prioridade.
Com o passar do tempo, o app foi se tornando cada vez mais uma ferramenta de comunicação da organização com os participantes, e uma ferramenta de engajamento entre os próprios participantes. O que exigiu cada vez mais uma inteligência unificada e consistente rodando por trás de tudo isso.
Nesse post eu vou falar um pouco do por quê, lá atrás, nós optamos por construir nossa própria API e os motivos que hoje, depois de mais de 4 anos, nós ainda acreditamos que é importante para uma empresa de SaaS (software como serviço) ter sua própria API.
CMS: onde é tudo gerenciado
O CMS, ou sistema de gerenciamento de conteúdo, é o sistema por onde o organizador configura tudo o que ele precisa no aplicativo e extrai informações importantes que ajudam ele a melhorar o evento em tempo real, sem precisar esperar a próxima edição.
Em 2013, nós já tínhamos uma primeira versão do gerenciador, a qual se comunicava direto com o banco e ao mesmo tempo servia de web service para os aplicativos. Nós tínhamos alguns dados em json, alguns em xml e algumas informações nós puxávamos direto do servidor do nosso principal cliente. Ou seja, não existia um padrão.
Por quê ter uma API própria em 2013?
Primeiro, é importante entender o que é e para que serve uma API. Uma API (do inglês, Application Programming Interface) é um sistema sem interface gráfica, para onde outros sistemas enviam e solicitam dados. Através de uma API é possível fazer com que vários sistemas modifiquem e consumam uma mesma base de informações de maneira padronizada, respeitando regras de negócio únicas.
Naquele momento, nós precisávamos padronizar o formato de entrega dos dados. Além disso, parecia sensato separar o funcionamento do CMS dos dados e da lógica de negócio. Desse jeito nós não precisaríamos nos preocupar de onde as informações vinham e para onde elas iam. Nós também tínhamos a impressão que se separássemos os dois, seria mais fácil de escalar o serviço eventualmente. E realmente foi.
Mas o motivo principal para termos feito nossa própria API foi porque não existiam (ou nós não conhecíamos na época) um serviço para construir e hospedar uma API, como existem atualmente.
E hoje? Vale a pena construir a própria API?
Hoje existem alternativas de serviços que ajudam a construir e hospedar uma API, sem precisar se preocupar com infra-estrutura e dedicação de um desenvolvedor para dar manutenção desse código. Firebase e deployd são alguns exemplos.
Falo isso, pois nós tivemos algumas dificuldades desenvolvendo nossa própria API:
- Primeiro, eu nunca tinha feito uma API. Eu tinha experiência em sistemas de site em PHP e estudava algumas APIs, mas entre isso e realmente fazer, tinha uma certa diferença;
- No mesmo período, nós começamos o gerenciamento da própria infra, já que a hospedagem simples de site que nós usávamos já não estava mais dando conta. Nesse processo, demoramos um pouco para escalar de fato essa infra;
- Definir a arquitetura dos dados, principalmente para dar suporte à internacionalização;
- Fazer uma API com uma performance decente para milhares de usuários simultâneos também deu uma certa dor de cabeça;
- Por último, um ponto que acabou pesando, principalmente para uma empresa nova, é ter grande parte das horas de um desenvolvedor dedicadas à API, enquanto ele poderia estar desenvolvendo ou refinando funcionalidades que convertem em vendas.
Ainda assim, depois de mais de 4 anos desenvolvendo, refinando e dando suporte à essa API, eu continuo acreditando que vale a pena ter sua própria API<. Mas é claro que isso vai depender da natureza do seu negócio, então eu vou dar 8 motivos pelas quais nós passamos que me fazem acreditar que ainda vale a pena manter a própria API.
1) Não ficar refém de uma tecnologia ou serviço
O primeiro motivo é não ficar refém de uma tecnologia específica. Pode ser a troca de banco de dados, de linguagem de programação ou um serviço de terceiros que pode deixar de existir.
No nosso caso, enviar notificações para os usuários é um valor essencial que o aplicativo entrega e nós não podemos correr o risco de parar. Por esse motivo, nós já passamos por duas migrações de serviço de notificação.
No início nós usávamos o Urban Airship, mas o número de usuários começou a crescer e sentimos a necessidade de trocar de tecnologia. Então, migramos para o Parse.
Dois anos depois, o Facebook, dava suporte ao Parse, anunciou que o deixaria para a comunidade e as empresas teriam que cuidar da tecnologia por conta própria. Como nós não queríamos assumir essa responsabilidade com a nossa infra de push, resolvemos trocar de serviço novamente. Como, dessa vez, todas as regras de envio estavam dentro da API, a transição acabou sendo muito mais fácil.
2) Centralizar informações e regras de negócio.
Parece bem óbvio e é a principal função de qualquer API, mas nós já passamos por casos em que o sistema que nós estávamos integrando não tinha uma API. Nós tínhamos acesso direto a um banco de dados. Agora imagina se nós estivéssemos na mesma situação: cada aplicação lendo e escrevendo do jeito ela acha melhor, sem uma API no meio para validar regras e garantir que os dados estão consistentes. Seria o caos.
3) Aplicar regras de integração customizada
Gerenciar regras de integração customizadas. Como assim? Principalmente quando você tem um produto white-label, como o nosso, é necessário ter regras de integração diferentes para clientes diferentes.
Por exemplo, nós temos um produto que é um leitor de contatos que coleta dados a partir da credencial do participante. Por isso, nós temos que integrar dados com diversos sistemas de credenciamento para conseguir conectar a informação da credencial com os dados do participante.
Nesse processo, é bem comum acontecerem mudanças de última hora no formato do código da credencial. Como o processo de republicar um app é relativamente lento, não é possível garantir que todos os usuários estejam com a versão mais atualizada e fica a cargo da API conseguir contornar essas situações.
4) Autenticar o usuário em sistemas diferentes
Como eu já citei, nosso produto é white-label e se integra com vários sistemas dependendo de cada cliente. Às vezes, não basta que o usuário faça login na nossa base, é preciso autenticá-lo no sistema do cliente também.
Imagine ter que ensinar o seu app a se logar em cada sistema. Agora imagine se alguma regra de autenticação do sistema do cliente muda após o app já estar publicado. Seria uma dor de cabeça ter que republicar todos os aplicativos que dependem dessa integração. Por isso, contar com a API ajuda a manter a consistência das chamadas que o app faz e diminui a chance da sua republicação.
5) Segmentar informações
Existem vários casos em que você precisa segmentar informações de acordo com a aplicação que está solicitando-a. O CMS, por exemplo, precisa de informações que os apps não precisam. Eventualmente, pode ser preciso diferenciar informações para usuários de Android ou iOS.
O envio de notificações é um caso de exemplo bem comum. Se precisamos publicar algum tipo de atualização crítica no app iOS e notificar aos usuários, não é necessário que os usuário de Android também recebam essa notificação. Essas regras de segmentação de informação quem cuida é a API.
6) Internacionalizar
Internacionalizar costuma ser um problema para quem está crescendo internacionalmente. Nós temos aplicativos publicados em vários países e em várias línguas: português, inglês, espanhol… até mesmo tailandês. Independente de utilizar uma solução pronta de API ou ter a sua própria API, ela ajuda a manter a consistência entre dados internacionalizados.
É bem comum acontecer dos nossos cliente traduzirem uma parte do conteúdo e deixar partes sem tradução. A API nos ajuda a manter a consistência, entregando a informação numa língua padrão, caso aquela informação não tenha sido ou não precise ser traduzida.
7) Dar suporte a versão antiga do app
Quem nunca passou por isso, um dia vai passar. Continuamente sua aplicação vai ganhar novas funcionalidades e novas regras de negócio. O aplicativo dos usuários que não atualizarem para a última versão pode ficar inutilizável se a API não souber lidar com essas mudanças.
Como você não controla quais usuários de fato fizeram atualização, fica difícil gerenciar esse tipo de coisa sem ter uma API responsável, pois é ela que mantém a consistência das regras de negócio.
8) Controlar o endpoint
Mesmo que você use um serviço como o Firebase por trás da sua API, é importante que você controle o endpoint, ou seja, a URL pela qual suas aplicações acessam a API. Isso reflete tanto a dependência de serviços de terceiros, quanto o suporte à atualização que comentamos.
Se um dia o Google resolver parar de dar suporte (como o facebook fez com o Parse), aumentar o preço para um valor que você não pode mais pagar ou qualquer outra situação que faça você parar de usar o firebase, sua aplicação não pode parar de funcionar. Geralmente, atualizar todos os apps para se comunicarem com a nova API não costuma ser algo trivial, por isso é importante que, mesmo utilizando um serviço de API, você hospede seus próprios endpoint ao invés de utilizar os prontos fornecidos por esses serviços.
Conclusão
Para resumir um pouco de tudo que eu falei: é importante ter seus dados centralizados em uma API. Dessa forma você mantém consistência das informações entre diferentes plataformas e garante que suas regras de negócio são mantidas.
Você não precisa desenvolver tudo do zero. Existem diversos frameworks que facilitam o desenvolvimento de APIs. Se achar melhor você pode utilizar um serviço como firebase ou hospedar seu próprio servidor de Parse, mas mantenha uma camada de negócio na frente.
Mesmo que inicialmente você não precise manipular nada específico, em algum momento essa camada vai te ajudar a resolver problemas. Além disso, você mantém o controle dos seus endpoints e caso o serviço por trás parar de funcionar, você ainda consegue dar um jeito de recuperar sua aplicação sem ter que forçar seus usuários instalarem uma nova versão.
Esse post é o primeiro de uma série de outros posts mais técnicos que faremos focados no desenvolvimento de APIs. Se você gostou ou ficou com alguma dúvida, deixe um comentário para podermos aprofundar o assunto nos próximos posts. :)
