SPA: o que é e quando usar?

O SPA ao qual me refiro não é aquele lugar de descanso para relaxar e sim um interessante conceito em termos de desenvolvimento WEB cuja sigla significa Single Page Application ou MVC client-side.

A sigla parece meio óbvia... é uma aplicação web de uma página só... sim, beleza é isso, mas não é só isso: aplicativos de uma única página se distinguem pela sua capacidade de redesenhar qualquer parte da interface do usuário sem a necessidade de ida e volta no servidor para recuperar HTML, já que os dados enviados para o navegador apresentam-se em formato bruto JSON ou XML, através do padrão RESTful (onde o servidor expõe um conjunto de endpoints consumidos por clients JavaScript). Funcionando como uma aplicação desktop instalada na máquina do usuário, fica a cargo do navegador  fazer a conversão e o processamento dos dados em HTML, ou seja, desonera o servidor, tornando o tempo de resposta mais rápido.

Modelo tradicional server-side sem ajax

Model, view e controller executam no servidor, geram o html e o enviam ao navegador do cliente.

Modelo tradicional server-side com ajax

Semelhante ao modelo anterior porém, com a implementação de JavaScript utilizando-se de ajax, algumas das funcionalidades da view são processadas no lado cliente, fazendo requisições parciais, o que evita o reload total em cada interação do usuário com a página web.

Modelo client-side

A view e o controller são executados no lado cliente. Já o model passa a ter duas partes, uma executada no lado servidor e outra no lado cliente. O server além de fornecer e armazenar os dados é responsável por fornecer uma API (geralmente em formato RESTful) para ser consumida pela aplicação cliente.Este lado  fica responsável pela renderização de templates e pelo controle de rotas. As validações são responsabilidade de ambos e devem ocorrer tanto no lado cliente quanto no lado servidor.

Em SPA também se utilizam conceitos de desenvolvimento mais modernos como foco em interface mais rica. Interações ricas significam que os componentes da interface têm muito mais estados intermediários, como por exemplo, menu aberto, menu fechado, menu oculto, item de menu clicado, item A do menu selecionado, item B do menu selecionado. Se a renderização destes estados tivesse que ser tratada no lado do servidor a implementação seria bem mais difícil porque os mesmos não são bem mapeados para URLs.
Como temos que focar em escrever mais código client-side a necessidade de padronização e de hierarquia ganha espaço e temos um código JavaScript mais organizado, geralmente com a ajuda de frameworks (como AngularJS, Ember.js e Backbone.js).
Além disso, existem outras coisas interessantes do padrão WEB 2.0 geralmente aplicadas nas SPAs:

• maior expertise em termos de técnicas de front-end;
• desenvolvimento já pensando em termos de ambiente de execução, ou seja qual será o dispositivo onde a aplicação vai rodar (smartphone, tablet, pc, etc);
• não utilização de elementos de navegação convencionais como links (o que seria vantajoso em temos de SEOs) permitindo formas alternativas e mais mais fluidas de explorar e  percorrer a página, como scroll vertical, horizontal e o parallax effect;
• fazem uso do HTML 5;
• trafegam dados de forma assíncrona com o servidor (utilizando WebSockets, AJAX ou Comet);

Agora vem a dúvida: quando utilizar e quando não utilzar a técnica SPA?

Bom, algumas discuções tem sido feitas a respeito e há críticas e elogios. Na minha opinião vale o bom senso. Não dá para sair usando para todos os cenários, o que, diga-se de passagem, é muito comum na informática. Só porque uma tecnologia está na crista da onda é adotada a torto e direito por milhares de desenvolvedores e empresas que querem "andar na moda", sem critérios de aplicabilidade ao contexto.

Mas vamos ao que interessa!

Cenários onde SPAs são interessantes

• Aplicações que tenham uma interface rica e exijam bastante processamento e interação com o usuário (como jogos, processamento de texto, etc)
• Aplicações cujo processamento não exige recursos do servidor (como processamento de imagens)
• Aplicações que precisem funcionar de maneira offline (como mapas, sistemas acoplados ao GPS, etc)
• Aplicações onde seja necessário desenvolver front-ends específicos em função do dispositivo utilizado (como apps para Android, IOS ou Windows Phone)

São exemplos de aplicações que utilizam o padrão SPA: Gmail,  Google, Google Drive, Facebook, Twitter, FourSquare, Instagram, Blogger, LinkedIn e SoundCloud.

Cenários onde as SPAs não são interessantes

• Aplicações que tenham várias páginas e conteúdos diversos
• Conteúdo que precise ser indexado por mecanismos de pesquisa (páginas válidas, que possam ser rastreadas)
• Conteúdo que precise ser exibido quando o JavaScript estiver desabilitado no cliente

Há prós e contras em termos de adoção da tecnologia para a equipe de desenvolvimento.

Prós

