Posts da Tag: SPA - Blog da TreinaWeb

Desenvolvimento

SPA e SSR: quais as diferenças?

Vamos ver neste artigo as diferenças entre SPA e SSR. Mas, primeiramente, precisamos saber o que vem a ser cada uma delas.

SPA

SPA é uma sigla para Single Page Application, ou Aplicação de Página Única. A utilização de SPAs traz uma melhor experiência do usuário através da sensação de navegação entre as páginas de maneira muito mais rápida. Apesar do nome, isso não quer dizer necessariamente que aplicações SPA terão apenas uma única página.

Aplicações SPA são sempre executadas do lado do cliente – no caso, o navegador. O conteúdo de uma aplicação SPA é carregado completamente logo na primeira requisição – incluindo templates e arquivos JavaScript.

Quando novas páginas precisam ser carregadas, não há a necessidade de uma nova requisição para o servidor: estas páginas são carregadas através de rotinas JavaScript, tirando a necessidade de requisições para o servidor para obtenção do novo conteúdo a ser renderizado: a partir da primeira carga da aplicação, toda a interação para carga de conteúdo passa a acontecer exclusivamente do lado do cliente através do JavaScript.

Vantagens

  • É possível prover interações na aplicação sem a necessidade de recarregamento, oferendo uma experiência muito mais fluída para o usuário;

  • Suporte rico e refinado através de frameworks de mercado maduros, como o Angular, o React e o Vue.js;

  • Pode ocasionar “alívio” ao servidor da aplicação, já que não há a necessidade de se realizar uma requisição ao servidor a cada vez que é necessário carregar um novo conteúdo.

Desvantagens

  • Performance imprevisível: podem ocorrer algumas inconsistências justamente pelo deslocamento do esforço de renderização para o cliente: se existir código JavaScript escrito de maneira incorreta, a performance da aplicação pode ser seriamente afetada;

  • Dificuldades no SEO: aplicações que precisem de SEO podem ter problemas se forem desenvolvidas com frameworks SPA. Como em uma SPA você precisa carregar o JavaScript para então fazer requisições, você acaba não tendo conteúdo para ser indexado por motores de busca como o Google: o conteúdo é carregado de maneira dinâmica. Hoje, já existem maneiras de auxiliar o SEO em aplicações SPA, mas ainda assim, esse é um possível ponto de atenção.

Alguns exemplos de frameworks SPA são o Angular, React, Vue.js e Ember. Alguns exemplos de aplicações SPA são o Twitter, o Gmail, o Google Maps e o Trello.

SSR

SSR é a sigla para Server Side Rendering, ou Renderização do Lado do Servidor. O SSR vem para solucionar um pouco dos problemas das aplicações SPAs, tentando manter suas principais vantagens. O SSR inverte o processo de renderização, trazendo uma parte do esforço de renderização de aplicações SPA para o servidor, de maneira similar ao carregamento tradicional.

O SSR pode fornecer aos usuários um carregamento mais eficiente da aplicação, já que parte da renderização é feita no servidor. Além da possibilidade de melhoria da performance, o SSR ajuda a lidar com alguns problemas de SEO (como indexação), já que parte da aplicação ainda é carregada pelo servidor.

Aplicações SSR também são comumente chamadas de universal apps.

Angular - Tópicos avançados
Curso de Angular - Tópicos avançados
CONHEÇA O CURSO

Vantagens

  • Melhoria do processo de indexação: como parte do conteúdo é renderizado no servidor, é possível definir o conteúdo a ser carregado a partir do servidor da aplicação de maneira que este conteúdo colabore com os mecanismos de indexação dos motores de busca;

  • Menor exigência da máquina do cliente, já que parte do esforço de renderização fica ainda no servidor;

  • Melhor performance da aplicação em geral na maioria dos casos, justamente porque parte da aplicação já é pré-renderizada. Isso auxilia a reduzir inclusive incômodos na experiência de usuários de aplicações SSR, como a rápida página em branco (ou flicker) que acontece em uma parte das aplicações SPA (a página fica em branco enquanto o cliente não termina de processar o JavaScript para carregar a aplicação toda);

