Fui convidado pela equipe de Marketing da Hariken a escrever artigos sobre o desenvolvimento de nossos produtos. O que vou escrever aqui são artigos mais técnicos e diferentes dos já postados no blog mas que são bastante interessantes para quem é da área, entusiastas ou startupeiros e empreendedores que precisem tomar decisões sobre quais caminhos seguir na área de desenvolvimento.

No começo de 2017, quando entrei na Hariken, a empresa estava saindo de sua primeira infância. Após diversas experimentações encontramos um conjunto de recursos que tinham um market fit razoável, mas nosso dashboard (painel de controle para consulta dos dados) estava longe de ser perfeito.

Ninguém era culpado disso. A equipe era pequena e cada vez que um recurso novo era planejado, o foco principal era colocar no ar algo que gerasse dados verdadeiros e não estourasse nossos poucos recursos computacionais. Diagramar uma nova tela no dashboard era a última das preocupações.

Dashboard

Dashboard 1.0
Dashboard 1.0

O dashboard 1.0 era funcional, mas foi feito sem planejamento. O design (um tema comprado) era sem personalidade nem inspiração. Alguns dados só podiam ser gerados pelo dashboard, e outros eram gerados em mais de um lugar diferente. Isso tornava inconsistente a geração de relatórios pois era difícil fazer o “cálculo bater” entre os diversos sistemas. E o pior de tudo era que o bichinho era lento… muito lento.

Por incrível que pareça nossos clientes já consideravam nosso dashboard melhor que a maioria nesta época, mas nós sentíamos que algo ainda precisava ser feito.

Desafio

Eu e o Designer fomos trazidos para o time para ajudar nos concentrando em criar uma cara mais amigável para o produto e para a empresa em geral.

Eu sou programador desde a Idade das Trevas (Internet Explorer 6) mas nunca me envolvi tão a fundo no universo frontend. Mesmo porque, este é um universo que explodiu em escopo e complexidade apenas nos últimos anos.

Depois de muitas conversas para entender essa conversa de maluco que é Data Management Platform era hora de começar a planejar a solução.

Enquanto ele se afundava no mar de referências de design eu sentei para cristalizar os objetivos que eu precisava alcançar, e vi que seriam:

  • Criar um look’n’feel unificado (isso ia ser mais responsabilidade do designer, mas eu precisava levar isso em consideração nas minhas escolhas de tecnologia).
  • Criar uma API unificada a partir da qual qualquer produto da Hariken faria consultas. Seria nossa fonte unificada da verdade.
  • Criar um sistema de autenticação e autorização extensível, pra que tanto nossos usuários quanto nossas integrações conseguissem se logar e acessar tudo aquilo que fosse relevante.
  • Criar um FrontEnd novo para substituir o dashboard.
  • Fazer tudo isso em dois meses. Precisávamos de um produto no mercado o quanto antes para poder vender antes que nosso investimento acabasse.

Sem mais delongas, comecei a codificar o sistema de autenticação criando um servidor OAuth 2 em Python. Com ajuda do resto da equipe começamos também a recriar todas as consultas no banco de dados como endpoints numa API RestFul usando micro-serviços.

Frameworks – Opções na mesa

Em 2017, estava acontecendo uma revolução no universo frontend. Novos frameworks nasciam e morriam a cada semana. Foi uma época interessante, mas eu precisava tomar uma decisão rápida. E essa decisão ficaria amarrada com a empresa pelos próximos anos.

AngularJS

AgularJS

Eu tinha uma pequena experiência com AngularJS, então este foi o primeiro framework que olhei. Nesta época o mercado tinha muitos profissionais que citavam alguma experiência com a ferramenta, portanto aumentar a equipe não seria um problema num futuro próximo.

Mas suas desvantagens logo ficaram aparentes. O framework estava recebendo muitos comentários negativos da comunidade (o que apontava para um futuro onde poucos profissionais iriam adotar o framework). A principal reclamação era que com um pouco de descuido os apps feitos no AngularJS poderiam sobrecarregar o navegador do usuário e deixar o sistema lento.

Além de tudo isso, a equipe do Google que criou a ferramenta já estava indo para a versão 2.0 (que seria conhecida apenas como Angular) e isso apontava para um fim de vida do produto no horizonte.

