gerenciamento de estado no servidor do ASP.NET Core Blazor

Persistência do estado do circuito

Durante a renderização do lado do servidor, Blazor Web Apps podem manter o estado de sessão (circuito) de um usuário quando a conexão com o servidor é perdida por um longo período de tempo ou pausada de forma proativa, desde que uma atualização de página inteira não seja iniciada. Isso permite que os usuários retomem a sessão sem perder trabalho não salvo nos seguintes cenários:

• Limitação da guia do navegador
• Usuários de dispositivo móvel trocando de aplicativos
• Interrupções de rede
• Gerenciamento proativo de recursos (pausando circuitos inativos)
• Navegação aprimorada

Os recursos do servidor poderão ser liberados se o estado do circuito puder ser mantido e, em seguida, retomados posteriormente:

• Mesmo se desconectado, um circuito pode continuar a executar o trabalho e consumir CPU, memória e outros recursos. O estado persistente consome apenas uma quantidade fixa de memória que o desenvolvedor controla.
• O estado persistente representa um subconjunto da memória consumida pelo aplicativo, portanto, o servidor não é necessário para acompanhar os componentes do aplicativo e outros objetos do lado do servidor.

O estado é armazenado para dois cenários:

• Estado do componente: estado que os componentes usam para renderização do Servidor Interativo, por exemplo, uma lista de itens recuperados do banco de dados ou um formulário que o usuário está preenchendo.
• Serviços com escopo definido: estado armazenado dentro de um serviço do lado do servidor; por exemplo, o usuário atual.

Condições:

• O recurso só é eficaz para a renderização do Servidor Interativo.
• Se o usuário atualizar a página (aplicativo), o estado persistente será perdido.
• O estado deve ser serializável em JSON. Referências cíclicas ou entidades ORM podem não ser serializadas corretamente.
• Use @key para exclusividade ao renderizar componentes em um loop para evitar conflitos de chave.
• Mantenha somente o estado necessário. Armazenar dados excessivos pode afetar o desempenho.
• Nenhuma hibernação automática. Você deve aceitar e configurar explicitamente a persistência de estado.
• Nenhuma garantia de recuperação. Se a persistência de estado falhar, o aplicativo retornará à experiência desconectada padrão.

O armazenamento de estado fica ativado por padrão quando AddInteractiveServerComponents é chamado AddRazorComponents no arquivo Program. MemoryCache é a implementação de armazenamento padrão para instâncias de aplicativo único e armazena até 1.000 circuitos persistentes por duas horas, que são configuráveis.

Use as opções a seguir para alterar os valores padrão do provedor em memória.

• PersistedCircuitInMemoryMaxRetained (Espaço reservado {CIRCUIT COUNT}): o número máximo de circuitos que devem ser mantidos. O padrão é 1.000 circuitos. Por exemplo, use 2000 para reter o estado por até 2.000 circuitos.
• PersistedCircuitInMemoryRetentionPeriod (espaço reservado {RETENTION PERIOD}): o período máximo de retenção como um TimeSpan. O padrão é duas horas. Por exemplo, use TimeSpan.FromHours(3) para um período de retenção de três horas.

services.Configure<CircuitOptions>(options =>
{
    options.PersistedCircuitInMemoryMaxRetained = {CIRCUIT COUNT};
    options.PersistedCircuitInMemoryRetentionPeriod = {RETENTION PERIOD};
});

O armazenamento do estado do componente entre circuitos é criada sobre a API existente PersistentComponentState, que continua a manter o estado para componentes pré-gerados que adotam um modo de renderização interativo. Para obter mais informações, consulte Persistência de estado prerenderizado no ASP.NET CoreBlazor.

[OBSERVAÇÃO] A persistência do estado do componente para a pré-renderização funciona em qualquer modo de renderização interativa, mas a persistência do estado do circuito só funciona no modo de renderização Servidor Interativo.

Anote as propriedades do componente com o [PersistentState] atributo para habilitar a persistência do estado do circuito. O exemplo a seguir também associa os itens com o atributo de diretiva @key para fornecer um identificador exclusivo para cada instância de componente:

@foreach (var item in Items)
{
    <ItemDisplay @key="@($"unique-prefix-{item.Id}")" Item="item" />
}