Desvantagens

  • O TTFB (time to first byte) em aplicações SSR é maior, pois o servidor precisa justamente pré-carregar parte do conteúdo antes de enviar a resposta para o cliente. TTFB é o tempo entre o servidor receber a requisição e enviar o primeiro conteúdo a ser renderizado pelo cliente. Enquanto o TTFB não acontece, o usuário vê a página sendo “carregada” pelo cliente;

  • Um pouco de incômodo dependendo da experiência de carga: como aplicações SSR são pré-renderizadas pelo servidor, assim que o TTFB é concluído, o cliente começa a iniciar imediatamente o processo de renderização, mostrando a aplicação para o usuário. Porém, o usuário só poderá interagir com a aplicação de fato quando o cliente terminar a sua parte da carga da aplicação. Se o processo de carga do lado do cliente for um pouco extenso, isso pode causar uma experiência de usuário estranha;

A maioria dos frameworks SPA modernos oferece também suporte a SSR. É possível utilizar SSR com Vue.js através do Nuxt.js por exemplo, assim como é possível utilizar SSR com React através do Next.js e com o Angular através do Angular Universal.

Quando utilizar um ou outro?

A decisão de utilizar SPA ou SSR vai depender muito dos objetivos da aplicação. Porém, de maneira geral, os seguintes pontos devem ser levados em consideração:

SPA é uma boa opção caso…

  • A página precise oferecer uma experiência de usuário mais rica e fluída;
  • Existirão muitas interações na página com a renderização de conteúdos dinâmicos;
  • A indexação no Google não seja prioridade.

SSR é uma boa opção quando…

  • Ter boa indexação no Google é um requisito;
  • Existir a necessidade da fluidez do SPA, porém, com um tempo de carga para o usuário mais eficiente;
  • A aplicação possui um número mais extenso de páginas. Nesse cenário, a divisão do trabalho de renderização com o servidor pode vir a ser interessante.

Desenvolvimento Desenvolvimento Front-end

O que é o Angular e para que serve?

Frameworks SPA atualmente são um padrão de mercado quando falamos sobre desenvolvimento front-end. Neste artigo, vamos abordar um dos mais populares frameworks JavaScript da atualidade: o Angular.

Afinal, o que é o Angular?

É um framework JavaScript de código aberto mantido pela Google para a construção de SPA (sigla para Single Page Applications ou Aplicações de Página Única). Resumidamente, uma SPA é basicamente uma aplicação web construída em uma só página, na qual a interação e a navegação entre as sessões de uma página ocorrem de maneira a qual não é necessário recarregar a página em cada uma dessas mudanças.

Sua finalidade é nos dar ferramentas necessárias para criação de aplicações SPA, além disso também deixa o desenvolvimento deste tipo de aplicação mais simples e otimizado. Com ele, podemos desenvolver aplicações web voltadas tanto para resoluções desktop quanto para resoluções mobile, tornando-as dinâmicas, modernas e escaláveis.

Com o Angular, temos um novo paradigma de desenvolvimento focado nos dados da aplicação. Ele não utiliza uma virtualização do DOM para manipulá-lo: ele utiliza mecanismos próprios de detecção de alterações na interface, alterações tas disparadas principalmente por uma estrutura chamada Two-Way Data Binding.

O Two-Way Data Binding mantém o model e a view sempre atualizados entre si, ou seja: sempre que algum model é atualizado, essa alteração se reflete automaticamente na view.

AngularJS ou somente Angular?

Provavelmente, você já ouviu falar de Angular e AngularJS e pode ter ficado em dúvida se é a mesma tecnologia, porque que uma tem “JS” no nome e a outra não. A resposta é: embora o Angular seja a evolução após o AngularJS, eles praticamente são frameworks diferentes.

O AngularJS começou em 2009, sendo definido pelas versões 1.x. Já o Angular (antes conhecido como “Angular 2”, publicado em 2016) é considerado a versão 2 mais as versões superiores. Muitos pensam que o Angular é uma continuação do AngularJS em termos de código, o que não é verdade.