Ember / Knockout / jQuery

Ember.js

Alguns frameworks e bibliotecas JS foram fáceis de descartar. Seja porque não tinham apoio da comunidade ou porque eram ferramentas reconhecidamente inadequadas para o tipo de solução que eu estava desenvolvendo.

Em especial, quero destacar Ember entre essas alternativas. Apesar de não ter mais um market share expressivo a comunidade a sua volta é muito ativa e o framework tem soluções interessantes e inovadoras. Mas na época, diante de todas as incertezas do mercado não estava claro se este framework iria sobreviver.

VueJS

Vue.js

Hoje o VueJS já é um nome conhecido e respeitado. Mas no começo de 2017 a estória era diferente. Especialmente porque o criador é um desenvolvedor chinês e a primeira grande companhia a adotar foi a AliBaba. Por muito tempo a documentação para desenvolvedores da plataforma estava principalmente em chinês e ainda pairava a dúvida se o Vue iria emplacar no ocidente.

Apesar disso o framework tinha muitas similaridades com o AngularJS (seu criador já trabalhou no Google com a turma do Azão) e tem se tornado progressivamente mais parecido com o Angular, especialmente agora que a adoção TypeScript tem aumentado.

Os desenvolvedores que optam por esta solução geralmente gostam muito da atenção que os criadores e mantenedores lhes dão.

Curiosamente 2017 foi o ano em que VueJS começou a estourar. Rapidamente o mercado ficou repleto de desenvolvedores Vue. Talvez se eu tivesse começado meu projeto no final do ano esta teria sido minha escolha.  

ReactJS

ReactJS

React é o framework a biblioteca JS mais popular para desenvolvimento de frontends. O projeto, criado pelo Facebook, possui uma comunidade forte e foi adotado por diversas empresas grandes como AirBnB e Netflix.

No entanto a biblioteca possui duas características que foram chave na minha decisão por não adotá-la.

O primeiro é um problema que já foi em grande parte resolvido atualmente: JS Fatigue. Como a comunidade React tem um posicionamento forte sobre deixar a biblioteca pequena e não transformá-la em um framework eu precisaria pesquisar sobre cada uma das soluções auxiliares necessárias para o projeto. Seria necessário até mesmo escolher a forma de roteamento e a biblioteca de requisições HTTP.

Isso fazia que, apesar de o aprendizado inicial ser menor, no longo prazo o desenvolvedor tinha que aprender e manter muito mais bibliotecas de terceiros para conseguir fazer coisas corriqueiras.

Na época ainda não existia uma definição clara sobre qual seria a biblioteca definitiva para cada recurso faltante no react. Hoje já existe uma padronização maior na comunidade e este problema não é tão grande.

O segundo problema é a peculiaridade da forma de escrever componentes React. Meu pano de fundo é de alguém que já trabalhou muito no backend com linguagens orientadas a objeto e frameworks MVC. Eu estranhei logo de cara o formato JSX e por mais que entendesse o conceito uma voz no fundo do meu cérebro ficava dizendo que misturar JS e HTML não era uma coisa boa.

Componentes sem classe e a falta de um conceito parecido com serviços parecia tornar a troca de mensagens entre os componentes algo mais complicado do que deveria ser, a não ser que aprendesse Redux.

Olhe os exemplos de um Hello World em React (de 2017) e em Angular e tente enxergar com os olhos de alguém que veio do mundo OO MVC e você vai entender meu dilema.

// React
function Welcome(props) {
  return <h1>Hello, {props.name}</h1>; 
}
function App() { 
  return (<div>
    <Welcome name="Sarah" />
  </div>); 
} 
ReactDOM.render(<App/>, document.getElementById('root'));
// Angular
@Component({
  selector: 'my-app',
  template: `<hello name="{{name}}"></hello>`
})
export class AppComponent  {
  name = 'Sarah';
}

@Component({
selector: 'hello',
template: `<h1>Hello {{name}}!</h1>`,
})
export class HelloComponent  {
  @Input() name: string;
}

Como uma nota final, nesta época create-react-app, o CLI do react ainda estava em sua infância e pelo que eu ouvia de colegas era muito comum ter que dar eject para conseguir fazer muitas coisas no build da aplicação, e eu definitivamente não queria aprender Webpack.