• Padronização e modularização do código JavaScript
• Existência de APIs públicas prontas e testadas disponíveis para utilização
• Faz uso de práticas modernas de desenvolvimento
• Separação clara e equilíbro da carga de processamento entre cliente e servidor

Contras

• Inclusão de uma camada a mais na aplicação
• Necessidade de aprender uma ou mais técnicas (MVC e/ou MVVM) e frameworks de front-end
• Existem argumentos contra a utilização de SPA alegando que tanto a não adoção do padrão HTML como a criação de um aplicativo desktop no browser quebram o paradigma WEB. Leia mais em “Web Development: You’re Doing it Wrong”

Dúvidas, sugestões e questionamentos são bem vindos.

Então.. a primeira postagem é sempre difícil..assim como a decisão de escrever...que a gente vai postergando, postergando..até o dia que a vontade se transforma em algo concreto.

Hoje em dia tem tantos blogs sobre tecnologia e desenvolvimento e eu penso então como não ser somente mais um, como fazer alguma diferença na vida das pessoas, passar alguma coisa legal que sirva de inspiração ou que provoque reflexões interessantes.

Não sei vocês, mas na minha humilde concepção o que realmente faz diferença é como cada um de nós atua nos projetos, na equipe, enfim na vida como um todo .Seguir padrões, métricas, metodologias é ok, na real não somente isso, é extremamente importante e  necessário se você deseja fazer um trabalho bom, mas não garante a qualidade do todo.

 Mas porquê? Como assim? Uso Scrum,Kanbam, XP, sigo corretamente vários Design Patterns, faço TDD, BDD, trabalho com Integração e Entrega Contínuas, participo ativamente de comunidades e fóruns de desenvolvimento, sei tudo sobre integração entre sistemas, serviços, ORMs..sou perfeito..kkk SQN meu caro!! It's Really!!

Conhecimento e sua práticas são muito importantes, mas vão além disso, é preciso também que saibamos comunicar, ensinar, nos fazer comprender, difundir o conhecimento e as melhores práticas senão o crescimento para porque ele é em rede! Tudo isso aí que você sabe, me desculpe a sinceridade, mas não é mérito seu, não foi você quem inventou, apenas aprendeu um conhecimento que lhe foi apresentado e conseguiu no máximo evoluir coisas em cima disso, ou talvez nem isso só conseguiu aplicar mesmo.

Então, siga na mesma onda das pessoas que criaram, inventaram e descobriram o que você aprendeu e está aproveitando e compartilhe todo o conhecimento que tiver, ajude o mundo e as pessoas a evoluírem. Não se ache a bolachinha mais recheada do pacote só porque consegue dominar e fazer coisas legais com uma dúzia de tecnologias e linguagem que tem por aí,  isso muitos podem fazer..basta ter um cérebro ágil e dedicação..mas e agora compartilhar, ajudar os outros a aprender, exercitar sua paciência e sua capacidade de transmitir aprendizados será que você consegue?

Fazer o que grandes gênios fazem, compartilhando suas descobertas e criações com o mundo para torná-lo melhor te parece um desafio interessante? Pois é fica aí uma reflexão pessoal sobre o conhecimento e o que fazemos com ele.. talvez seja interessante revermos nossos conceitos e atitudes. Começar por nós mesmo a mudança que queremos no mundo sempre é uma boa opção, é claro na minha humilde opinião. Mas fica a dica..

Um pouco depois de rascunhar este post, acabei lendo o artigo The Reflective Software Engineer: Reflective Pratice, escrito pelos autores Tore Dybá(SINTEF), Neil Maiden(City University of London) e Robert Glasse(Computing Trends) da edição de jullho/agosto da  IEEE Software Magazine (disponível em http://www.computer.org/portal/web/computingnow/software) sobre a prática de aprendizagem reflexiva que veio muito a calhar com o que penso. Daí achei legal, incrementar o post traduzindo e compartilhando um trechinho que dá um overview sobre a ideia:

"Prática reflexiva
O conceito de prática reflexiva centra-se na ideia de aprendizagem ao longo da vida. Fundamental para tal prática reflexiva é a integração entre teoria e prática: o padrão cíclico de experiências e consciente apli-cação dos resultados de aprendizagem dessa experiência
Na verdade, a prática reflexiva desejável ao desenvolvedor ágil oferece uma abordagem alternativa para a aprendizagem de um conjunto de conhecimentos que devem de ser adquiridos por novatos,e que podem ser aplicados para resolver problemas pré-definidos. (Referimo-nos aqui a um conjunto genérico dede conhecimento : assumindo-se conhecimento sobre um negócio, sobre como funciona a tecnologia, sobre as boas práticas de trabalho, tudo o que precisa ser abordado e aprendido). Um profissional reflexivo frequentemente questiona como pensa e age, seja depois de ter agido (reflexão sobre a ação), ou no meio de ação (reflexão na ação). Neste último torna possível alterar o seu curso atual de ação por meio da formulação do problema de uma forma nova ou improvisando novas maneiras de resolver o problema em questão."