Info+News+Tech

Se você está ciente dos últimos desenvolvimentos em .NET nos últimos dois anos, deve ter ouvido a palavra da moda ‘Blazor’ com frequência. É uma revolucionária estrutura de interface do usuário final do cliente desenvolvida pela poderosa equipe de especialistas em ASP.NET da Microsoft. Desde o seu lançamento, ele se tornou um grande ponto de discussão entre as organizações de tecnologia e a comunidade de desenvolvedores. Blazor oferece uma capacidade incrível de codificar interfaces de usuário / experiências de usuário da web enriquecidas usando CSS, C # e HTML em vez de JavaScript, uma proposta com a qual a maioria dos desenvolvedores sonham há muito tempo.

O que é Blazor?

Blazor é uma estrutura de código aberto e disponível gratuitamente, que permite aos desenvolvedores desenvolver aplicativos da web altamente interativos usando a linguagem de programação C #. Ele permite que uma única linguagem de programação C #, HTML ou Razor escreva o código do lado do cliente e do lado do servidor. O Blazor consegue isso usando o tempo de execução .NET, que é compilado no bytecode WebAssembly. O tempo de execução .NET funciona no navegador e pode permitir a execução de qualquer DLL .NET, incluindo o código que escrevemos na linguagem de programação C #.

Vamos dar uma visão detalhada dos dois modelos de hospedagem do Blazor para melhorar nosso entendimento de sua viabilidade.

1- O Servidor Blazor

2-Blazor WebAssembly

1. O servidor Blazor

Este modelo de hospedagem permite que uma aplicação seja executada no servidor. Ele estabelece uma conexão SignalR entre o servidor e o cliente. Sempre que ocorre algum evento na extremidade do cliente, essa informação é repassada ao Servidor pela conexão SignalR. Assim que a informação é recebida pelo Servidor, ele trata o evento e calcula a diferença para o HTML gerado.

Então, para qualquer comunicação posterior com o cliente, o servidor apenas envia a diferença do HTML pela conexão SignalR e, uma vez que o cliente o recebe, ele atualiza a interface do usuário (IU). O navegador desempenha um papel importante para atualizar a IU, uma vez que apenas a diferença é aplicada para atualizar a IU, o aplicativo executa rapidamente e oferece uma experiência altamente responsiva ao usuário final.

Um aplicativo Blazor pode ser executado facilmente em um back-end ASP.NET core e pode ser acessado facilmente por um navegador. Os aplicativos ASP.NET Core podem ser executados no IIS ou podem ser hospedados como aplicativos autocontidos. O aplicativo ou site Blazor pode ser acessado por qualquer navegador no lado do cliente. O Blazor Server utiliza um arquivo JavaScript para funcionar e usar CSS e HTML para renderizar sua interface de usuário (UI). É importante notar que o Blazor Server não usa WebAssembly.

2. Blazor WebAssembly

Blazor WebAssembly é o segundo modelo de hospedagem oferecido pelo Blazor, que é usado para hospedar diferentes componentes do Blazor. O Blazor WebAssembly possui um runtime .NET incorporado ao WebAssembly , que oferece um bytecode padronizado para os aplicativos da web. Este runtime .NET é facilmente baixado junto com o aplicativo Blazor WebAssembly e permite a execução de código .NET normal diretamente no próprio navegador. Ele oferece uma proposta única onde nenhum plugin extra ou código adicional é necessário para a transpiração.

O Blazor WebAssembly é compatível com todos os renomados navegadores da web modernos disponíveis no mercado para dispositivos móveis e desktops. Sua execução é semelhante ao JavaScript, onde permite que os aplicativos WebAssembly sejam executados com segurança no dispositivo do usuário final, que também está na caixa de proteção de segurança do navegador. Ele oferece aos aplicativos a capacidade de serem implantados como um verdadeiro site estático autônomo, sem qualquer componente de servidor .NET. Os aplicativos podem ser amalgamados com ASP.NET Core, o que garante um desenvolvimento web full stack com a ajuda do ecossistema .NET, que é onde o código do aplicativo pode ser compartilhado facilmente com o servidor e o cliente.

Blazor Server vs WebAssembly – Diferenças entre eles

Agora de volta à estaca zero, ainda temos a mesma pergunta em nossa mente, qual modelo de hospedagem devemos usar para criar um aplicativo Blazor?

Honestamente falando, tudo depende do propósito objetivo e dos recursos a serem oferecidos pelo aplicativo proposto, que estamos planejando criar. Se você está procurando por um aplicativo padrão que deve ser usado em um local com má conectividade com a Internet, certamente iremos optar pelo Blazor WebAssembly como opção padrão para o desenvolvimento de aplicativos, pois oferece a capacidade de funcionar sem uma conexão de servidor .