Angular

Angular

A versão 2 do Angular foi uma reescrita completa do framework. Os desenvolvedores aproveitaram para colocar todos os recursos que seriam necessários para o desenvolvimento do dia a dia como roteamento, injeção de dependências e um CLI (forkado do Ember).

A forma de escrever código no Angular tem uma cara familiar para desenvolvedores com o mesmo passado que eu mas é considerada mais rígida que a maioria no quesito de estilo. Isso facilita as coisas porque qualquer novo desenvolvedor vindo para o time iria codificar de uma maneira similar e estaria acostumado a usar as mesmas ferramentas.

Uma aposta muito acertada foi o uso de TypeScript como linguagem, diminuindo muitos os problemas de tipos de variáveis errados. No começo, grande parte das comunidades dos outros frameworks rejeitava o TypeScript acusando-o de ser muito complexo e desnecessário. Hoje a maior parte dos “concorrentes” está adotando a mesma linguagem. Então ponto pra equipe Angular.

Mãos a obra

No final do segundo trimestre tínhamos lançado como MVPs (minimum viable product) uma nova API e o novo dashboard, agora chamado de UDM, Universal Data Manager.

Com a nova API tínhamos uma maior segurança de que todos os dados estariam sendo gerados de uma forma unificada. O tempo de carregamento do dashboard melhorou muito, principalmente porque agora o carregamento da estrutura das páginas não estava atrelado ao tempo de agregação e carregamento dos dados em si.

Nosso novo visual e a experiência como um todo foi muito elogiada por nossos clientes e parceiros. Ao longo de 2017 lançamos novos recursos e telas. Até que a UDM deixou de ser um MVP e tornou-se um produto completo.

Pivotando

Assim como outras startups, a Hariken estava constantemente mudando sua proposta para melhor refletir as demandas do mercado, algo que no meio chamamos de pivotagem. E no final de 2017 tivemos uma pivotagem brusca que me deu a oportunidade de refletir nas decisões feitas.

Basicamente, a empresa percebeu que nosso maior valor para nossos clientes não era o que achávamos que era. Nosso produto era focado em fornecer ferramentas para os usuários segmentarem seus dados para serem ativados por campanhas de display (compra de visualizações de ads para usuários específicos). Boa parte das telas do sistema eram voltadas para a criação destas campanhas.

Mas muitas empresas e agências são especializadas em criação de campanhas. Mas poucas conseguem fazer segmentação de dados tão bem como nós. Decidimos virar os canhões para focar em segmentação de dados e deixar a criação de campanhas nas mãos do cliente.

Isso significaria remover boa parte das telas que já estavam implementadas e amarrações em outras telas. A tela de entrada dos dados seria reescrita para um novo paradigma visual.

Durante essa pivotagem da empresa também tivemos que mudar toda nossa infra de TI por motivos econômicos e parte do nosso time não permaneceu conosco. Em muitos aspectos estávamos em uma situação parecida com a que tivemos no início de 2017.

Era hora de olhar o bom, o mau e o feio para decidir como iríamos prosseguir.

O Bom

Vimos que nosso design era bem aceito e a linguagem visual dele não precisaria mudar muito.

O Angular, nessa época na versão 4 ficava mais rápido a cada versão e eu finalmente começava a pegar velocidade no desenvolvimento.

Nosso backend, que nessa época era quase totalmente em Python precisaria ser reescrito pois ficamos sem programadores Python suficientes para mantê-lo. Mas como tudo tinha sido convertido para uma API RestFul a reescrita não seria complexa.

O Mau

E precisava reescrever a API e aprender um novo framework backend para fazê-lo.

O prazo para a entrega do 3.0 era ainda mais curto que o prazo inicial da entrega da UDM (2.0). E agora nossos clientes já esperavam ter todo processo de segmentação funcionando. Teríamos que trocar o pneu com o carro em movimento.

O Feio

Como tive que aprender Angular já na prática, não tive tempo de entender algumas das boas práticas. Algumas partes do sistema ficaram esquisitas.

