Se você tem acompanhado os últimos desenvolvimentos no mundo .NET ao longo do último ano ou dois, você provavelmente já ouviu a palavra Blazor mencionada uma ou duas vezes. Blazor é uma nova estrutura de interface do cliente da equipe ASP.NET. Seu grande ponto de venda é a capacidade de escrever experiências ricas de Interface web usando HTML, CSS e C# em vez de JavaScript — algo que muitos desenvolvedores têm sonhado.
Embora o JavaScript tenha sido o padrão de fato para o desenvolvimento front-end da Web desde o seu início, nunca pareceu realmente estar felizes com ele. Quero dizer, quantos superconjuntos ou transpilos para linguagens JavaScript surgiram ao longo dos anos para ajudar a melhorar o JavaScript e torná-lo mais mantenedor? CoffeeScript, Dardo, Elm e Scala — para citar apenas alguns.
Olhando para as línguas mais amadas, TypeScript, uma linguagem projetada pelo lendário Anders Hejlsberg,lidera a lista. O mesmo homem que projetou C#, nada menos. Ele adiciona recursos como interfaces, classes, compilar verificação de tipo de tempo, até mesmo genéricos. No entanto, todas essas características e mais já existem em C#, e têm feito por anos. C# é uma linguagem poderosa, flexível e rica que é fácil de aprender.
Mas a Blazor já começou a mostrar que tem potencial como um modelo de programação altamente eficiente e produtivo fora de seu design original — como um concorrente direto para as estruturas de spa (Single Page Application, aplicativo de página única) JavaScript.
A Microsoft já tem vários experimentos acontecendo com Blazor, testando-o com aplicativos de desktop usando Electron e WebWindow (uma alternativa experimental leve à Electron). Mas, mais recentemente, para o desenvolvimento de aplicativos móveis nativos, onde o modelo de programação Blazor é misturado com controles de formas xamarin nativas.
Poderíamos estar vendo o início de uma única estrutura de interface do usuário unificada para construir qualquer tipo de aplicativo com .NET, seja web, desktop ou celular? Não sei quanto a você, mas acho isso uma perspectiva excitante.
O que torna Blazor tão flexível?
Para responder a essa pergunta, precisamos entender como Blazor foi arquitetado.
Essencialmente, Blazor tem uma separação entre como ele calcula as alterações de interface do usuário (modelo de aplicativo/componente) e como essas alterações são aplicadas (renderizador). Isso diferencia o Blazor de outras estruturas de interface do usuário, como angular ou ReactJS/React Native, que só podem criar UIs baseados em tecnologia web. Usando diferentes renderizadores, o Blazor é capaz de criar não apenas UIs baseados na Web, mas também uis móveis nativos.
Isso requer que os componentes sejam de autoria de forma diferente, de modo que os componentes escritos para renderizadores web não podem ser usados com renderizadores móveis nativos. No entanto, o modelo de programação é o mesmo. Ou seja, uma vez que os desenvolvedores estão familiarizados com ele, eles podem criar UIs usando qualquer renderizador.
Modelo de renderização/hospedagem
Em sua essência, o modelo de aplicativo/componente da Blazor é responsável pelo cálculo das alterações da interface do usuário, mas você pode usar diferentes renderizadores para controlar como a interface do usuário é realmente exibida e atualizada. Essas renderizadores são mais comumente referidas como modelos de hospedagem. No momento da escrita, há quatro modelos de hospedagem para Blazor em várias etapas de desenvolvimento.
Servidor Blazor (Renderizador Remoto)
Plataforma: Web
Status – GA/Produção Suportada
Blazor WebAssembly (WebAssembly Renderer)
Plataforma: Web
Status: Visualização (Produto Comprometido)
Elétron Blazor (Renderizador de Elétrons)
Plataforma: Desktop (Windows, Mac e Linux)
Status: Experimental (Não Comprometido)
Ligações Blazor Móvel (MobileBlazorBindings Renderer)
Plataforma: Mobile (iOS e Android)
Status: Experimental (Não Comprometido)
Blazor Server é o único modelo suportado pela produção no momento da escrita. Blazor WebAssembly deve ser lançado por volta de maio de 2020 — eu esperaria que este pudesse ser o grande anúncio na Build. Blazor Electron e Mobile Blazor Bindings são marcados como experimentais e a Microsoft ainda não se comprometeu a enviá-las.
Modelo de aplicativo/componente
Esta é a sala de máquinas da estrutura. Aqui podemos encontrar todos os elementos específicos não-UI que fazem Blazor funcionar. O modelo de programação, roteamento e navegação, e a árvore de renderização, que é o mecanismo de Blazor para calcular as alterações de interface do usuário.
A parte que quero focar é no modelo de programação. Dos quatro modelos de hospedagem que falei acima, os três primeiros têm uma coisa em comum, todos entendem os padrões da web. Os componentes de autoria para segmentar esses modelos de hospedagem usarão HTML e CSS. Mas o quarto modelo, Mobile Blazor, não entende os padrões da Web. Os aplicativos construídos para este modelo de hospedagem precisarão ter seus componentes escritos usando controles móveis nativos.
Para dar um exemplo mais visual, vamos olhar para o mesmo componente escrito para Blazor WebAssembly, que usa um renderer compatível com padrões da Web, vs Mobile Blazor Bindings, que usa o renderizador baseado em padrões não web.
// WebAssembly Renderer
div
pCurrent count: @currentCount/p
button class="btn btn-primary" @Click me/button
/div
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
// MobileBlazorBindings Renderer
StackLayout
Label FontSize="30" Text="@($"Current count: {currentCount}")" /
Button Text="Click me" OnClick="@IncrementCount" /
/StackLayout
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
É fácil ver as diferenças entre as duas amostras de código, mas o que eu quero que você se concentre nas semelhanças.
Ambas as amostras têm uma seção de marcação e um bloco de código. Na verdade, os blocos de código são idênticos entre as amostras. Cada um deles tem um evento 'OnClick' com um manipulador especificado e ambos usam expressões para produzir o valor do campo de contagem atual.
O que estou fazendo aqui é que o modelo de programação é o mesmo. E este é o poder do Blazor, aprenda o modelo de programação e, salvo alguns ajustes aqui e ali, você será capaz de produzir interface do usuário para qualquer tipo de aplicativo, em qualquer plataforma — isso é algo que não fomos capazes de fazer antes com .NET.
Agora temos um pouco mais de entendimento sobre como blazor é montado, quero falar um pouco sobre os dois principais modelos de hospedagem, Blazor Server e Blazor WebAssembly.
Servidor Blazor
O modelo de hospedagem blazor server é atualmente a única opção suportada pela produção para o desenvolvimento blazor agora. Foi lançado em setembro de 2019 com .NET Core 3, durante o .NET Conf.
Neste modelo, o aplicativo Blazor é executado no servidor em cima do tempo de execução completo .NET Core. Quando o usuário carrega o aplicativo, um pequeno arquivo JavaScript é baixado, o que estabelece uma conexão SignalR em tempo real e bidireível com o servidor. Qualquer interação que o usuário tenha com o aplicativo é então transmitida de volta ao servidor através da conexão SignalR para o servidor processar. Após o servidor ser feito, quaisquer atualizações de interface do usuário são transmitidas de volta ao cliente e aplicadas ao DOM.
Agora, eu sei o que você está pensando. Não há nenhuma maneira que isso possa ser realizador, todas essas interações e atualizações de interface do usuário sendo constantemente enviadas para frente e para trás. Mas acho que vai ficar surpreso.
A equipe fez alguns testes de carga no Servidor Blazor para estabelecer o que poderia ou não lidar com isso e foi isso que eles encontraram.
Teste 1 – Instância padrão D1 v2 no Azure (memória 1vCPU e 3,5GB)
O aplicativo poderia lidar com mais de 5000 usuários ativos simultâneos sem qualquer degradação visível no desempenho.
Teste 2 – Instância padrão D3 v2 no Azure (memória 4vCPU e 14GB)
O aplicativo poderia lidar com mais de 20.000 usuários ativos simultâneos sem qualquer degradação visível no desempenho.
São números impressionantes, acho que concordarão. As principais descobertas que saíram desses experimentos foram que a memória e a latência são os principais gargalos dos aplicativos blazor server. Se a latência ficou acima dos 200ms, então o desempenho foi atingido e a escala foi limitada pela memória disponível na caixa.
Benefícios
É executado no tempo completo de execução do .NET Core
Ciclo de desenvolvimento rápido
Tamanho de download pequeno
O código é mantido no servidor e não baixado para o cliente
Inconvenientes
Não funciona bem em ambientes de alta latência
Sem suporte off-line — requer uma conexão constante com o servidor
Demanda de recursos pesados no servidor
Caso de uso ideal
Eu honestamente acho que o Blazor Server pode ser usado para muitos cenários, mas seu nicho será em aplicativos intranet ou aplicativos de baixa demanda voltados para o público. A velocidade de desenvolvimento com este modelo de hospedagem é obscenamente rápida, e quero dizer rápido, devido a tudo estar no servidor. Não há necessidade de projetos de API separados, por exemplo, você pode apenas consumir serviços de aplicativos diretamente em seus componentes. Eu estava cético sobre blazor server no início, mas eu tenho que dizer, eu tenho sido realmente surpreso com o que ele pode fazer.
Blazor WebAssembly
Este é o grande, o modelo de hospedagem que geralmente recebe mais interesse, e por uma boa razão. Este modelo oferece um concorrente direto para SPAs JavaScript, como Angular, VueJS e React.
Usando o WebAssembly, somos capazes de escrever nossa lógica de interface do usuário usando C# e não JavaScript. Está atualmente em pré-estreia e deve ser lançado por volta de maio de 2020.
Uma versão do tempo de execução Mono .NET,compilada para WebAssembly, é baixada para o navegador do cliente juntamente com os DLLs do aplicativo e quaisquer dependências. Uma vez que tudo está no navegador, o tempo de execução Mono é inicializado, e, por sua vez, carrega e executa os DLLs do aplicativo.
Vou abordar a primeira pergunta que geralmente surge de ouvir a explicação acima, qual é o tamanho do download? Bem, a pré-visualização atual pesa em torno de 2,4mb, isso é bastante impressionante considerando que há um tempo de execução .NET envolvido. Mas eu aprecio que isso não é incrível quando comparado com algumas estruturas JavaScript. No momento em que o modelo de hospedagem WebAssembly é lançado em maio, a equipe espera cortar esse tamanho significativamente. O primeiro protótipo da Blazor usou um tempo de execução .NET muito compacto, que compilou apenas 60k de código WebAssembly. Acredito que melhorias de tamanho maior são apenas uma questão de tempo.
Atualmente, o Blazor WebAssembly usa o modo interpretado para carregar e executar seu aplicativo. Neste modo, o intérprete Mono IL executa seus aplicativos .NET DLLs dentro do navegador. A única parte do processo que é compilado para o WebAssembly é o tempo de execução mono. No futuro, a equipe está procurando permitir que os desenvolvedores escolham se seus aplicativos, ou partes mais prováveis de seus aplicativos, também serão compilados para o WebAssembly — isso é conhecido como compilação AOT ou Ahead Of Time. O benefício deste modo é o desempenho, o trade-off é um tamanho de download maior.
Benefícios
Compila para arquivos estáticos, o que significa que não há necessidade de um tempo de execução .NET no servidor
O trabalho é descarregado do servidor para o cliente
Aplicativos podem ser executados em um estado offline
Codesharing, objetos C# podem ser compartilhados facilmente entre cliente e servidor
Inconvenientes
Carga. Agora, se você criar um novo projeto Blazor, ele pesa cerca de 2,4mb. A equipe espera reduzir isso significativamente em maio.
Tempo de carga. Devido ao tamanho do download, dispositivos em conexões ruins podem experimentar tempos de carga iniciais mais longos.
Tempo de execução restrito. Os aplicativos devem operar na caixa de areia do navegador e estão sujeitos às mesmas restrições de segurança que qualquer aplicativo JavaScript.
Caso de uso ideal
Blazor WebAssembly foi construído para ser um concorrente direto das modernas frameworks JavaScript. Portanto, em qualquer lugar que você estaria procurando usar um desses quadros, você poderia considerar Blazor. Também é trivial fazer aplicativos Blazor WebAssembly em PWAs (Progressive Web Application). Na verdade, haverá um modelo fora da caixa para isso que vem em maio.
Também é importante ressaltar que o uso do Blazor WebAssembly não exige que você use .NET no servidor. Ou seja, se você tiver um backend escrito em Node, PHP ou Rails, você pode usar blazor alegremente como frontend sem quaisquer problemas como Blazor WebAssembly compila para arquivos estáticos.
Qual é o futuro de Blazor?
Com um modelo de hospedagem em produção já e outro no caminho em breve, vamos terminar voltando nossa atenção para o futuro.
Onde eu vejo Blazor indo? Voltando ao meu pensamento anterior em torno de Blazor se tornando uma única estrutura de interface do usuário para qualquer aplicativo .NET. Acho que é para onde Blazor está indo, na minha opinião. Se todos os modelos atuais de hospedagem da Blazor entrarem em produção, e agora eu não posso ver por que eles não iriam, os desenvolvedores terão a opção de aprender um único modelo de programação que eles podem usar para criar UIs em qualquer lugar. Isso é importante.
Em um momento em que há muitas discussões em torno da barreira para a entrada no .NET, com tantas opções que novos desenvolvedores para a plataforma têm que enfrentar, Blazor poderia oferecer clareza quando se trata de UI, um único modelo de programação, aprendido uma vez e aplicado em qualquer lugar. Para mim, esse é o hype com Blazor.
O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.