A versão 2, chamada hoje somente de Angular, foi uma reescrita completa do código e tornou-se uma arquitetura completamente diferente, mantendo apenas o nome – porém sem o JS no final. Nesta nova ferramenta, foram seguidos padrões da web moderna, técnicas e boas práticas que foram aprendidas com os erros cometidos no desenvolvimento da ferramenta anterior.

O AngularJS tinha como linguagem padrão o JavaScript. Já o Angular ainda continua baseado no JavaScript, mas através do TypeScript. Com isso, ele passou a oferecer capacidades interessantes antes oferecidas somente pelo TypeScript.

Características

Suas principais características são:

Suporte cross-platform: esse framework fornece suporte a múltiplas plataformas de desenvolvimento. O Angular pode ser utilizado para criar aplicações web SPA, aplicações mobile (com o suporte do Ionic, por exemplo) ou até mesmo aplicações desktop (com o suporte do Electron).

Mesmo em ambientes distintos, a API do Angular permanece praticamente a mesma, o que facilita a curvatura de adoção e aprendizagem em múltiplos ambientes de desenvolvimento;

Integração e suporte à todas as fases de desenvolvimento: provê ferramental e suporte para todas as fases de desenvolvimento, desde a escrita do código em si (apoiando-se bastante na API e no sistema de tipos do TypeScript) até a criação de fluxos de teste (com o apoio principalmente do Karma – uma biblioteca para escrita de testes JavaScript), passando pelo suporte excelente à criação de animações, o provisionamento de estruturas de acessibilidade e até mesmo o scaffolding de projetos através do Angular CLI;

Produtividade aliada à performance: consegue oferecer suporte ao desenvolvimento rápido de aplicações através de uma API simples, bem estruturada e bem documentada, o que acaba trazendo bastante produtividade.

Por fim, por mais que o Angular não utilize o conceito de Virtual DOM (conceito utilizado por outros frameworks, como o React), ainda sim o Angular oferece uma performance bem interessante, principalmente com a Ivy, a engine de renderização utilizada desde o Angular 6+.

Mercado

Atualmente o Angular é um dos frameworks Javascript que dominam o mercado, sendo muito popular nos últimos anos e é utilizado em inúmeros projetos. Por esses motivos, ele vem sendo amplamente requisitado no mercado para desenvolvimento web e mobile, tendo diversas oportunidades no Brasil e no mundo.

Através de uma pesquisa feito pelo Stack Overflow neste ano (2020), ao focar em estruturas web, vemos que ele é muito popular. Apesar de o jQuery estar em primeiro, ele está lentamente perdendo espaço para o React.js e o Angular, ano após ano.

pesquisa-stackoverflow-angular

Com uma rápida pesquisa também podemos ver o número de vagas que requisitam o conhecimento em Angular. Abaixo podemos ver vagas pesquisadas no LinkedIn e InfoJobs. Vale ressaltar as vagas home office.

vagas angular LinkedIn

vagas angular InfoJobs

Desenvolvedor Angular
Formação: Desenvolvedor Angular
O Angular é utilizado por várias empresas em soluções de larga escala. Nesta formação vamos conhecer desde os fundamentos do Angular: como iniciar um projeto, o que são componentes e a trabalhar com o Angular CLI. Até conceitos mais avançados: componentes, diretivas, pipes, validação de formulários, rotas, internacionalização, modularização, carregamento sob demanda, criação de bibliotecas, API de animação e renderização no servidor com Angular Universal.
CONHEÇA A FORMAÇÃO

O que preciso saber para iniciar com essa tecnologia?

Existe muito conteúdo de suporte para o Angular, que conta com uma comunidade grande, ativa e disposta a ajudar.

Se você tem interesse de aprender ou se aperfeiçoar mais nas funcionalidades, conceitos e até mesmo desenvolver um projeto para entender como estruturar uma aplicação web moderna e rápida, temos uma formação específica para você iniciar do zero 🙂


Desenvolvimento

O que são aplicações SPA?

