SPA(Single Page Applications) X Multi-Page ?
30/11/2018
0
Fala aí pessoal, td bom?
Na criação de um novo projeto, vocês utilizam SPA,Single Page Applications, em que o usuário não precisa aguardar o recarregamento de toda a página para vê-la se atualizar por completo ou parcialmente, como por exemplo Facebook e Gmail? Ou o modelo Multi-Page, ou chamado de "tradicional", que são as aplicações que realizam chamadas e execuções em 1 ou várias páginas e sub-páginas, como por exemplo de sistemas intranet?
Na criação de um novo projeto, vocês utilizam SPA,Single Page Applications, em que o usuário não precisa aguardar o recarregamento de toda a página para vê-la se atualizar por completo ou parcialmente, como por exemplo Facebook e Gmail? Ou o modelo Multi-Page, ou chamado de "tradicional", que são as aplicações que realizam chamadas e execuções em 1 ou várias páginas e sub-páginas, como por exemplo de sistemas intranet?
Rodolfo Gomes
Curtir tópico
+ 6
Responder
Post mais votado
01/12/2018
Fala Rodolfo,
Obs.: Apenas minha opinião!!!
A gente aqui na empresa trabalha com sistema de saúde, é um sistema ENORME (a base de código deve estar em umas 18M de linhas), então SPA faz a manutenção, de certa forma, "inviável". Acho que quem já teve que fazer domínios gigantes e complexos sabe disso (existe diferença de perfomance também, se considerar que o servidor do back seja "robusto", já que o uso de RAM da SPA é alto no client-side). E outro problema é a questão de acessibilidade que é razoavelmente afetada nas SPA, além de que muitas redes grandes entre nossos clientes não usam JavaScript ativo no browser, por segurança, aí tu já viu a bagunça né? Haha.
Mas para projetos simples, dashboards e coisas do tipo, eu geralmente penso em SPA em primeiro lugar, já que é muito mais fácil com ela seprar o front-end por completo, e ter somente a regra de negócio e camada de dados no back (que no nosso caso é todo em .NET).
Acho que vai muito de cada situação e eu uso em determinados momentos uma opção, e em outros, outra opção. Mas ainda prefiro a renderização toda no servidor, ao invés de delegar pro client-side, já que acho que existe uma perda de separação de conceitos quando o front tem que gerenciar rotas e validações, etc. Ah, e vale notar que uma boma SEO é mais difícil de ser bem implementada numa SPA, então ter que ter cuidado redobrado!
Pra finalizar, quando existe JavaScript no server, eu sempre separo dos servers que não tem JavaScript. A linguagem já teve muitos erros no passado (incluindo o clássico override de construtores de tipos básicos, como o Array), e ainda não é a mais segura hoje em dia, até porque é bem difícil manter uma linguagem de script mais segura do que uma linguagem compilada.
Obs.: Apenas minha opinião!!!
A gente aqui na empresa trabalha com sistema de saúde, é um sistema ENORME (a base de código deve estar em umas 18M de linhas), então SPA faz a manutenção, de certa forma, "inviável". Acho que quem já teve que fazer domínios gigantes e complexos sabe disso (existe diferença de perfomance também, se considerar que o servidor do back seja "robusto", já que o uso de RAM da SPA é alto no client-side). E outro problema é a questão de acessibilidade que é razoavelmente afetada nas SPA, além de que muitas redes grandes entre nossos clientes não usam JavaScript ativo no browser, por segurança, aí tu já viu a bagunça né? Haha.
Mas para projetos simples, dashboards e coisas do tipo, eu geralmente penso em SPA em primeiro lugar, já que é muito mais fácil com ela seprar o front-end por completo, e ter somente a regra de negócio e camada de dados no back (que no nosso caso é todo em .NET).
Acho que vai muito de cada situação e eu uso em determinados momentos uma opção, e em outros, outra opção. Mas ainda prefiro a renderização toda no servidor, ao invés de delegar pro client-side, já que acho que existe uma perda de separação de conceitos quando o front tem que gerenciar rotas e validações, etc. Ah, e vale notar que uma boma SEO é mais difícil de ser bem implementada numa SPA, então ter que ter cuidado redobrado!
Pra finalizar, quando existe JavaScript no server, eu sempre separo dos servers que não tem JavaScript. A linguagem já teve muitos erros no passado (incluindo o clássico override de construtores de tipos básicos, como o Array), e ainda não é a mais segura hoje em dia, até porque é bem difícil manter uma linguagem de script mais segura do que uma linguagem compilada.
Vinicius Cavagnolli
Responder
Mais Posts
05/12/2018
Gladstone Matos
Fala Rodolfo,
Obs.: Apenas minha opinião!!!
A gente aqui na empresa trabalha com sistema de saúde, é um sistema ENORME (a base de código deve estar em umas 18M de linhas), então SPA faz a manutenção, de certa forma, "inviável". Acho que quem já teve que fazer domínios gigantes e complexos sabe disso (existe diferença de perfomance também, se considerar que o servidor do back seja "robusto", já que o uso de RAM da SPA é alto no client-side). E outro problema é a questão de acessibilidade que é razoavelmente afetada nas SPA, além de que muitas redes grandes entre nossos clientes não usam JavaScript ativo no browser, por segurança, aí tu já viu a bagunça né? Haha.
Mas para projetos simples, dashboards e coisas do tipo, eu geralmente penso em SPA em primeiro lugar, já que é muito mais fácil com ela seprar o front-end por completo, e ter somente a regra de negócio e camada de dados no back (que no nosso caso é todo em .NET).
Acho que vai muito de cada situação e eu uso em determinados momentos uma opção, e em outros, outra opção. Mas ainda prefiro a renderização toda no servidor, ao invés de delegar pro client-side, já que acho que existe uma perda de separação de conceitos quando o front tem que gerenciar rotas e validações, etc. Ah, e vale notar que uma boma SEO é mais difícil de ser bem implementada numa SPA, então ter que ter cuidado redobrado!
Pra finalizar, quando existe JavaScript no server, eu sempre separo dos servers que não tem JavaScript. A linguagem já teve muitos erros no passado (incluindo o clássico override de construtores de tipos básicos, como o Array), e ainda não é a mais segura hoje em dia, até porque é bem difícil manter uma linguagem de script mais segura do que uma linguagem compilada.
Obs.: Apenas minha opinião!!!
A gente aqui na empresa trabalha com sistema de saúde, é um sistema ENORME (a base de código deve estar em umas 18M de linhas), então SPA faz a manutenção, de certa forma, "inviável". Acho que quem já teve que fazer domínios gigantes e complexos sabe disso (existe diferença de perfomance também, se considerar que o servidor do back seja "robusto", já que o uso de RAM da SPA é alto no client-side). E outro problema é a questão de acessibilidade que é razoavelmente afetada nas SPA, além de que muitas redes grandes entre nossos clientes não usam JavaScript ativo no browser, por segurança, aí tu já viu a bagunça né? Haha.
Mas para projetos simples, dashboards e coisas do tipo, eu geralmente penso em SPA em primeiro lugar, já que é muito mais fácil com ela seprar o front-end por completo, e ter somente a regra de negócio e camada de dados no back (que no nosso caso é todo em .NET).
Acho que vai muito de cada situação e eu uso em determinados momentos uma opção, e em outros, outra opção. Mas ainda prefiro a renderização toda no servidor, ao invés de delegar pro client-side, já que acho que existe uma perda de separação de conceitos quando o front tem que gerenciar rotas e validações, etc. Ah, e vale notar que uma boma SEO é mais difícil de ser bem implementada numa SPA, então ter que ter cuidado redobrado!
Pra finalizar, quando existe JavaScript no server, eu sempre separo dos servers que não tem JavaScript. A linguagem já teve muitos erros no passado (incluindo o clássico override de construtores de tipos básicos, como o Array), e ainda não é a mais segura hoje em dia, até porque é bem difícil manter uma linguagem de script mais segura do que uma linguagem compilada.
Entao... quando eu penso em SPA, nao costumo pensar em migrar um 'sistema inteiro'... Mas apenas partes dele, delimitado por contexto; Por exemplo, vamos tomar como base o site da DevMedia - ao inves de criar uma SPA unica para englobar o site todo (cursos, artigos, busca, cadastro, etcetc) - poderiamos criar varias SPAs, uma para cada contexto; A busca poderia ser uma SPA, os cursos poderiam ser outra SPA, por ai vai;
O que voces acham dessa abordagem?
abs
Responder
05/12/2018
Vinicius Cavagnolli
Entao... quando eu penso em SPA, nao costumo pensar em migrar um 'sistema inteiro'... Mas apenas partes dele, delimitado por contexto; Por exemplo, vamos tomar como base o site da DevMedia - ao inves de criar uma SPA unica para englobar o site todo (cursos, artigos, busca, cadastro, etcetc) - poderiamos criar varias SPAs, uma para cada contexto; A busca poderia ser uma SPA, os cursos poderiam ser outra SPA, por ai vai;
O que voces acham dessa abordagem?
abs
Esta é sim, uma boa abordagem (e bem comum por sinal) a ser feita. Eu gosto dela pelo quesito da separação de conceitos, porém no fim, acaba se tornando uma lista de views, como se cada SPA fosse uma View dentro de um MVC já que teria um tratamento de rotas, cookies, claims e etc em dobro (sendo o geral e + o de cada contexto separado), tendo como unica diferença mesmo, o uso dos frameworks SPA disponiveis.
Acho vantajosa para uma equipe que já desenvolve o back-end com tecnologias front-end, ou então se a equipe tem mais experiencia com o próprio front, ou linguagens de script, por exemplo.
Eu discordo que as SPAs gerem mais velocidade de desenvolvimento, porém é muito mais comum achar boilerplates e templates completos e bons com SPAs, facilitando muito o desenvolvimento, então novamente acho que sempre pesa pro lado do background de cada equipe/desenvolvedor.
Particularmente, para divisão de contextos, eu prefiro renderizar views "não-SPA" e me aproveitar de conceitos como Composite UI, já estou fazendo uns testes de Composite UI com Blazor, que une a Razor Engine com WebAssembly, pros front-ends e estou gostando muito (lembrando que pode ser usado em SPAs também).
Responder
07/07/2020
Lebwa
Fala aí pessoal, td bom?
Na criação de um novo projeto, vocês utilizam SPA,Single Page Applications, em que o usuário não precisa aguardar o recarregamento de toda a página para vê-la se atualizar por completo ou parcialmente, como por exemplo Facebook e Gmail? Ou o modelo Multi-Page, ou chamado de "tradicional", que são as aplicações que realizam chamadas e execuções em 1 ou várias páginas e sub-páginas, como por exemplo de sistemas intranet?
Na criação de um novo projeto, vocês utilizam SPA,Single Page Applications, em que o usuário não precisa aguardar o recarregamento de toda a página para vê-la se atualizar por completo ou parcialmente, como por exemplo Facebook e Gmail? Ou o modelo Multi-Page, ou chamado de "tradicional", que são as aplicações que realizam chamadas e execuções em 1 ou várias páginas e sub-páginas, como por exemplo de sistemas intranet?
If you can't decide which approach to go with, SPA or MPA, go on reading a comparison here https://yojji.io/blog/spa-vs-mpa
Single-page applications are the perfect match if you need to create a dynamic solution with a limited data volume. However, if you need to create an online store or build a marketplace like eBay, a multi-page app is the way to go.
Responder
Clique aqui para fazer login e interagir na Comunidade :)
