Nossas tecnologias no front-end

Um pouco de história

O desenvolvimento front-end deixou de ser a simples camada visual que era há alguns anos e evoluiu juntamente com a necessidade de atender a novos requisitos cada vez mais frequentes como desenvolvimento ágil, responsividade e interfaces assíncronas. Um ecossistema repleto de inúmeras tecnologias surgiram para facilitar o desenvolvimento e melhorar a qualidade do código escrito, para que assim fosse possível assegurar um longo tempo de vida aos projetos, ou seja, melhorar a capacidade de manutenção.

Tendo isto em vista, cada vez mais torna-se uma decisão vital definir a Stack a ser utilizada. Já dizia o Tio Ben: “Com grandes poderes vêm grandes responsabilidades”.

Por quê definir a stack é uma decisão vital? Você ainda pode estar se perguntando, uma vez que várias outras empresas já tiveram esse trabalho antes de você, se dentre as stacks dessas empresas já não existem aquelas consideradas as ideais.

Então, por que gastar seu tempo e o da sua equipe definindo a sua própria stack?

Porque cada caso é um caso e o que determina as necessidades técnicas do seu projeto é o seu negócio, principalmente em startups, onde o negócio está em constante mudança e optar por um framework/tecnologia que não consegue acompanhar essas mudanças pode custar o sucesso da sua empresa.

O que usamos e o porquê de nossas escolhas

LESS

Utilizar um pré processador de CSS nos permite utilizar inúmeras funcionalidades, tais como: variáveis, mixins, funções, modularização de arquivos, operações matemáticas etc, o que facilita de forma significativa a produção de código manutenível e  reaproveitável.

A nossa escolha do LESS sobre os outros pré processadores foi baseada em alguns fatores como popularidade do projeto, issues resolvidas, dependência apenas do node e documentação bem escrita.

Ember.js

Dessa vez terei que dar um pouco de contexto da situação na qual escolhemos o Ember.js. Estávamos migrando de um projeto legado que já havia atingido seu limite (já não era simples desenvolver nada novo e o esforço necessário para “corrigi-lo” era bem similar ao de iniciar um novo projeto).

Neste projeto o front-end estava no asset pipeline do rails e não utilizava nenhum framework para padronização e reutilização do código, ou seja, terra de ninguém.

Bom, essa era mais ou menos a situação na qual nos encontrávamos e precisávamos tomar uma decisão levando em conta não apenas o que havíamos aprendido mas nosso estado atual (sem padrões e boas práticas no front-end).

Com isso percebemos duas coisas:

  • A necessidade de separar o back-end e o front-end em projetos diferentes para que fosse possível ter mais liberdade nas tecnologias utilizadas e no processo de deploy;
  • A importância de utilizarmos um framework que já dispusesse de um conjunto de boas práticas e convenções.

Além desses pontos havia também a necessidade de manter um padrão de conversação entre o back e o front em projetos distintos, o que nos levou a optar pelo uso de JSON API (basicamente uma especificação para construir e consumir APIs em JSON).

Levando essas necessidades/decisões em consideração o número de frameworks diminuiu bastante e dentre eles destacou-se o Ember.js, um framework robusto, com um longo tempo de vida, uma comunidade ativa e consciente, suporte a JSON API e convenções e boas práticas bem definidas.

Mocha / Chai

Devido à boa documentação, ao mapeamento de exceções e à legibilidade e facilidade de escrita dos testes.

Mirage

Uma das possíveis abordagens para se testar / executar a aplicação simulando a interação com um servidor quando se usa Ember.js.

Foi nossa escolha por ser fácil de se configurar, ser bem integrado com o relacionamento entre models do Ember.js e simular um servidor com persistência.

Como aprender nossa stack

Acredito que a melhor forma seria seguir nossa lista de leitura / exercícios:

Concluindo

Estamos há um ano e meio utilizando em produção essa stack e acreditamos ter sido uma decisão acertada, mas como eu disse, cada caso é um caso e acredito que o mais importante é  sempre questionarmos o porquê de cada escolha e estarmos abertos para novas soluções.

E você, já teve alguma experiência com uma stack ou solução parecida?