100%
9.12.2021

Como transformamos o Colab em um Super App

O Augusto Coelho, nosso tech leader, explica neste artigo como o Colab deixou de ser apenas um aplicativo e se tornou um super app.

Os "Super Apps", estilo WeChat, Meituan e TaoBao, são muito populares na Ásia, porém não tanto na sociedade ocidental, onde os aplicativos são mais centrados em fazer bem uma coisa. Dito isso, tivemos que fazer muitas pesquisas para poder entender não só a arquitetura desse novo paradigma, mas também como era a experiência de desenvolvimento. Era um norte que sabíamos que queríamos tomar por conta das convicções de futuro do Colab, então no final de 2020 nasciam os primeiros esboços e POCs para uma mudança bem radical no nosso app.

Nós queríamos ver o que seria necessário para construir algo semelhante. Sempre pensamos "ah, é apenas HTML e Javascript em um WebView", mas a quantidade de esforço para construir seu próprio ecossistema é, essencialmente, uma Store, exige muito mais reflexão - curiosamente, mais reflexão do que nós imaginávamos originalmente. Dizer que é apenas HTML e Javascript é um eufemismo para a engenhosidade que essas empresas tinham com as ferramentas existentes.

 O que é um Super App

Um Super App é um aplicativo que começa com uma funcionalidade (ou conjunto delas) principal. Quer se trate de mensageria (WhatsApp), de um gerenciamento de caronas (Uber) ou de pedidos de comida (Ifood), sacou? Esses apps tem uma funcionalidade principal e fazem bem essa funcionalidade. Então, quando eles aumentam a escala, eles permitem que terceiros (ou eles mesmos) criem "Mini Apps / Mini Programas" dentro de seus aplicativos com um subconjunto de suas funcionalidades. Isso permite que os Mini Programas acessem as funcionalidades do domínio, como se fizessem parte do mesmo ecossistema.

No entanto, existem algumas maneiras de criar um Super App. Se a empresa deseja se expandir em muitos setores, mas controlar todo o aplicativo e seu desenvolvimento, incluindo os novos setores, ela pode construir tudo sozinho como um monólito.

Por outro lado, se a empresa deseja colocar a inovação e compartilhar alguns dos riscos em um jogo B2B2C, pode permitir que terceiros desenvolvam esses novos verticais na forma de Mini Apps. A decisão de qualquer um deles altera amplamente os casos de risco, implementação e investimento antecipadamente.

Mas antes de continuarmos com a explicação, vamos ver se estamos na mesma página em questão de terminologia.

Aqui no Colab adoramos inovar na gestão pública!

Por isso, disponibilizamos alguns conteúdos mais completos que falam sobre gestão pública. Deixe o seu melhor e-mail para recebê-los!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Terminologia

Host - O host é a aplicação principal, a que foi baixada da Play Store ou Apple Store e que hospeda todos os outros micro apps. No nosso caso, o app do Colab contém dentro de sua arquitetura todos os serviços transversais que os outros Mini Apps vão poder acessar como push notification, pagamento, disparo de e-mails, validação de CPF, de autorização, enfim, qualquer serviço de utilidade para o funcionamento dos side effects desse mini app.

Mini App - O Mini App é o pedaço de código externo ao host que fará uma determinada coisa, estendendo as funcionalidade do app host, já temos exemplos funcionais desses Mini Apps como geração de IPTU e agendamento de vacinação

Arquitetura dos Mini Apps

Isso basicamente ilustra como funciona a relação desses Mini Apps com o resto do ecossistema, eles existem por si só como projetos independentes em .dart, porém podem acessar interfaces dentro de suas controllers para estender suas funcionalidades usando abstrações de serviços de dentro do Colab. Quem fica responsável por essa troca de informação é uma camada extra que precisamos criar, a camada de I/O.

Camada de I/O

A camada de I/O ou Input / Output é uma parte fundamental para a arquitetura de Mini Apps, ela é a responsável por expor determinados serviços no app do Colab, pois cada Mini App é um serviço, certo? 