@code {
    [PersistentState]
    public List<Item> Items { get; set; }

    protected override async Task OnInitializedAsync()
    {
        Items ??= await LoadItemsAsync();
    }
}

Para persistir o estado dos serviços escopados, anote as propriedades do serviço com o atributo [PersistentState], adicione o serviço à coleção de serviços e chame o método de extensão RegisterPersistentService com o serviço.

public class CustomUserService
{
    [PersistentState]
    public string UserData { get; set; }
}

services.AddScoped<CustomUserService>();

services.AddRazorComponents()
  .AddInteractiveServerComponents()
  .RegisterPersistentService<CustomUserService>(RenderMode.InteractiveAuto);

[OBSERVAÇÃO] O exemplo anterior mantém o estado UserData quando o serviço é usado na pré-geração de componentes para a renderização do Interactive Server e do Interactive WebAssembly, porque RenderMode.InteractiveAuto é atribuído a RegisterPersistentService. No entanto, a persistência do estado do circuito só está disponível para o modo de renderização do Servidor Interativo .

Para lidar com a persistência de estado distribuído (e atuar como o mecanismo de persistência de estado padrão quando configurado), atribua uma HybridCache (API: HybridCache) ao aplicativo, que configura seu próprio período de persistência (PersistedCircuitDistributedRetentionPeriodoito horas por padrão). HybridCache é usado porque fornece uma abordagem unificada para o armazenamento distribuído que não requer pacotes separados para cada provedor de armazenamento.

No exemplo a seguir, um HybridCache é implementado com o provedor de armazenamento Redis :

services.AddHybridCache()
    .AddRedis("{CONNECTION STRING}");

services.AddRazorComponents()
    .AddInteractiveServerComponents();

No exemplo anterior, o espaço reservado {CONNECTION STRING} representa a string de conexão do cache Redis, que deve ser fornecida usando uma abordagem segura, como a ferramenta Gerenciador de Segredos no ambiente ou o Azure Key Vault com Identidades Gerenciadas do Azure para aplicativos implantados no Azure em qualquer ambiente.

Pausar e retomar circuitos

Pause e retome circuitos para implementar políticas personalizadas que melhorem a escalabilidade de um aplicativo.

Pausar um circuito armazena detalhes sobre o circuito no armazenamento do navegador do lado do cliente e remove o circuito da memória, o que libera recursos do servidor. Retomar o circuito estabelece um novo circuito e inicializa-o usando o estado persistente.

De um manipulador de eventos JavaScript:

• Chame Blazor.pause para pausar um circuito.
• Chame Blazor.resume para retomar um circuito.

O exemplo a seguir pressupõe que um circuito não é necessário para um aplicativo que não está visível:

window.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    Blazor.pause();
  } else if (document.visibilityState === 'visible') {
    Blazor.resume();
  }
});

Persistir o estado entre circuitos

Em geral, mantenha o estado entre circuitos em que os usuários estão criando dados ativamente, não simplesmente lendo dados que já existem.

Para preservar o estado entre circuitos, o aplicativo deve persistir os dados em algum outro local de armazenamento que não seja a memória do servidor. A persistência de estado não é automática. Você deve executar etapas ao desenvolver o aplicativo para implementar a persistência de dados com estado.

A persistência de dados normalmente só é necessária para o estado de alto valor que os usuários se esforçaram para criar. Nos exemplos a seguir, a persistência do estado economiza tempo ou ajuda em atividades comerciais.

• Formulários da Web de várias etapas: demora para um usuário inserir dados novamente em várias etapas concluídas de um formulário da Web de várias etapas, se o estado for perdido. Um usuário perderá o estado nesse cenário, se sair do formulário e retornar mais tarde.
• Carrinhos de compras: qualquer componente comercialmente importante de um aplicativo que representa uma possível receita pode ser mantido. Um usuário que perde o estado e, portanto, o carrinho de compras, pode comprar menos produtos ou serviços quando retornar ao site mais tarde.

Um aplicativo só pode persistir o estado do aplicativo. UIs não podem ser persistidas, como instâncias de componentes e suas árvores de renderização. Os componentes e as árvores de renderização geralmente não são serializáveis. Para persistir o estado da interface do usuário, como os nós expandidos de um controle de exibição de árvore, o aplicativo deve usar o código personalizado para modelar o comportamento do estado da interface do usuário como estado serializável do aplicativo.