Durante o último ano construí uma plataforma online, que tem como objetivo simplificar a encomenda de refeições em Lisboa.
Neste artigo partilharei a experiência que adquiri ao desenvolver esta plataforma, os erros que cometi e abordarei as principais tecnologias que utilizei.
Como referi, desenvolvi uma plataforma online. Esta plataforma designa-se Magnar e é uma app mobile em que o utilizador pode encontrar e encomendar almoços de restaurantes locais. Existe também uma app em que os restaurantes gerem vendas e pedidos de refeições.
De seguida podem encontrar todo o processo por detrás do desenvolvimento e criação desta plataforma, todas as tecnologias que utilizei e alguns prós e contras.
Arquitetura
A solução de software utilizada segue uma arquitetura clássica cliente/servidor:
- Servidor: responsável pela disponibilização e armazenamento dos dados e comunicação com serviços externos:
- Pagamentos
- Analytics
- Push notifications
- Clientes: aplicações mobile.
Nos próximos capítulos abordarei cada um dos componentes que integra a plataforma.
Apps Mobile
O desenvolvimento mobile pode seguir três abordagens principais:
- Nativo: utilizando os IDE (Xcode no caso de iOS e Android Studio ou Eclipse no caso de Android) e linguagens nativas;
- Cross-platform híbrido: com tecnologias web (usando Cordova, Phonegap, Ionic, etc). As apps são alojadas dentro de uma WebView de uma aplicação nativa;
- Cross-platform nativo: desenvolvimento de apps que são convertidas para múltiplos sistemas (iOS, Android, Windows Mobile) de forma nativa (usando o Xamarin).
Sou quase sempre contra apps híbridas porque:
- Não conseguem oferecer uma experiência nativa devido às limitações de viverem dentro de uma WebView
- Nos casos em que fazem sentido, provavelmente um bom website mobile friendly seria o suficiente
Tecnologias de cross-platform nativo, como por exemplo o Xamarin, por outro lado, acabam por oferecer uma experiência nativa aos utilizadores e benefícios óbvios na programação.
A experiência que tenho em desenvolvimento mobile nativo (Swift e Kotlin) levou-me a optar por esse caminho neste projeto. Hoje teria optado por Xamarin: o tempo de desenvolvimento poderia ser semelhante, mas ganharia quando começasse a adicionar novas funcionalidades.
O fastlane é uma ferramenta de Continuous Integration que permite automatizar tarefas como o lançamento de versões, geração de screenshots, manutenção de provisioning profiles, entre outras. É comparável ao Jenkins e ao Bamboo.
Apesar de ter sido desenvolvida para iOS, já conta com algumas ferramentas para Android.
Esta tecnologia traz benefícios para qualquer projeto, tornando-se mais necessária quanto mais frequentes forem as publicações de novas versões.
Para lidar com traduções usei o Twine, que permite ter um ficheiro de strings (master) e a partir dele exportar para vários formatos: iOS, Android, gettext e jQuery. Os ficheiros são gerados a partir da linha de comandos. É portanto imprescindível em projetos que precisam de suportar mais que uma língua.
Backend
Na altura em que iniciei o projeto, o Parse era a plataforma líder de BaaS (backend as a service), muito útil para programadores sem experiência em backend. Entretanto o Facebook, que o comprou em 2013, decidiu fechá-lo no início de 2016, disponibilizando o Parse-Server, o mesmo que o Parse mas hospedado pelo programador. Neste momento, o Firebase, mantido pela Google, é um substituto à altura.
Com o fim do Parse à vista, decidi aproveitar para criar um backend à medida daquilo que preciso.
Web application framework
O Spring Boot é a web application framework web ideal para construir microserviços de forma rápida. Integra anos de experiência com o Spring, adota a técnica ‘convention over configuration‘ e é facilmente personalizado através de bibliotecas-plugin. É equivalente ao Ruby on Rails ou ao Laravel, mas para Java (embora também possa ser usado com Kotlin ou Groovy).
Sendo uma web application framework, apoia imenso em tarefas comuns, nomeadamente, na construção de APIs REST ou na criação de repositórios de dados.
Autenticação de utilizadores
Decidi manter a autenticação de utilizadores do Parse pelos seguintes motivos:
- Disponibiliza as funcionalidades de registo, login e recuperar password;
- Trata da segurança dos dados dos utilizadores;
- Gere as sessões dos utilizadores (mecanismo baseado em tokens).
Pagamentos
Qualquer sistema que aceite, processe, guarde ou transmita dados de cartão de crédito tem de seguir um conjunto de medidas de segurança criadas pela Payment Card Industry Data Security Standard (PCI DSS). Seguir estas medidas é extremamente complicado e por isso surgem serviços como a PayPal e o Stripe, que abstraem esta complexidade permitindo a qualquer empresa processar pagamentos de forma segura.
Neste momento existem dois líderes no mercado dos pagamentos mobile:
- Braintree: empresa Americana fundada em 2007 e comprada pelo Paypal em 2013. Tem SDKs para várias plataformas que permitem uma fácil integração de pagamentos com cartão de crédito.
- Stripe: também Americana, fundada em 2010. Destacam-se por estarem constantemente a criar novas funcionalidades e a permitir novos métodos de pagamento. Recentemente incluíram SEPA Direct Debit.
Existe outra opção, vinda de França, que vale a pena conhecer também: Lemonway.
Mercado
Um mercado permite ter clientes e vendedores na plataforma, sendo que os pagamentos são feitos ao dono do mercado e redirecionados por ele para a conta dos vendedores.
Esta funcionalidade é extremamente importante neste projeto porque nos permite:
- Não ter de fazer transferências manuais para os restaurantes. Não é relevante quando há apenas alguns restaurantes associados à plataforma, mas compensará quando houverem centenas
- Obter uma taxa por cada transação efetuada
O mercado do Braintree ainda só está disponível no EUA e foi essa a principal razão que me levou a optar pelo Stripe.
Integração
A integração consiste em duas partes:
- Frontend: em que se recolhem os dados do cartão de crédito. O SDK trata de enviar os dados do cartão de crédito para o Stripe de forma segura e de retornar um token que é enviado para o backend. Desta forma, o programador nunca tem de lidar com informação sensível.
- Backend: recebe o token e o valor a debitar, e utiliza o SDK do Stripe para processar o pagamento.
Push Notifications
Push notifications são mensagens que os utilizadores recebem nos smartphones, normalmente enviadas pelo backend. As notificações que recebemos de emails, de conversas de whatsapp e ofertas de marketing são alguns exemplos de push notifications.
O OneSignal destaca-se dos outros serviços pelos seguintes aspetos:
- Integração rápida e boa documentação
- É gratuito
- Suporta bastantes plataformas (mobile, browser, apps Chrome, etc.) e oferece vários SDKs (tanto nativos como híbridos).
- O painel de controlo é intuitivo e permite personalizar bastante as notificações. Importante numa altura em que a apresentação push notifications de Android e iOS estão cada vez mais diferentes e complexas.
- Oferece boas ferramentas de marketing, como por exemplo: A/B testing, segment targeting, drip marketing e conversion tracking.
Não oferecem SDK para o backend, mas facilmente se criam bibliotecas a partir da API REST que disponibilizam.
Analytics
A utilização de analytics em negócios online é fundamental a vários níveis. No caso da Magnar há quatro métricas que me interessam bastante:
- Daily active users: se este valor for demasiado baixo em comparação com o número total de registos, é porque os clientes não estão a voltar. É necessário perceber a razão e iterar o produto.
- Daily new users: média de utilizadores que se registam diariamente. Este número aumentará com o marketing e, se o produto for bom, com o ‘passa-palavra’.
- Crash-free users: percentagem de utilizadores que não experienciam crashes. Mais importante em mobile que na web. Este indicador nunca deverá ser inferior a 95%.
- Pagamentos iniciados e pagamentos finalizados: É importante comparar estes dados diários com o número de daily active users. Se a diferença entre pagamentos iniciados e finalizados for grande, provavelmente será necessário melhorar a usabilidade da app.
O Fabric, desenvolvido pelo Twitter e comprado recentemente pela Google, inclui tudo isto através de dois serviços: Answers (analytics) e Crashlytics (relatórios de erros).
Existem outros serviços de analytics mobile bastante fortes; alguns já oferecem heatmap (bastante comum na web). A escolha do serviço deve ser baseada principalmente nas métricas que se pretendem obter.
Conclusão
Existem vários aspetos a ter em conta durante a escolha de tecnologias, entre eles:
- Experiência prévia: na maioria das vezes escolher uma tecnologia familiar será a opção correcta. “Go with what you know”.
- Requisitos específicos ao projeto: para evitar transferências bancárias manuais, escolhi o Stripe como plataforma de pagamentos por oferecer um mercado online na Europa.
- Orçamento: no caso das push notifications, por exemplo, optei por um serviço gratuito.
Depois da publicação, é necessário continuar a iterar e a melhorar o produto regularmente:
- Continuous delivery tem como objectivo publicar software frequentemente e de forma rápida. Ferramentas como o fastlane e o jenkins ajudam a automatizar estes processos.
- As ferramentas de analytics permitem perceber a forma como os utilizadores estão a usar o software e a detetar problemas de usabilidade. “What gets measured, gets improved”.
Deixo também alguma leitura complementar:
- Stripe vs Braintree
- Como escolher uma biblioteca/framework?
- What is the difference between Spring Boot and the Spring framework?
- The Good and The Bad of Xamarin Mobile Development (também aborda um pouco de desenvolvimento híbrido)