Olá Pessoal,
O post de hoje vou falar um pouco sobre a experiência que tivemos aqui na ITSLabs com desenvolvimento de um produto usando AngularJS e hoje está em produção. O produto ainda é um MVP versão 1.0.0 e foi de desenvolvido em 45-50 dias. Para quem acompanha o blog venho trabalhando com AngularJS no dia a dia a quase 1 ano e criei o grupo AngularJS-Brazil (https://groups.google.com/forum/#!forum/angularjs-brazil) no Google Groups e mais uma vez reforço para quem está chegando, quer aprender qualquer tecnologia? Saia do CRUD, só assim você vai poder aprender de verdade.
Lets go…
ITSLabs
Antes de começar falando do projeto, deixa eu falar rapidamente da ITS. A ITS é uma start-up voltada para criação de produtos web e mobile. Aqui buscamos resolver os problemas dos nossos clientes identificamos qual a tecnologia resolve melhor o problema. Portanto, a tecnologia nada mais é que apenas uma ferramenta para atingir o objetivo. Hoje temos projeto com AngularJS, NodeJS, Java etc. Em breve assim que tiver um ok do cliente teremos mais um case que vou compartilhar aqui com vocês de um projeto NodeJS + AngularJS. A ITSLabs não é consultoria, fabrica de software que tem o foco apenas em desenvolver software, vamos um pouco além, e precisamos entregar valor ao negócio do cliente e também trazer valor para nossa equipe técnica. Já rejeitamos projetos que financeiramente seria ótimo, mas valor entregue tecnicamente para nossa equipe seria quase zero. Nosso dia a dia é bem Agile, trabalhamos 95% remoto e pouco focado em horas trabalhadas ou que horas você entrou hoje e saiu ontem. Atender aos prazos com qualidade é o nosso maior ativo.
DiveDoo – www.divedoo.com
É uma plataforma que busca resolver o problema de quem busca acessório, curso, equipamentos na área de mergulho, mas não sabe como e onde encontrar. Fazendo uma pesquisa no Google as informações estão espalhadas e alguns sites podem não ser confiáveis. Baseado nisso foi criado a plataforma pela mergulhadora Gabriela Galvão.
Nossa experiência com AngularJS
Esse foi o nosso terceiro projeto com AngularJS em produção, os dos primeiros eram projetos bem menores com relação ao DiveDoo. Ter escolhido AngularJS foi uma excelente escolha, por alguns motivos:
- Manutenção do lado do cliente: ganhamos muito na organização de js, css etc. Isso foi fantástico e crucial para o desenvolvimento;
- Integração com back-end: ter o back-end e front 100% independente. É fantástico, podemos mudar para qualquer outra tecnologia sem precisar tocar no código do cliente.
- Ter programadores trabalhando em paralelo e separado sem bloqueios: isso ajudou bastante, alguns programadores back-end odeiam front-end (eu era um desses, mas deixei de ser graças ao AngularJS) e aqui podemos manter cada um trabalhando do seu lado e se comunicando apenas através de uma API REST.
- IE: esse cara é uma dor de cabeça. Então se você pensa em querer dá suporte para versões antigas como 8 ou inferior. Esquece de usar AngularJS, apesar que o pessoal da Google fala nas versões mais antigas do AngularJS que eles oferecem suporte e talz, algumas coisas não funcionam bem, e ainda depender do Windows com a versão do IE, pegamos incompatibilidade. É tenso o negócio, simplesmente consome um tempo enorme para tentar achar a solução e se encontrar. Se você tem um projeto que vai dá suporte a esse camarada em versões antiga, pode ir buscando outro framework, pq o AngularJS não vai rolar. E o problema não é do AngularJS, na verdade ele nasceu sem vontade nenhuma em querer ajudar o browser da Microsoft :). A partir do IE9 as coisas já funcionam com uma compatibilidade melhor.
Tools
Usar Yeoman & Grunt é um fator de produtividade. Criamos uma estrutura do lado do back-end onde o desenvolver front-end consegue testar aplicação com back-end localmente e podendo sempre pegar o ultimo código que foi comitado. Separamos isso em módulos :
- Web: aqui é a versão que vai para o servidor remoto
- Core: todo back-end
- Webdev: aqui é onde o programador front-end trabalha e segue toda a estrutura do Yeoman. Se for preciso debugar um código local basta subir aplicação a partir desse modulo usando o comando: grunt Server e pronto.O Server vai subir em porta e IP diferente da aplicação que possui o back-end. Quando o trabalho de front-end está concluído e precisa ser integrado com o back-end basta executar um grunt build e todo código do front é minificado e colocado no modulo de web para ser deployed. Para quem está trabalhando no front-end isso é transparente.
Montamos essa estrutura, pois em projetos passados sofremos bastante com isso, a estrutura tudo em um único projeto funciona bem, quando temos um projeto que não é grande, ou seja, poucas funcionalidades.
Aprendizado
Aprendemos que sem Yeoman é querer sofrer. Realmente é uma ferramenta poderosa e querer fazer tudo na mão, é perda de tempo, exceto se você está querendo aprender criando seus projetos house made. Mas, projeto que vai para produção, não recomendo. UI-Router esse é o cara. Muito bom, e facilita bem o uso de rotas dentro do AngularJS. Quando você usa o UI-router que percebe a limitação que temos com as rotas default com AngularJS. Em breve vou fazer um post sobre ele. Aprenda a separar as coisas, controller, services etc. Ter tudo organizado e separado é importante. Crie padrões de nomeação de arquivos para facilitar na hora que for buscar. Se você usa o Yeoman, ele ajuda em manter tudo organizado. Use e abuse da injection dependecy que temos no angularJS, é fantástico. Lembro que quando comecei a estudar AngularJS demorei um pouco para pegar o core de usar injeção de dependência , a dica é leve o tempo que puder estudando, mas aprenda. Não tenha medo de perguntar e não ache que você sabe tudo, esse é o maior erro achar porque fez algum CRUD que já aprendeu, pelo contrario é nesse momento que a brincadeira começa, todo dia você vai aprender alguma coisa nova.
Conclusão
Hoje usamos fortemente AngularJS em nossos projetos aqui na ITS, há outros valores na tecnologia da Google que se fosse entrar nos detalhes o post viraria um livro. Por falara nisso, em breve estarei lançando meu próximo livro que será sobre AngularJS, que nada mais vai ser o que aprendi nesse quase 1 ano em três projetos completamente diferente e os erros que cometi, e acertos que também tive.
Vou ficando por aqui…
See ya!!!Abraços,
Muito bom seu artigo mas e quanto ao SEO ?
SEO não está implementado, próximo desafio.
Foi usado RequireJS para carregamento dos arquivos?
não foi. Esse projeto nasceu bem colado com a versão do angularjs, pegamos no inicio mesmo. Inclusive ajudamos a equipe do angularjs com alguns bugs que tinham na versão 1.1 do framework.
Camilo Lopes, Blz? Olhei o sistema da divedoo e achei muito bacana. Posso tirar algumas dúvidas e trocar experiências?
Bom, vamos lá.
1 – Vcs tem uma URL para categorias… http://www.divedoo.com/api/categoria
Quando eu clico por exemplo em “Quero viajar”, ele faz 5 requisições para categorias. Vcs não cachearam ela no cliente por algum motivo?
2 – Notei também que não há versionamento das api’s na url’s, e também não foi feito via media type. Como vcs estão tratando essa evoluçao das API’s?
3 – Toda a lógica do Angular foi feita em um arquivo só, o script.js. Pq? Como foi compartilhar o mesmo arquivo durante o desenvolvimento? A gente aqui optou por fazer vários arquivos. Tem a limitação do http 1.1 mas usamos o spdy. Achei melhor separar em vários, e qual foi o motivo de vcs terem usado em um só?
4 – Gostei do login devolver 401 para não autorizados, estou tentando manter os código HTTP’s corretos também.
Por fim, uma dica, o login não está com https e no form eu percebi que vcs só habilitam o botão se o form estiver preenchido. Também estou fazendo isso, gostei da API do Angular para form. A dica é só usar <input nome="email" type="email" ao invés de <input nome="email" type="text" que dae o Angular só enviar o form se o email for válido!
No mais, parabéns pelo Post e sistema
opa Raphael,
1 – Sim, elas não podem ser cacheadas no cliente, pq tem regras de negócio onde preciso ter a informação atualizada sempre a cada nova requisição
2 – a gente não tratou o versionamento da API RESTFUL não. Amarramos tudo na app. mesmo versão da app é a versão da API.
3 – não. Arquivos separados, só que minificamos tudo em um arquivo. Porém, durante o desenvolvimento mantivmos separado.
4 – manter os https é um desafio;
5 – A app toda não está com https
Sobre o campo email, eu não lembro perfeitamente pq não está com o tipo e-mail.Mas, deveria. Estamos refazendo algumas coisas, pois quando começamos esse projeto tinha muita coisa no angualarjs “verde” começamos o segundo e colocamos em produção a estrutura foi outra. Agora vamos restruturar o divedoo, pois tem umas coisas do angularjs que só metendo mão pra aprender mesmo.
vlw pelo feedback
Po.. massa bem legal!!
Sobre o item 3, fizeram isso com o GRunt mesmo neh?
E mais uma pergunta.. vcs mantiram o conteúdo estático em um projeto separado da parte Java ou tudo em um projeto só?
sim, com o grunt. Conteúdo estático separado. Aqui os desenvolvedores “front-end” que não entendem de java ou qualquer outro back-end podem trabalhar isoladamente e subir app e seguir sua vida normal, como se não tivesse trabalhando em um projeto java, ruby etc. Separamos toda essa arquitetura para ter produtividade. Apesar que a maioria dos desenvolvedores back-end aqui aprenderam front-end e não há muito essa diferença, afinal angularjs é fácil demais rs. Tudo é um projeto só, porem separado em modulos. ficando assim: core, web, webdev (é aqui que está o trampo de front-end).
abraço,
Tinha vontade de usar o AngularJS, o problema é o IE.
Olá Salomão,
O IE antigo certo? Pq nos mais recentes e os que o angularjs informou que suporta, está rodando bem.
abraço,