Re: [androidbrasil-dev] Comunicação Cliente - Servidor

Esse tipo de problema é dos bons!

Dá pra passar um belo pente fino nisso tudo, e deixar a coisa bem
redonda, é o tipo de projeto que gostaria que acontecesse numa futura
ideia ou produto que eu consiga conceber.

Também acredito que o futuro seja Resful services, baseado em JSON,
não dá pra fugir deste modelo, e, ainda não vi um produto capaz de
facilitar o desenvolvimento de aplicações deste porte.

O node.js com estes frameworks, backbone, twitter bootstrap,
expression são sem dúvida uma tecnologia muito poderosa e seriam minha
escolha atual, digo isto para um site ou qualquer que seja o tipo de
aplicação.

Sou favorável à sites de 1 página só e, uma API central onde ficaria
colocada toda a camada e as regras de negócios.

Cabe o uso de nosql em alguns aspectos, outros prefiro o modelo
tradicional de SQL mesmo.

O pessoal da apigee manja muito destes conceitos, e, fala algo muito
interessante aqui:

http://www.youtube.com/watch?v=QpAhXa12xvU

No fim desejo sucesso pra todos da lista e gostaria de vê-los
apresentar num dos android bootcamps ou quem sabe até mesmo num I/O
futuramente!

[]'s

Ernani


2013/2/5 Ricardo Othuki <othuki@gmail.com>:
> Não estou defendendo ou desmerecendo linguagens ou arquitetura.
> Mas dentro do contexto inicial da theader (arquitetura Cliente/Servidor) com
> Android sendo o Client, o consumo de WEB Service com JSON, na minha opinião
> seria o melhor caminho.
>
> Pensar fora da caixa, é muito importante, mas vamos analisar um caso que
> ocorreu na empresa em que trabalhei:
>
> Um site de eCommerce vinha crescendo a taxas constantes (cerca de 30% ao
> ano) e já consumia a seguinte infra-estrutura:
>
> 4 servidores HTTP (Linux + Apache + PHP) (máxima configuração disponível)
> 1 serviço de Load Balance
> 1 Servidor de Banco (MySql) (máxima configuração disponível)
> 1 equipe de suporte, manutenção e monitoria de infra.
>
> Devido os altos custos operacionais, e a previsão de crescimento, foram
> realizados estudos para encontrar uma solução mais econômica, confiável e
> facilmente escalável, com as seguintes conclusões:
>
> 1 - utilizar SOA ou Arquitetura Orientada a Serviços (client/server).
> 2 - utilizar um servidor HTTP mais eficiente (Nginx)
> 3 - utilizar WEB Service, serviço de troca de dados eficiente e moderno
> (event-driven, non-blocking I/O model)
> 4 - remodelagem da base de dados
>
> Modelos experimentais, indicavam um redução de custos para atender a demanda
> atual acima de 50%.
>
> Os custos para esta mudança:
>
> 1 - Treinamento da equipe de desenvolvimento que não domina as novas
> tecnologias.
> 2 - Refatorar toda a aplicação (feita em PHP orientado a objetos), front-end
> & back-end.
> 3 - Testes e mais teste da nova aplicação.
> 4 - Reeducação dos usuários para as novas features que a tecnologia iria
> propiciar.
>
> Resultado, o projeto foi adiado, pois os riscos pareciam maiores que os
> benefícios.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Android Brasil - Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to androidbrasil-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.