Neste artigo, vamos abordar o que são as aplicações baseadas em tecnologias SPA e o porquê de estas fazerem tanto sucesso nos dias atuais.

A sigla SPA vem de Single Page Applications, ou Aplicações de Página Única. Apesar de o nome permitir a dedução, isso não significa que a aplicação terá apenas uma única página.

JavaScript Básico
Curso de JavaScript Básico
CONHEÇA O CURSO

O que muda na verdade é a forma com que a página irá ser carregada. Estamos acostumados com aplicações onde as páginas são renderizadas do lado do servidor, independente da tecnologia utilizada. Isso traz um efeito: cada nova página que precisa ser carregada se traduz em uma nova requisição para o servidor, requisição esta para que o browser consiga carregar o HTML, o CSS e o JavaScript da nova página requisitada. Por isso, em várias aplicações web, vemos o browser levando um “tempinho” para carregar a nova página, ou vemos a nova página ficar em branco inicialmente para ser carregada em seguida. Estes comportamentos ocorrem por causa do tempo entre o browser fazer a requisição para carregar a nova página e o servidor responder com as novas estruturas a serem renderizadas.

Aplicações baseadas em frameworks SPA funcionam de maneira diferente, pois nelas não há a necessidade de se fazer requisições para carregamento de novas páginas. A aplicação seria “carregada” por inteiro na primeira requisição, onde todo o HTML, CSS e JavaScript necessários seriam carregados de uma vez. A partir deste momento, quando novas páginas precisassem ser carregadas, estas seriam carregadas através de rotinas JavaScript, retirando a necessidade de requisições para o servidor com a finalidade de obter o novo conteúdo a ser renderizado.

Aplicações SPA de maneira geral nos permitem obter algumas vantagens. Uma delas é a possibilidade de otimização em geral da performance da aplicação ao deslocar todo o esforço de renderização para o cliente e permitir um tráfego de dados mais leve entre cliente e servidor. Outra é o reaproveitamento de código através de tecnologias como React/React Native e Angular/Ionic, o que possibilita o desenvolvimento com menor esforço e mais padronizado até mesmo de aplicações mobile. Porém, aplicações SPA têm a tendência de possuírem alguns pontos fracos, como justamente o deslocamento do esforço de renderização para o cliente e, em alguns casos, questões de SEO.

Como aplicações SPA funcionam?

De maneira geral, em uma aplicação SPA, o carregamento dos recursos (como CSS, JavaScript e HTML das páginas) ocorre apenas uma única vez: na primeira vez em que o usuário acessa a aplicação. Nesse primeiro acesso, todo o conteúdo HTML, CSS e JavaScript já é transferido para o cliente. A partir deste momento, quando o usuário transitar pelas páginas da aplicação, não será necessário mais fazer requisições para o servidor para a carga dessas novas páginas: o conteúdo relacionado a elas já foi baixado no primeiro acesso. O que acontece nesse momento é que o conteúdo da página é carregado via JavaScript, código este que é justamente gerado com base nos frameworks SPA, como Angular, React e Vue.js. Por isso, dizemos que o processamento do carregamento das páginas e seus respectivos recursos passa para o cliente, já que JavaScript é uma linguagem majoritariamente client side (existem algumas exceções, como quando trabalhamos com Node.js).

JavaScript Intermediário
Curso de JavaScript Intermediário
CONHEÇA O CURSO

Neste momento, o servidor fica responsável não mais por renderizar e processar a renderização do conteúdo, mas sim por lidar com os dados a serem manipulados pela aplicação. As operações de persistência em bancos de dados ou a devolução de conteúdo para ser renderizado (como uma lista de clientes, por exemplo) passam a ser exclusivamente da aplicação hospedada do lado do servidor. Atualmente, o que é comum é que o servidor exponha uma API RESTful para ser consumida por uma aplicação SPA. A aplicação SPA se comunica com essa API RESTful através de chamadas HTTP, trafegando dados em formatos como XML e JSON. A aplicação do lado do servidor fica responsável por responder a estas chamadas HTTP, realizando os processos de negócio e de persistência que sejam pertinentes na situação. Essa arquitetura traz uma vantagem muito clara: a separação e isolamento completos do back-end e do front-end. Isso possibilita que duas equipes trabalhem nas duas frentes em paralelo por exemplo, além de permitir esforços mais focados: uma pessoa que lida melhor com aspectos ligados ao front-end pode direcionar todo o seu esforço para tarefas relacionadas ao front-end. O mesmo vale para quem tem mais aptidão ao back-end.