Temos uma ideia básica sobre os modelos de hospedagem, suas funções e seus utilitários. Agora veremos alguns exemplos em tempo real, onde podemos ver as diferenças claras entre o Blazor Server e o Blazor Web Assembly.

Recursos de renderização de mecanismos de pesquisa

Ao desenvolver o aplicativo Blazor, devemos lembrar que nosso aplicativo será processado e rastreado pelos motores de busca. É um fato conhecido que a maioria dos motores de busca enfrenta dificuldades ao renderizar a funcionalidade cliente-final de uma aplicação web, normalmente desenvolvida em JavaScript.

Embora, nos últimos anos, tenha havido um suporte crescente para JavaScript, no entanto, aqui estamos falando sobre Blazor e WebAssembly. Devemos entender e ver como o Blazor Server e o Blazor WebAssembly executam e suportam diferentes mecanismos de pesquisa. Podemos executar os dois aplicativos e observar seus resultados para entender este parâmetro.

Blazor Server – Um aplicativo desenvolvido no Blazor Server sempre produzirá todo o HTML buscado na forma do código-fonte. Aqui no código-fonte, o código dos links pode ser visto no lado esquerdo da página. Isso o torna maravilhoso para os motores de busca, pois eles podem ler o conteúdo de nossa página da web sem ter que realizar e executar funções do lado do cliente.

Blazor WebAssembly – opera em um nível diferente, onde carrega apenas um modelo no código-fonte. O WebAssembly se responsabiliza pela renderização dos aplicativos e é por isso que os aplicativos WASM não são bons no que diz respeito à renderização do mecanismo de pesquisa.

Suporte offline para aplicativo

Aqui, a maior questão é – O que acontecerá com o aplicativo Blazor quando ele ficar offline devido a algum problema de rede ou sistema?

Servidor Blazor – Para aplicativos de servidor Blazor, uma vez que o aplicativo perde a conexão com o servidor, torna-se quase inútil. Nesses eventos, o aplicativo lança um erro e exibe uma mensagem de erro para o usuário final, conforme mostrado na captura de tela abaixo.

Blazor WebAssembly – Aqui a situação é bem diferente, oferece uma melhor funcionalidade uma vez que o aplicativo perde a conectividade de rede por qualquer motivo. Depois que um aplicativo WebAssembly é baixado para o navegador, o usuário final pode continuar a navegar e usar o aplicativo normalmente, mesmo depois de desligar o aplicativo. O WebAssembly oferece um recurso exclusivo para executar os aplicativos no modo offline.

Escalabilidade

É um fator importante, considerando a tendência atual de escalonamento de aplicativos no mundo da tecnologia.

Blazor Server –   aqui é importante entender que se os aplicativos do Blazor Server devem ser escalados, devemos escalar sua parte do servidor, da mesma forma que escalamos um servidor web padrão. A Microsoft recomendou que precisamos de pelo menos 85 KB de RAM para atender a um único cliente. A Microsoft conduziu vários testes em tempo real e eles chegaram à seguinte conclusão, quanto um servidor Blazor pode suportar.

  • Qualquer servidor com uma única CPU e 3,5 GB de RAM e pode lidar com 5 mil conexões simultâneas.
  • Qualquer servidor com 4 CPUs e 14 GB de RAM pode lidar com 20 mil conexões simultâneas em qualquer ponto do tempo.

Web Assembly – Aqui, o WebAssembly opera de maneira bastante diferente. Ele não precisa de nenhum tipo de escala para a parte do cliente, pois geralmente é baixado pelo usuário final e executado no próprio navegador.

Inicialização do aplicativo –

A inicialização do aplicativo é um aspecto importante de qualquer aplicativo. Aqui, estamos pegando um exemplo de aplicativo de “Previsão do tempo”, que geralmente é fornecido com o Blazor. Aqui, tentaremos ver como esses aplicativos foram inicializados. Usaremos as ferramentas de desenvolvedor do Google e faremos esforços para mapear a linha do tempo da página inicial. irá clicar no respectivo link do Contador e ver como os dois modelos de hospedagem funcionam de maneira diferente.

Blazor Server – No exemplo abaixo, é bastante evidente que o Blazor Server carrega CSS e HTML. Aqui, também é evidente que ele também contém blazor.server.js (arquivo JavaScript), esse arquivo é útil para inicializar uma conexão com SignalR via web-sockets.

Aqui podemos ver que ele carregou 9 solicitações e as carregou em 317 milissegundos. Agora, se clicarmos no link Contador, saberemos como isso está afetando o cronograma do aplicativo.

Aqui é bastante visível que não há nenhuma nova atividade de rede observada quando clicamos no link fornecido no aplicativo Blazor Server. Os dados estão sendo enviados por meio de uma conexão SignalR ativa, então a página do contador pode ser solicitada clicando no link que é enviado pelo servidor. Aqui, o servidor retorna o HTML para pagers de contador usando o SignalR.

