Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

12
Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

Transcript of Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

Page 1: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

Primeiros passos para tomar uma decisão

de arquitetura com AngularJS.

Page 2: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

Mas por que eu preciso pensar nisso?

Page 3: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

● Alguns benefícios de uma arquitetura bem pensada:

Melhor desempenho de carregamento e processamento de página.

Fácil de manter a escalabilidade.

Consistência da sua aplicação.

Código desacoplado.

E muitos, muitos outros benefícios...

Page 4: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

- O Angular Seed (https://github.com/angular/angular-seed), é um esqueleto onde você pode começar. Possue uma arquitetura básica, incluindo o ambiente configurado para realizar seus testes. Basta você clonar o repositório, instalar dependências e feito.

- O Yeoman (http://yeoman.io/) é uma ferramenta que irá criar um esqueleto e oferece um fluxo de trabalho muito bom pois possuí os seus geradores automáticos. Uma linha no terminal e você cria um serviço, controladores, etc.Angular Seed

Yeoman

Os esqueletos mais utilizado

pela comunidade.

Quando estamos começando a desenvolver uma aplicação em AngularJS, grande parte do tempo não sabemos como organizar nossos arquivos e hierarquia de diretórios...

Page 5: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

Ambas as recomendações são excelentes, mas você precisa ter muito cuidado ao usá-los, principalmente no ambiente de produção (apresentação para usuário final).

Em uma página, você usa 10 destes componentes.

Você chegou a um altíssimo nível de

componentização da sua aplicação, onde você

possui vários componentes que podem

ser reutilizados.

E em uma única página você fez +10 requests de arquivos diferentes além

das directivas.

Page 6: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

Fazer vários pedidos para o servidor pode ter um custo muito elevado e gerar problemas de desempenho no carregamento da página...

Hmm, ok. Mas como

posso resolver isso?

Grunt Gulp

Use ferramentas para automatizar algumas tarefas.

http://gruntjs.com/ http://gulpjs.com

Page 7: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

Em ambas as ferramentas, você pode usar tarefas como a minimização e concatenação de arquivos. Desta forma, você só terá um arquivo contendo a sua aplicação.

Isso é bom? Depende muito os requisitos do projeto, das ferramentas, se você utiliza uma CDN para seus arquivos estáticos... Mas de uma coisa eu sei, vale muito mais a pena fazer o pedido de um arquivo com 20kbs do que ter 20 arquivos com 1kb cada. E se você tiver um bom serviço de cache, por exemplo (Amazon CloudFront), a partir do segundo request a sua aplicação vai voar !!

Se você optar por usar um único arquivo da sua aplicação, não se esqueça de ter um controle de versão de seus arquivos estáticos (assets). Você não vai querer estar forçando a invalidação sempre que você fizer uma nova mudança em sua aplicação, isso é muito chato e custoso.

Page 8: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

Eu trabalhei em um projeto que depois de um tempo, voltei para analisar algumas decisões que tinha tomado e elas não eram muito boas. E assim fizemos as mudanças...

- Melhor utilizar 'template' do que 'templateUrl' em suas directivas. Porque cada 'templateUrl' será uma nova solicitação para o usuário final.

O que eu penso sobre isso: Se você estiver usando 'templateUrl' numa directiva, pode ter algo errado com ela. Podendo dividi-lo em mais componentes...

Page 9: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

- Melhor utilizar 'ng-if' do que 'ng-show / hide' nas soluções que sua variável da condicional não vai ficar mudando durante a aplicação. Pois a directiva 'ng-if' só vai criar o elemento no DOM se condicional está retornando verdadeiro.

A directiva 'ng-show' e 'ng-hide' são úteis quando a sua

aplicação interage com a condicional. (sem recarregar

a página)

Page 10: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

- Tome cuidado ao usar a diretiva 'ng-repeat' em grandes escalas. Tenha em mente a resposta da seguinte pergunta: "Será que nessa estrutura realmente precisamos utilizar ela?".

- Ambas as estruturas que eu levantei, possuem um ambiente totalmente estruturado para realizar testes de sua aplicação... Então, faça! Não dê desculpas.

- Tenha sempre em mente os requisitos do seu projeto e necessidades, tratar cada componente sendo único e avaliar as possibilidades de encontrar a melhor solução.

Page 11: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

Depois de termos implementado todas essas mudanças e dicas, tivemos um ganho no desempenho e no carregamento da aplicação. Veja um gráfico que fizemos, o antes (vermelho) e o depois (azul):

Page 12: Primeiros passos para tomar uma decisão de arquitetura com AngularJS.

Eu não quis introduzir a solução ideal para todos os projetos, ela não existe. Cada projeto é um projeto. Nós apenas temos que ter cuidado, porque pequenas decisões de arquitetura podem sair caro. E ao escolher qualquer directiva para o seu problema, tente entender o que ela realmente faz antes de implementá-la. Seu usuário final ficará bem satisfeito.

Obrigado!

@_cauealves

/cauealves