Basicamente, o encapsulamento de uma determinada funcionalidade executada de determinada forma, a camada de I/O é responsável por duas grandes coisas, a primeira é prover acesso às abstrações de serviços do app do Colab, e a segunda de explicar para o app do Colab como esse mini app vai existir dentro dele, em outras palavras, cuida do manifesto e do lifecycle desse mini app.

Isso possibilita para o desenvolvedor escolher como ele quer que o app apareça no Colab. Hoje conseguimos expor o app dentro do host de diversas formas, escolhendo, por exemplo, os dias da semana, horários específicos, polígonos geométricos e até propriedades do usuário, segmentando assim esses Mini Apps. Por exemplo, é possível determinar que ele seja exibido para “mulheres entre 38 e 43 anos, às quartas-feiras das 10:45 às 18:37, que estejam dentro de uma UBS específica“, tudo isso por conta da camada de I/O.

 O Flutter

O que acaba possibilitando essa flexibilidade é porque usamos uma code base única para esses Mini Apps, e o flutter acaba ajudando muito nessa orquestração quando estamos pensando em Mini Apps que vão estar tanto em Android ou IOS (Ok, ok, poderíamos usar webview com HTML e JS, mas, gente, estamos em 2021…).

O Flutter acaba ajudando muito na parte lógica e organização também, estamos usando flutter modular em toda nossa estrutura, e como ele segue bem os ensinamentos do uncle Bob em questão de clean architecture podemos abstrair serviços de uma forma mais profissional.

Dessa forma conseguimos até usar serviços que podem abstrair funções nativas do device como pushes e até chamadas no celular, tudo isso sendo provisionado através de uma estrutura segura e organizada.

Considerações

Se você leu até aqui, muito obrigado! Existem apenas algumas outras considerações que nós gostaríamos de apontar:

  • Lembre-se de que você deve controlar o carregamento e as visualizações da página. Para obter a melhor experiência do usuário, você não quer que fornecedores terceirizados controlem a navegação, né? E isso significa trabalho extra para abrir os serviços e configuração extra no lado do desenvolvimento do Mini App.
  • Crie seu próprio SDK e estrutura, remova todas as funções complicadas da linguagem e coloque na abstração de serviços core apenas aquelas que você deseja permitir que terceiros usem.
  • Crie seu próprio mecanismo de componente, se necessário. O Colab fez isso porque precisávamos de algo com mais desempenho e que corroborasse com o nosso Design System. Certifique-se de que os tempos de re-renderização não sejam triviais.
  • Não subestime as pessoas necessárias para realmente ter um ecossistema. É mais do que apenas viabilidade técnica, você também precisa considerar todo um processo de revisão de Mini Apps e criar ferramentas de terceiros para que as pessoas que criam Mini Apps em sua plataforma também tenham uma boa experiência.

Para o futuro, queremos trazer ainda mais a possibilidade de outros usuários usarem o Colab para exercer a cidadania, até mesmo com ferramentas no/low code. Queremos que as pessoas se inspirem a participar e colaborar de várias maneiras.

 

Se você se interessou e tem uma ideia de serviço, mas não quer desenvolver um app do zero, fale com a gente, podemos fazer acontecer 😀


Terminologia

Host - O host é a aplicação principal, a que foi baixada da Play Store ou Apple Store e que hospeda todos os outros micro apps. No nosso caso, o app do Colab contém dentro de sua arquitetura todos os serviços transversais que os outros Mini Apps vão poder acessar como push notification, pagamento, disparo de e-mails, validação de CPF, de autorização, enfim, qualquer serviço de utilidade para o funcionamento dos side effects desse mini app.

Mini App - O Mini App é o pedaço de código externo ao host que fará uma determinada coisa, estendendo as funcionalidade do app host, já temos exemplos funcionais desses Mini Apps como geração de IPTU e agendamento de vacinação

Arquitetura dos Mini Apps