Blazor WebAssembly – Aqui, sempre que tentamos carregar qualquer aplicativo Blazor WebAssembly, ele deve baixar todos os aplicativos no navegador. Se observarmos o exemplo atual, ele deve carregar 203 solicitações em um tempo de carregamento de 4,13 segundos.

Aqui, precisamos ter em mente que, se o aplicativo for grande, serão necessários mais recursos que precisam ser baixados para o navegador. As regras de polegar dizem que quanto mais recursos, mais tempo de carregamento do aplicativo será necessário.

Agora, se virmos a página do Contador, dá a impressão de que a inicialização do aplicativo WebAssembly é mais ou menos semelhante ao aplicativo Blazor Server.

No entanto, a verdade é diferente, os aplicativos WebAssembly oferecem uma inicialização melhor. Isso ocorre porque, ao contrário do Blazor Server, o aplicativo Blazor WebAssembly já foi baixado no navegador do usuário final e não precisa interagir com o servidor.

Também significa que os cliques em links no aplicativo quase certamente carregarão muito mais rápido se compararmos isso com os aplicativos do Blazor Server.

Funcionalidade do lado do servidor –

Este é um aspecto importante que mostra claramente a diferença entre os dois modelos de hospedagem.

Blazor Server – se olharmos a Configuração e o Programa de um aplicativo Blazor Server, ele se parece com um aplicativo ASP.NET Core Web API padrão.

Devido à sua semelhança com a API da Web ASP.NET Core, ela oferece a capacidade de adicionar ferramentas do lado do servidor, como o Entity Framework.

Blazor WebAssembly – Agora, dê uma olhada mais de perto na classe de programa definida no aplicativo Blazor WebAssembly.

É bastante visível que o WebAssembly oferece uma versão muito mais enxuta do aplicativo Blazor Server. Embora ofereça suporte para injeção de dependência, deixa muitos outros aspectos ao mesmo tempo. É importante adicionar que a funcionalidade do lado do servidor pode ser adicionada ao aplicativo Blazor WebAssembly; para isso, devemos integrá-lo a um aplicativo do lado do servidor, como a ASP.NET Core Web API.

Blazor Server vs Blazor WebAssembly – Recursos

A tabela a seguir pode ajudá-lo a tomar a decisão certa antes de se entregar ao desenvolvimento de aplicativos Blazor.

Blazor Server – caso de uso ideal

Embora o Blazor Server possa ser utilizado em vários cenários, ele é conhecido por seu desempenho e execução meticulosos ao desenvolver e executar aplicativos voltados ao público de baixa demanda e aplicativos de intranet. O Blazor Server oferece uma velocidade incrivelmente rápida de desenvolvimento de aplicativos, pois oferece um modelo de hospedagem único e obscenamente rápido, já que quase tudo está disponível no servidor. Ao usar o Blazor Server, não precisamos de projetos API separados e podemos utilizar os serviços de aplicativo diretamente em nossos componentes de aplicativo.

Blazor WebAssembly – Caso de uso ideal

A renomada equipe de desenvolvimento ASP da Microsoft desenvolveu-se e seu objetivo principal era trazer um concorrente direto para estruturas JavaScript altamente populares. Ele oferece recursos e recursos quase semelhantes, o que o torna uma alternativa robusta para quem está procurando algo diferente do JavaScript.

O Blazor WebAssembly também oferece recursos exclusivos para desenvolver aplicativos da Web progressivos, além de oferecer um modelo de desenvolvimento PWA pronto para uso, que atua como um benefício para os desenvolvedores. É importante saber que embora usemos o Blazor WebAssembly, não precisamos usar o .NET na extremidade do servidor. Isso significa que se tivermos um código de back-end do lado do servidor escrito em PHP, Node ou Rails, ainda podemos usar o Blazor como a estrutura de desenvolvimento de componente de front-end sem pensar duas vezes, pois o Blazor WebAssembly acabará nos ajudando na compilação dos arquivos estáticos.

Conclusão

O Blazor foi desenvolvido e lançado pela Líder de Mercado Microsoft, com a visão de criar um concorrente robusto contra o poderoso JavaScript, que está dominando o poleiro há décadas. A Microsoft ofereceu uma infinidade de oportunidades, recursos e opções para o desenvolvimento de aplicativos. Ele oferece modelos de hospedagem do lado do servidor e do lado do cliente, o que também tem seu próprio conjunto de vantagens e desvantagens. No entanto, é importante observar que ambos os modelos de hospedagem oferecem o conjunto certo de recursos para desenvolver aplicativos robustos, escaláveis ​​e de alto desempenho, o que pode dar uma corrida de dinheiro para qualquer aplicativo desenvolvido usando a estrutura JavaScript. Você pode aprender mais sobre isso no site Blazor da Microsoft .

Comments

Deixe um comentário

Info.CEVIU