Como e onde utilizar?

Atualmente, aplicações SPA podem ser utilizadas em praticamente todas as situações, o que explica bastante a popularização de frameworks SPA como Angular, React, Vue.js e Ember na atualidade. Porém, existem algumas situações onde frameworks SPA podem não ser tão adequados hoje:

• Aplicações que precisem de SEO extremo podem ter problemas se forem desenvolvidas com frameworks SPA. A maioria dos indexadores hoje conseguem entender aplicações SPA, além de dispormos de uma grande quantidade de meta-tags para melhorar este ponto. Porém, é um trabalho adicional frente à clássica renderização de páginas múltiplas no servidor (também chamado de multi-page application). Esse “probleminha” acontece justamente porque o conteúdo não é renderizado no servidor,, sendo renderizado completamente no cliente. Por isso, os mecanismos de busca podem encontrar dificuldade para indexar o conteúdo das páginas, tendo em vista que eles não podem indexar conteúdo gerado do lado do cliente. Isso explica porque a maioria dos frameworks SPA hoje contam com soluções SSR (Server-Side Rendering), onde pelo menos uma parte do conteúdo é carregado do lado do servidor para favorecer os mecanismos de indexação;

• Aplicações SPA podem ser um pouco mais lentas, principalmente na inicialização. Isso ocorre porque todo o conteúdo precisa ser baixado de uma vez para o cliente no primeiro acesso. Além disso, como todo o processo de renderização passa a ser de responsabilidade do cliente, a aplicação passa a sofrer um pouco com possíveis limitações de hardware de quem a acessa. Porém, obviamente, existem técnicas para mitigar este ponto, como o lazy loading;

• De maneira geral, aplicações SPA precisam que o JavaScript no browser esteja habilitado, embora não seja tão comum hoje em dia que o mesmo seja desabilitado. Também existem técnicas que podem mitigar este ponto, como o próprio SSR;

• Há uma ligeira tendência a aplicações SPA serem menos seguras do que aplicações multi-page renderizadas no servidor, principalmente no que diz respeito a ataques XSS. Porém, de fato, isso na verdade está mais atrelado ao conhecimento do desenvolvedor sobre técnicas para evitar estes tipos de ataques; precauções estas que deveriam ser tomadas inclusive em aplicações renderizadas do lado do servidor;

• Atenção à fragilidade do ecossistema JavaScript. Esse é um ponto bem polêmico, mas é fato que a “instabilidade” de frameworks JavaScript é algo a se considerar. É relativamente comum que você desenvolva uma aplicação com uma determinada versão de um framework SPA, mas seja obrigado a reescrever uma quantidade considerável de código quando precisar atualizar a versão do framework utilizada inicialmente no projeto. Esse é, sem sombra de dúvidas, um fator importante a ser colocado na balança; não só no que diz respeito a utilizar um framework SPA ou um framework MPA, mas também no que diz respeito à decisão sobre qual framework SPA deverá ser utilizado, se for o caso.

Desenvolvedor Front-end
Formação: Desenvolvedor Front-end
HTML, CSS e JavaScript são a base de toda a web. Tudo o que você está vendo aqui agora depende deste tripé. Nesta formação vamos iniciar aprendendo lógica. Em seguida veremos todos os aspectos do HTML, CSS e JavaScript. Por fim, aprenderemos Sass, Google Analytics, empacotar nossas aplicações com Webpack, criação de aplicações Desktop com Electron, UX/UI e uma introdução aos frameworks mais utilizados no mercado: Angular, React, Vue e Ember.
CONHEÇA A FORMAÇÃO