O boilerplate blazorpost passou pela maior evolução desde a sua criação. São quatro mudanças principais: a autenticação migrou do Google OAuth para o Keycloak (OIDC), os dados corporativos passaram a ser lidos diretamente do MongoDB do ETL, a solução foi modularizada em múltiplos projetos e todo o boilerplate foi atualizado para o .NET 10. A documentação deste site já reflete o estado atual.

Autenticação via Keycloak (OIDC)

O login das soluções deixou de ser feito pela integração direta com o Google OAuth e passou a ser delegado ao Keycloak institucional, por OpenID Connect. Cada aplicação tem o seu próprio client OIDC por ambiente, solicitado via chamado na Central de TI (o roteiro está no item 5 do FAQ).

Junto vieram:

• revinculação transparente das contas migradas — quem já acessava a solução pelo login Google continua acessando normalmente;
• autocadastro de usuários externos, quando habilitado, apoiado em federação externa configurável no realm;
• modal de aviso de expiração de sessão, com tempos configuráveis.

Um efeito colateral importante: integrar outros provedores de identidade (Gov.br, Microsoft Entra, LDAP) passou a ser configuração de realm no Keycloak, e não alteração de código na aplicação.

O controle de autorização continua na própria aplicação, sobre o ASP.NET Core Identity, mas agora é baseado em permissões: o código conhece apenas permissões granulares (Auditoria.Consultar, por exemplo) e o vínculo entre perfil e permissões é gerenciado em tela, no banco. Criar um perfil novo ou mudar o que ele pode fazer virou operação de dados, não de código.

Dados corporativos via MongoDB

O consumo de empregados, unidades, pessoas físicas e jurídicas e localidades deixou de ser feito pelas APIs publicadas no API Gateway e passou a ser feito por conexão direta ao MongoDB do ETL corporativo, somente leitura.

Na aplicação o acesso é sempre indireto, pelos gateways institucionais (IEmpregadosGateway, IUnidadesGateway, IPessoasGateway, ILocalidadesGateway, IFotoEmpregadoGateway) — o código de negócio nunca fala com o MongoDB diretamente. Com isso, o registro do HttpClient autenticado no API Gateway foi removido do boilerplate.

Atenção para soluções fora da Sede: o MongoDB corporativo só é acessível a partir da rede da Sede. Essa configuração padrão atende aos sistemas corporativos desenvolvidos pelo GTI; fora dela, os dados corporativos devem vir 100% das APIs corporativas, e cabe ao desenvolvedor substituir as implementações dos gateways no projeto Integracoes. Como todo o restante da aplicação depende apenas das interfaces, nenhuma página, service ou módulo precisa mudar. O passo a passo está no item 8 do FAQ.

Arquitetura modular

O projeto único deu lugar a uma solution com três projetos — o host Blazor Server, o Core (contratos, auditoria centralizada, modelos institucionais) e o Integracoes (gateways corporativos) — na qual cada módulo de negócio da solução derivada vive em uma Razor Class Library própria, plugada ao host por um único ponto de registro.

A fronteira entre plataforma e domínio passou a ser garantida pelo compilador: um módulo não consegue enxergar os tipos internos do host, e uma violação vira erro de compilação em vez de observação em revisão de código. Cada módulo traz o seu próprio schema de banco, catálogo de permissões, itens de menu, configuração e traduções.

O objetivo prático é permitir que correções e melhorias feitas na base cheguem às soluções derivadas por merge, e não por cherry-pick manual.

Modularizar não é obrigatório — o boilerplate segue funcionando com o domínio escrito diretamente no host. Toda a arquitetura e o guia do desenvolvedor, com as 15 perguntas mais frequentes sobre como construir um módulo, estão na nova seção Modularização.

Migração para o .NET 10

Os dois boilerplates (blazorpost e dotnetapi) foram atualizados para o .NET 10, adotando o formato de solution .slnx e o gerenciamento centralizado de versões de pacote: as versões vivem exclusivamente no Directory.Packages.props, e nenhum .csproj declara Version.

O que muda para quem já tem uma solução no ar

As seguintes variáveis de ambiente deixaram de existir: GOOGLE_CLIENTID, GOOGLE_CLIENTSECRET, API_GATEWAY_URL, API_GATEWAY_USERNAME, API_GATEWAY_PASSWORD, EMPREGADO_API_BASE_PATH e UNIDADE_API_BASE_PATH.

Foram substituídas pelos grupos KEYCLOAK_* (autenticação), MONGO_* (dados corporativos), EMBRAPA_PORTAL_* (foto do empregado) e SESSAO_* (expiração de sessão). A lista completa e comentada está na seção Boilerplates.

Atenção a um ponto: as variáveis do Keycloak são obrigatórias — a aplicação falha no startup se algum placeholder de configuração não for substituído. Isso é proposital, para evitar que uma solução suba com a autenticação mal configurada.

Em caso de dúvida sobre a atualização da sua solução, entre em contato com a equipe de arquitetura (Francisco, Joilton ou Rodrigo).