ASP.NET Core 2.0 Razor vs Angular / React / etc

101

Minha equipe e eu recebemos financiamento para começar a desenvolver um aplicativo da web de nível empresarial (não entrarei em detalhes sobre o que ele faz). O aplicativo terá muitas páginas da web separadas, mas duas dessas páginas serão mais focadas e muito pesadas - pesadas como em muita interação do usuário, modais que exibem dados em massa, conexões de websocket, bate-papo, etc.

Fui designado como arquiteto-chefe no projeto, então estou fazendo algumas pesquisas nas estruturas da web mais recentes. Para o back-end, fizemos alguns testes e decidimos usar a plataforma Azure SQL. Até agora, estou gostando das melhorias que foram feitas e estão sendo feitas no ASP.NET com Core 2.0. Especificamente, o mecanismo Razor, em relação às versões anteriores da ASP.NET MVC.

Eu queria obter algumas opiniões de especialistas sobre o "novo" Razor vs. Angular / React e similares. Estou particularmente mais preocupado com o desempenho. Como o Core 2.0 Razor suporta frameworks de renderização do lado do cliente? As diferenças são insignificantes? Nosso aplicativo tem como alvo um potencial de 1.000.000 de usuários (cerca de 100.000 simultâneos).

Desde já, obrigado!

— TchPowDog
fonte

Com " novo Razor " você quer dizer páginas do Razor?

— Werner

Então, qual você escolheu no final e como está indo?

— stt106 de

Como você entrou (ou está progredindo) com este projeto? Estou em uma situação quase idêntica à de você agora e adoraria uma atualização!

— JLo

Olá, JLo e stt106. Desculpa por ter demorado tanto pra te responder. Acabamos optando por um front-end Angular e um back-end da API ASP.NET Core, usando o Azure SQL. Tem funcionado muito bem para nós até agora! Imagino que o React seja um substituto semelhante ao Angular se você se sentir mais confortável com ele. Eu tive que aprender Angular, que foi uma transição muito fácil, e eu adoro isso agora!

— TchPowDog

A comparação da velocidade do ASP.Net Core vs Angular / React está fora do assunto? Pode haver respostas canônicas para isso. Hoje temos Core 2.2 e em breve 3.0.

— MikroDel

Respostas:

Acabamos optando por um front-end Angular e um back-end da API ASP.NET Core, usando o Azure SQL. Testamos o Core Razor e, embora melhor que o antigo Razor, o Angular foi muito mais rápido para nós no final. No que diz respeito à experiência do usuário, o Angular (ou React) é muito superior em termos de desempenho. Descobrimos que os aspectos de vinculação de modelo do Angular são uma vantagem gigantesca da renderização do lado do servidor. Usar o Razor (ou renderização do lado do servidor em geral), entretanto, se presta a uma melhor integridade geral no que diz respeito aos dados e contribui para uma melhor transição de dados do front-end para o back-end. Existe uma verdadeira desconexão entre uma estrutura de front-end e uma API. Todos os dados que são transmitidos ao servidor devem ser convertidos em objetos digitados - isso significa que você deve gerenciar dois conjuntos de modelos POCO separados. Isso pode causar problemas se os objetos do servidor e os objetos front-end não estiverem alinhados. No momento, o Entity Framework Core não está muito amadurecido, então temos problemas com a atualização de objetos, consulta de objetos, incluindo objetos filhos, etc.

No geral, essa configuração funcionou muito bem para nós até agora! Imagino que o React seja um substituto semelhante ao Angular se você se sentir mais confortável com ele. Eu tive que aprender Angular, que foi uma transição muito fácil, e eu adoro isso agora!

— TchPowDog
fonte

Quanto a manter os dois conjuntos de modelos POCO sincronizados, há uma extensão realmente útil para VS que cria interfaces angulares a partir de modelos MVC, verifique a máquina de escrever

— Andy Braham

bem, pessoalmente, se eu tivesse que ir com Angular, eu usaria NoSql para a parte DB.

— Venzentx

Não consigo imaginar a seleção de um barbeador ASP.NET acima do Angular. No passado, o ASP.NET fornecia alguns códigos familiares para desenvolvedores .NET, mas com RAZOR, a curva de aprendizado é maior do que usando Angular. MVC divide a lógica do HTML.

— Marcos

