Experiência AngularJS + Java em Produção – Blog do Camilo
10 comentários em "Experiência AngularJS + Java em Produção"
01/07/2014 em 13:37
Muito bom seu artigo mas e quanto ao SEO ?
07/11/2014 em 13:52
SEO não está implementado, próximo desafio.
17/07/2014 em 09:38
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.
07/11/2014 em 13:03
Camilo Lopes, Blz? Olhei o sistema da divedoo e achei muito bacana. Posso tirar algumas dúvidas e trocar experiências?
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
07/11/2014 em 13:51
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.
08/11/2014 em 11:56
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ó?
08/11/2014 em 13:55
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).
21/04/2015 em 23:50
Tinha vontade de usar o AngularJS, o problema é o IE.
08/05/2015 em 08:49
O IE antigo certo? Pq nos mais recentes e os que o angularjs informou que suporta, está rodando bem.