A tela de visualização dos dados através de gráficos e números de destaque exigia muita manipulação assíncrona do estado e meu cérebro treinado apenas para pensar de maneira estruturada e síncrona introduziu muitos bugs.

Terceiro Round

Na versão 3.0, já com um pouco mais de bagagem, procurei evitar as maiores fontes de bugs e para isso adotei alguns design patterns que me ajudariam a ter um código mais padronizado e menos quebradiço.

  • Uso de ngrx com uma forma de armazenamento e manipulação de estado em um único lugar (single source of truth), imutável e unidirecional.
  • Uso observables para deixar o código mais declarativo/reativo e menos imperativo.
  • Cuidados mais intensivos com o número de imports e uso mais abrangente de lazy loading para diminuir o tamanho do bundle inicial.
  • Uso de componentes burros para diminuir o acoplamento entre os módulos e diminuir os efeitos colaterais.
  • Diminuir o uso do cascateamento de CSS para ter folhas de estilo mais legíveis e performáticas.
  • Remoção de algumas animações que taxavam muito o navegador do usuário.

Como no ano anterior, testamos muitos recursos novos, uns deles tiveram boa resposta e outros nem tanto. Mas isso faz parte do jogo das StartUps.

O Presente e o Futuro

Como não poderia ser diferente já temos a versão 4.0 da UDM no horizonte, e talvez ano que vem tenha que escrever um novo capítulo para este artigo, mas por enquanto creio ser suficiente.

Como o foco principal deste artigo foi o desenvolvimento do frontend da UDM (escrita em Angular) gostaria de deixar um panorama geral sobre o presente e futuro próximo do Angular.

Acredito que alguém que esteja começando um produto novo hoje e não tenha muita experiência no frontend não irá errar em escolher Angular, Vue, React ou Ember. No entanto como minha opção foi pelo Angular aqui vai minha análise do futuro próximo do framework:

  • O CLI evoluiu muito e continua evoluindo. Agora é possível criar e configurar código automaticamente, mesmo de pacotes de terceiros através do ng add. O estado atual desta interface já permite economizar muito tempo de configuração. No futuro espere implementações de schematics ainda mais complexos que permitirão configurar rapidamente mesmo projetos com recursos bem avançados como server-side rendering, diferentes tipos de deploy, extração de componentes individuais etc.
  • Empresas de grande porte têm adotado cada vez mais o Angular devido a suas características de ser um one stop shop para todas as soluções de frontend. Então o framework não corre risco de ser abandonado num futuro próximo.
  • Número de acessos ao site da documentação e de perguntas no StackOverflow são maiores que os de React e o número de vagas para profissionais conhecedores da tecnologia é grande e crescente. É difícil encontrar desenvolvedor Angular parado.
  • A velocidade do framework aumenta e o tamanho do bundle diminui a cada release. Com o novo renderizador Ivy sendo adotado, a maior objeção a adoção do framework será coisa do passado.
  • A introdução do elements permitiu inserir componentes Angular avulsos em qualquer página. Quando isso tiver um forma de deploy automática através dos schematics será tão fácil e conveniente usar Angular para widgets em landing pages quanto Vue ou React.
  • Quando o time do Angular apostou em TypeScript e Observables a maior parte dos desenvolvedores de outros frameworks torceu o nariz, mas agora TypeScript está se tornando quase um padrão para desenvolvimento com qualidade em JS e Observables tem crescido em interesse a passos largos. Isso mostra que a equipe de idealizadores estava certa na maior parte de suas apostas.
  • Os criadores são humildes para mudar algumas apostas do framework que não agradaram tanto (como Zones.js e ngModule) e já temos opção de trabalhar sem estes recursos e eles tendem a ser depreciados ou se tornarem opcionais.

Mas nada está escrito na pedra e eu me reservo o direito de mudar subitamente de framework, linguagem, design patterns… se isso se apresentar como uma melhor opção. Afinal esse é o espírito startupeiro.

 

Show Full Content

About Author View Posts

Adam Foerster
Adam Foerster

Front e Teclado Mecânico Maniac

Previous Cookies e marketing digital: de que forma eles se relacionam?
Next As principais informações sobre o que é ETL para você!

Comments

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Close

NEXT STORY

Close

Guia completo do Remarketing: tudo que você precisa saber

07/11/2017
Close