@Mark não acredito nisso. As páginas do Razor são perfeitas, especificamente a maneira como lidam com a vinculação de dados. Eles são muito bons. Mas ofcource para seu cenário angular é perfeitamente adequado.

— Mosia Thabo

@MosiaThabo, Mark não está falando sobre o Razor Pages, ele está falando sobre o Razor. É a isso que meu OP se refere. No meu post original, eu não estava me referindo ao Razor Pages (ou agora chamado de Blazor, eu acho). Eu estava falando especificamente sobre renderização do lado do cliente versus renderização do lado do servidor. Razor Pages é o tipo de Angular / React da Microsoft, que eu acho que eles consideram necessário por causa das vantagens que você tem com Angular e React.

— TchPowDog

Usando Angular / React com API no lado do servidor:

você elimina o processo de geração de HTML no lado do servidor e salva a cpu
api produz pequena carga útil (json) e Razor (html) de um curso seria muito maior em tamanho, recarregamentos de página inteira constantes e ida e volta de postback. então api e spa economizam largura de banda
api e spa podem ter diferentes versões, escalonamento e cenários de implantação
Ao usar o api, você pode suportar o aplicativo móvel também e se você iniciar pelo Razor, pode precisar de um api no futuro

Mas, ao usar Angular / React, você deve se preocupar com os clientes:

o cliente deve habilitar javascript
o cliente deve ter navegadores modernos
o cliente deve ter hardware poderoso o suficiente
SEO

— Mohsen Esmailpour
fonte

Eu entendo as diferenças entre os dois frameworks, estava mais preocupado com o desempenho.

— TchPowDog

O mesmo pipline existe para ambos, mas não conheço nenhum benchmark para páginas de barbear. este link pode ajudar - ASP.NET Razor Pages vs MVC: Como o Razor Pages cabe na sua caixa de ferramentas?

— Mohsen Esmailpour

O Razor oferece suporte a dispositivos móveis, mas as desvantagens listadas não importam. Ambos são rápidos à sua maneira. Eu prefiro Angular, mas ambos são otimizados. O Razor otimiza o código ao não usar uma árvore como o MVC faz. Angular está do lado do cliente, então ele realmente não usa uma árvore, mas também otimiza os dados no HTML até certo ponto.

— Nick Turner

@NickTurner Eu entendi que não era apenas ver a página da web em seu smartphone, mas um aplicativo totalmente próprio. Por exemplo, um aplicativo Android, que pode obter os dados da API inalterada do servidor como estão, enquanto, por outro lado, usa a funcionalidade que o Android fornece - melhor suporte de animação, notificações, mensagens de notificação, etc.

— Raphael Schmitz

Eu não tenho benchmarks. Mas, tenho vários projetos executando JQuery, Razor, .NET MVC (C #), AJAX. Não na escala que você está enfrentando.

Conselhos .. Certifique-se de pensar sobre as coisas e seguir as melhores práticas. Para manter a manutenção, certifique-se de dividir os controladores, visualizações e modelos em grupos menores e significativos. Quando comecei, cometi o erro de colocar tudo em um controlador Home e uma tonelada de visualizações na pasta compartilhada. Estava bem no início, mas quando o recurso creep começou, tornou-se uma bagunça e difícil de voltar e redesenhar.

Eu também uso o Linq2SQL. Cometi o erro de criar modelos para tudo e então percebi que poderia simplesmente retornar o conjunto de resultados de minhas consultas como um modelo. duh.

Se você for .NET MVC e está preocupado com o desempenho, encontrei o seguinte:

NÃO retorne visualizações parciais que criam grandes blocos de HTML! Certifique-se de minimizar tudo. Livre-se de todos os espaços em branco. Use nomes de ID menores. Aproveite o tempo para criar html o mais leve possível. Retorne JSON e peça ao cliente para fazer parte do trabalho.

Tenha cuidado ao desenvolver seu CSS. Não use muitos estilos embutidos, reserve um tempo para incorporar em arquivos CSS que você pode minimizar mais tarde.

O mesmo vale para o JS do lado do cliente. É tentador colocar o JS em visualizações parciais. Mantenha tudo organizado.

Renderizar no IE é horrível. Especialmente se houver muitas imagens. Certifique-se de compactar as imagens o máximo possível, sem perder a qualidade, é claro.

— Keith Aymar
fonte