Isso basicamente ilustra como funciona a relação desses Mini Apps com o resto do ecossistema, eles existem por si só como projetos independentes em .dart, porém podem acessar interfaces dentro de suas controllers para estender suas funcionalidades usando abstrações de serviços de dentro do Colab. Quem fica responsável por essa troca de informação é uma camada extra que precisamos criar, a camada de I/O.

Camada de I/O

A camada de I/O ou Input / Output é uma parte fundamental para a arquitetura de Mini Apps, ela é a responsável por expor determinados serviços no app do Colab, pois cada Mini App é um serviço, certo? 

Basicamente, o encapsulamento de uma determinada funcionalidade executada de determinada forma, a camada de I/O é responsável por duas grandes coisas, a primeira é prover acesso às abstrações de serviços do app do Colab, e a segunda de explicar para o app do Colab como esse mini app vai existir dentro dele, em outras palavras, cuida do manifesto e do lifecycle desse mini app.

Isso possibilita para o desenvolvedor escolher como ele quer que o app apareça no Colab. Hoje conseguimos expor o app dentro do host de diversas formas, escolhendo, por exemplo, os dias da semana, horários específicos, polígonos geométricos e até propriedades do usuário, segmentando assim esses Mini Apps. Por exemplo, é possível determinar que ele seja exibido para “mulheres entre 38 e 43 anos, às quartas-feiras das 10:45 às 18:37, que estejam dentro de uma UBS específica“, tudo isso por conta da camada de I/O.

 O Flutter

O que acaba possibilitando essa flexibilidade é porque usamos uma code base única para esses Mini Apps, e o flutter acaba ajudando muito nessa orquestração quando estamos pensando em Mini Apps que vão estar tanto em Android ou IOS (Ok, ok, poderíamos usar webview com HTML e JS, mas, gente, estamos em 2021…).

O Flutter acaba ajudando muito na parte lógica e organização também, estamos usando flutter modular em toda nossa estrutura, e como ele segue bem os ensinamentos do uncle Bob em questão de clean architecture podemos abstrair serviços de uma forma mais profissional.

Dessa forma conseguimos até usar serviços que podem abstrair funções nativas do device como pushes e até chamadas no celular, tudo isso sendo provisionado através de uma estrutura segura e organizada.

Considerações

Se você leu até aqui, muito obrigado! Existem apenas algumas outras considerações que nós gostaríamos de apontar:

  • Lembre-se de que você deve controlar o carregamento e as visualizações da página. Para obter a melhor experiência do usuário, você não quer que fornecedores terceirizados controlem a navegação, né? E isso significa trabalho extra para abrir os serviços e configuração extra no lado do desenvolvimento do Mini App.
  • Crie seu próprio SDK e estrutura, remova todas as funções complicadas da linguagem e coloque na abstração de serviços core apenas aquelas que você deseja permitir que terceiros usem.
  • Crie seu próprio mecanismo de componente, se necessário. O Colab fez isso porque precisávamos de algo com mais desempenho e que corroborasse com o nosso Design System. Certifique-se de que os tempos de re-renderização não sejam triviais.
  • Não subestime as pessoas necessárias para realmente ter um ecossistema. É mais do que apenas viabilidade técnica, você também precisa considerar todo um processo de revisão de Mini Apps e criar ferramentas de terceiros para que as pessoas que criam Mini Apps em sua plataforma também tenham uma boa experiência.

Para o futuro, queremos trazer ainda mais a possibilidade de outros usuários usarem o Colab para exercer a cidadania, até mesmo com ferramentas no/low code. Queremos que as pessoas se inspirem a participar e colaborar de várias maneiras.

 

Se você se interessou e tem uma ideia de serviço, mas não quer desenvolver um app do zero, fale com a gente, podemos fazer acontecer 😀


Augusto Coelho

Sobre o autor

TechLead do Colab e caçador de techs de fronteira. Acredita que o o binômio design-tecnologia pode mudar o mundo e a forma como as coisas são pensadas, projetadas e construídas.