Forem: DEVz Wiz

Devops #1 - Qualidade x Tempo

Zama Bandeira Braga — Fri, 09 Jul 2021 13:55:25 +0000

O desenvolvimento de software e composto por algumas diferenças históricas, desenvolvimento x operação, qualidade x tempo, expectativa x realidade.

Quando me pergunto sobre a qualidade de um software, me vem a imagem de uma lista de testes executados e todos verdinhos, já para Willian E. Deming em seu livro Qualidade: revolução da administração afirma que, a qualidade tem muitas escalas, por exemplo, um livro de qualidade é determinado pela legibilidade, papel, tamanho, inexistência de erros, ou seja, o leitor deseja encontrar no livro cultura e entretenimento, enquanto a editora deseja encontrar nele, boa oportunidade de venda. A avaliação do que é qualidade dependeria, portanto, das escalas de valor determinadas por cada entidade.

A ISO 900 define a qualidade como a totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas, onde qualidades explícitas são aquelas que o produtor de software garante, explicitamente, ao cliente; enquanto as qualidades implícitas são aquelas subjetivamente esperadas pelo cliente.
As definições de Deming e da ISO convergem para necessidade de percebe-se a existência de duas entidades confrontantes para definição da qualidade, o desenvolvedor como entidade deseja um código entendível, padronizado, de fácil manutenção e que possibilite evoluções. O negócio por sua vez deseja um desenvolvimento rápido e que gere o menor número de reclamações dos clientes.

E como conseguir isso? Como conseguir criar um processo de software que atenda o dev como o negócio? Se alguém souber como me ensina.

As necessidades da área técnica para o desenvolvimento são atendidas com a adoção da filosofia de teste, seja TDD, BDD, etc. As necessidades da área negocial são atendidas também por garantir um menor impacto ao cliente, evitando uma cascata de incidentes após corrigir um, isso tudo porque é possível identificar todo o impacto de uma correção ou evolução da aplicação.

E o Tempo? O teste resolve os questionamentos voltados para o bem estar da aplicação, e não a variável tempo, que é importante para o negócio. Agora inicia-se a batalha do desenvolvimento x tempo. Como garantir que todos os requisitos da qualidade técnica foram atendidos em um tempo curto de desenvolvimento?

E comum ouvir durante uma sala de guerra, "não tivemos tempo de fazer os testes”, não concordo com essa sentença e acho errado vender que é preciso ter tempo para fazer o teste. O teste e a forma de garantir a qualidade da solução desenvolvida, se a minha solução foi desenvolvida em 72 horas (eita lasqueira) os testes são para garantir o que foi desenvolvido nessas 72 horas, nada mais.

A partir do momento em que você inicia um desenvolvimento o orientado a testes, o teste é o seu desenvolvimento. Ele faz parte da sua solução.

Desenvolvedor, pare de falar que não tem tempo para testar! Se você tem tempo de subir a aplicação e consultar via Postman você teve tempo de fazer o teste, o tempo que você abre e fecha a tela do Postman, era um teste desenvolvido.

Negócio, pare de comparar a qualidade de produtos desenvolvidos em diferentes tempos e jogar todas as features como prioritárias! Não faz sentido comparar a qualidade de uma solução desenvolvida em 200 horas com uma solução desenvolvida em 72 horas.

O processo de desenvolvimento de software de qualidade e um gerenciamento das expectativas de tempo com a expectativa de tecnologia. Sommerville diz que, se o sistema é legado você deve evitar ao máximo evoluí-lo, pois ele é um caos! Você não conseguirá rastrear o que é impactado com a alteração, logo se eu não consigo rastrear os impactos de uma alteração, quer dizer que ele não possui requisitos de testes que me possibilitem esse rastreio, levando a conclusão que se a solução não possui teste, ela e uma solução legada.

Hoje você desenvolve uma solução legada ou um produto de qualidade?

Stoplight/Prism-CLI - Acelerando o desenvolvimento e aumentando a integração

Bernardo Costa Nascimento — Thu, 25 Feb 2021 19:29:22 +0000

Ao desenvolver novas APIs, muitas vezes os desenvolvedores (devs) front-end precisam mockar dados para criar e demonstrar os layouts que estão desenvolvendo. É uma atividade que demanda tempo e, eventualmente, o código será jogado fora. No back-end, as features podem demorar algum tempo para estarem disponíveis e, em caso de mudanças, o dev terá de alterar o código, atualizar os testes, realizar uma nova build e um novo deploy, atividades que demandam tempo. Como podemos otimizar as tarefas do back-end e front-end para que não haja código mockado e novo ciclo de dev-build-deploy? Podemos utilizar a ferramenta Stoplight/Prism-CLI.

Prism permite que devs criem mocks da API com uma base mínima de código no back-end, fazendo com que não seja necessária a criação de mocks – que serão, eventualmente, descartados – no front-end. Ainda, torna possível testar o contrato da API, por meio de um proxy, auxiliando na diminuição de erros após mudanças no código. Por fim, como a ferramenta usa o OpenAPI como base para criação dos mocks e proxies, sua utilização auxilia na criação de documentações mais robustas para as APIs desenvolvidas. Este artigo abordará como utilizar a ferramenta em seus dois modos – mock e proxy – para auxiliar, acelerar e integrar o desenvolvimento front-end e back-end.

Sumário

Instalação do @stoplight/prism-cli
Código back-end & OpenAPI Documentation
Prism Mock Server
Prism Proxy Server
Conclusão

Instalação do @stoplight/prism-cli

Antes de mais nada, precisamos instalar a ferramenta Prism em nosso ambiente de desenvolvimento. A documentação prevê três formas de instalação, mas por motivos de simplicidade, abordaremos apenas o primeiro, que utiliza o NPM para realizar a instalação. Dessa forma, instale a ferramenta utilizando o comando:

# Usando NPM
npm i -g @stoplight/prism-cli

# Usando Yarn
yarn add global @stoplight/prism-cli

Código back-end & OpenAPI Documentation

Com o Prism instalado, podemos iniciar o código back-end. O template de APIs da Wiz já traz um exemplo básico de arquitetura de desenvolvimento de uma API e possui o OpenAPI instalado por default.

As rotas do template possuem algumas tags XML e Annotations, que formarão o JSON responsável por gerar a documentação da API. Na Figura 1, a rota apresenta uma descrição (summary), três códigos de resposta (response) e três schemas para os códigos de respostas gerados (ProducesResponseType).

Figura 1 - Tags XML e Annotations para uma rota da API.

Figura 2 - Documentação gerada pelas tags XML e Annotations no código back-end.

Se pararmos aqui, os exemplos de requisição e resposta, gerados pelo OpenAPI, serão genéricos, como visto na Figura 3.

Figura 3 - Exemplo de resposta genérica gerada pelo OpenAPI.

O Prism é capaz de gerar informações aleatórias para compor as respostas, no entanto como veremos mais adiante, é possível ter maior controle sobre o conteúdo das respostas e, por consequência, definir exemplos que documentarão melhor a API em desenvolvimento.

Para isso, adicionaremos tags XML e Annotations nas ViewModels da API e, caso não existam ViewModels específicas para erros, criaremos classes de exemplo para compor a documentação. A Figura 4 demonstra algumas das tags e Annotations utilizadas para melhor documentar a API. É importante ressaltar que, no caso da Annotation JsonSchemaExtensionData, é necessária a instalação do pacote NjsonSchema.Annotations, que permite adicionar informações que não seriam identificadas pelo OpenAPI.

Ao analisar a Figura 4, as tags example e minimum provavelmente são familiares, pois estão previstas na especificação do OpenAPI. Mas e a tag x-faker?

Prism Mock Server

Como dito anteriormente, o Prism é capaz de gerar mocks de respostas para as requisições feitas ao servidor gerado a partir da descrição do OpenAPI. Essas respostas podem ser estáticas ou dinâmicas. Vamos começar pelas respostas estáticas.

Figura 4 - Exemplos de tags para documentação no OpenAPI.

As respostas estáticas são produzidas a partir dos exemplos informados nas ViewModels da API e serão o default ao iniciar o servidor por meio do comando:

prism mock http://localhost:5001/swagger/v1/swagger.json

## Ou

prism mock path/to/descriptor.json

Ao iniciar o mock server dessa maneira, todas as repostas serão baseadas nos exemplos fornecidos. Caso não haja um exemplo, o Prism gera respostas aleatórias com base nos tipos esperados.

No entanto, a utilização das respostas estáticas pode gerar um viés no front-end, uma vez que as respostas, em um cenário real, são variadas. Então, como podemos gerar respostas aleatórias, mas com algum controle sobre seu conteúdo? É aqui que a tag x-faker vai nos ajudar.

Por baixo dos panos, o Prism utiliza a biblioteca Faker.js para gerar os dados de forma aleatória e, acessando a documentação da biblioteca, vemos que existem dezenas de métodos capazes de gerar respostas aleatórias para diversos contextos. Assim, podemos utilizar a tag x-faker, combinada com os métodos disponibilizados pela API, para imprimir contexto nas respostas. Na Figura 4, por exemplo, o “CEP” é gerado com base no método address.zipCode e, portanto, toda resposta não estática vai gerar um zip code aleatório.

Mas ainda fica uma dúvida: caso exista um exemplo, como o mock server pode gerar respostas dinâmicas? Para isso, basta iniciar o mock server com a flag “-d” ou “--dynamic”:

prism mock -d http://localhost:5001/swagger/v1/swagger.json

Ainda, é possível determinar que apenas uma rota específica gere respostas estáticas ou dinâmicas. Para isso, basta passar a utilizar o header “Prefer dynamic=true/false” em suas requisições. O mesmo header pode ser utilizado mais de uma vez e pode ajudar a controlar, também, o código da resposta gerada. Por exemplo, caso o front-end queira testar um cenário de erro na resposta da API, ele pode criar uma requisição com contrato inválido (faltando um campo obrigatório, por exemplo) ou pode utilizar o header “Prefer code=400” para gerar uma resposta com código 400 (Bad Request) por parte do mock server. Para mais exemplos sobre o header, utilize a documentação do Prism.

Prism Proxy Server

Utilizando o mock server, os devs front-end podem ir desenvolvendo os sites sem a necessidade de um back-end funcional, sendo necessário trocar apenas o endereço base das requisições pelo endereço da API funcional, uma vez que esta esteja disponível (i.e. trocar http://localhost:4010/api/vX/ por https://<projeto>-hml-api.azurewebsites.net/api/vX).

Apesar disso, pequenas mudanças ou erros podem ter ocorrido – tanto no front, quanto no back – e as requisições ou os contratos não estarem de acordo com o esperado. Para testar os contratos, o Prism dispõe de um proxy server.

O proxy server utiliza um descritor do OpenAPI e o endereço da API para validar os contratos de requisição e resposta. Dessa maneira, o usuário pode realizar chamadas à API e verificar se todas as requisições feitas e as respostas geradas batem com o que está definido no descritor, garantido que, uma vez que a API vá para produção, front e back não possuam erros de contrato. O proxy server pode ser iniciado pelo comando:

prism proxy path/to/descriptor.json https://<projeto>-hml-api.azurewebsites.net

Para mais informações sobre o proxy server, acesse a documentação do Prism.

Conclusão

A ferramenta Prism server para auxiliar a abordagem “design-first” para o desenvolvimento de APIs por meio do mock e, uma vez que todas as informações e preparativos estejam nas mãos do time de back-end, o proxy permite testar os contratos criados entre front e back.
Sendo assim, o Prism pode auxiliar na integração entre devs front e back, que terão de chegar a um consenso sobre os contratos, permite que o front desenvolva sem a necessidade de uma API e auxilia o back em uma melhor documentação da API em desenvolvimento.

GC: Otimizando para o ambiente do Azure

Pode me chamar de Juscélio Reis — Sun, 07 Feb 2021 15:24:40 +0000

Neste artigo, pretendo abordar um assunto complicado e que pode ser usado para melhorar nossas aplicações hospedados na nuvem da Microsoft Azure. Vou abordar o que exatamente acontece durante a coleta de lixo (GC) e como diferentes modos de GC podem afetar significativamente o desempenho do aplicativo. Mas antes vamos entender qual o ambiente que estamos executando nossas aplicações.

Azure

O que mais consumimos do Azure aqui na Wiz é o serviço de Aplicativo, ou se preferir chamar App Service. Esse serviço quando criado é composto de alguns nomes ou outros serviços. Sendo eles:

App Service Plan (Plano de Serviço de Aplicativo): Um Plano de Serviço de Aplicativo consiste nas máquinas virtuais alocadas que hospedarão os Serviços de Aplicativo do Azure. Possui vários níveis, do Gratuito ao Premium, seu orçamento é o limite. O Plano de Serviço de Aplicativo define a região do servidor físico onde seu aplicativo será hospedado e a quantidade de armazenamento, RAM e CPU que os servidores físicos terão.
App Service (Serviço de Aplicativo): O Serviço de Aplicativo do Azure é um serviço baseado em HTTP para hospedar aplicativos da web, APIs REST e back-ends móveis.
Resource Group (grupo de recursos): Um grupo de recursos é um conjunto que contém recursos relacionados para uma solução do Azure. O grupo de recursos pode incluir todos os recursos da solução ou apenas os recursos que você deseja gerenciar como um grupo.

Agora que temos a nomenclatura do Azure para os serviços de APIs, vamos observas os planos de serviço, ou como aprendemos, vamos olhar nas opções do App Service Plan. Podemos dividir esse plano de serviço em três categorias:

Computação compartilhada: Free ou F1 e Shared, as duas camadas de base, executa um aplicativo na mesma VM do Azure que outros aplicativos de serviço de aplicativo, incluindo aplicativos de outros clientes. Essas camadas alocam cotas de CPU para cada aplicativo executado nos recursos compartilhados, e os recursos não podem ser escalonados. Esse plano possui um limite de tempo e não permite a opção de configurar as apis em dotnet como 64 bits. Esse plano é um grande problema para nossas apis, pois a combinação do dotnet core 3.1 com uma configuração de 32 bits vai resultar em erro de estouro de memória, em outras palavras não usem em ambiente de homologação ou produção.
Computação dedicada: as camadas Basic, Standard, Premium, PremiumV2 e PremiumV3 executam aplicativos em VMs do Azure dedicadas. Somente aplicativos no mesmo App Service Plan compartilham os mesmos recursos de computação. Quanto mais alto o nível, mais instâncias de VM estão disponíveis para você escalar horizontalmente. Essa é a opção que usamos em homologação e produção, em sua grande maioria usamos o plano S1 ou Standard 1, em alguns casos usamos o plano B1 ou Basic, lembrando que não é recomendado pela Microsoft a utilização do plano Basic para produção.
Isolado: esta camada executa VMs do Azure dedicadas em Redes Virtuais do Azure dedicadas. Ele fornece isolamento de rede além do isolamento de computação para seus aplicativos. Ele fornece os recursos de expansão máxima. No momento vamos ignorar esse modo aqui.

Preste atenção aqui

O plano B1 possui 1 núcleo de CPU e 1.75 GB de ram, pode receber até 3 instancias de aplicativos, além de outras limitações do plano Basic. Mais informação aqui.

O plano S1 possui 1 núcleo de CPU e 1.75 GB de ram, mas pode receber até 10 instancias de aplicativos, além de outras limitações do plano Standard. Mais informação aqui.

Bom agora podemos voltar ao tema principal desse artigo garbage collection ou GC pros íntimos.

Garbage Collection

Vou colocar um pequeno resumo do GC aqui, só para entender qual o seu papel no nosso ambiente computacional. Mas será um breve resumo, mais informação ler esse artigo aqui.

O garbage collection (GC) atua como um gerenciador de memória automático. O garbage collection gerencia a alocação e liberação de memória para um aplicativo. O gerenciamento automático de memória pode eliminar problemas comuns, como esquecer de liberar um objeto e causar um vazamento de memória ou tentar acessar a memória de um objeto que já foi liberado.

A coleta de lixo ocorre quando uma das seguintes condições é verdadeira:

O sistema está com pouca memória física. Isso é detectado pela notificação de memória insuficiente do sistema operacional ou memória insuficiente, conforme indicado pelo host.
A memória usada por objetos alocados no heap gerenciado ultrapassa um limite aceitável. Este limite é continuamente ajustado conforme o processo é executado.
O método GC.Collect é chamado. Em quase todos os casos, você não precisa chamar esse método, porque o coletor de lixo é executado continuamente. Este método é usado principalmente para situações e testes únicos.

O algoritmo GC é baseado em várias premissas:

É mais rápido compactar a memória para uma parte do heap gerenciado do que para todo o heap gerenciado.
Objetos mais novos têm vida útil mais curta e objetos mais antigos têm vida útil mais longa.
Objetos mais novos tendem a estar relacionados entre si e acessados pelo aplicativo ao mesmo tempo.

Como vemos a estratégia do GC é dividir o heap em partes considerando a idade dos objetos para otimizar o desempenho, o heap gerenciado é dividido em três gerações, 0, 1 e 2.

Geração 0: Esta é a geração mais jovem e contém objetos de curta duração. Um exemplo de objeto de vida curta é uma variável temporária. A coleta de lixo ocorre com mais frequência nesta geração.
Geração 1: Esta geração contém objetos de vida curta e serve como um buffer entre objetos de vida curta e objetos de vida longa.
Geração 2: Esta geração contém objetos de vida longa. Um exemplo de objeto de longa duração é um objeto em um aplicativo de servidor que contém dados estáticos que estão ativos durante o processo. Mais um motivo para nunca encher nossa aplicação com objetos estáticos.

Objetos que não são recuperados em uma coleta de lixo são conhecidos como sobreviventes e são promovidos para a próxima geração:

Os objetos que sobrevivem a uma coleta de lixo da geração 0 são promovidos para a geração 1.
Os objetos que sobrevivem a uma coleta de lixo da geração 1 são promovidos para a geração 2.
Os objetos que sobrevivem a uma coleta de lixo da geração 2 permanecem na geração 2.

Até aqui podemos entender que os objetos da geração 0 e 1 são os mais voláteis ou como está na documentação são objetos efêmeros. Já os objetos da geração 2 são mais permanentes então não faz tanto sentido fazer uma coleta de lixo completa, podemos focar mais nas gerações 0 e 1 que vamos obter mais sucesso. Mais um motivo para evitar a utilização de objetos estáticos e de tentar chamar o GC.Collect manualmente.

*Estamos chegando na parte de otimização, até aqui foi um grande resumo do resumo para começar o processo de otimização. *

O tamanho do segmento efêmero varia dependendo se um sistema é de 32 ou 64 bits e do tipo de coletor de lixo que está executando (Workstation ou Server GC). A tabela a seguir mostra os tamanhos padrão do segmento efêmero.

Workstation/server GC	32-bit	64-bit
Workstation GC	16 MB	256 MB
Server GC	64 MB	4 GB
Server GC with > 4 logical CPUs	32 MB	2 GB
Server GC with > 8 logical CPUs	16 MB	1 GB

Acabamos de saber que o existem dois tipos de GC, um chamado Workstation GC e outro chamado Server GC. Bora entender esses caras, pois aqui está a chave para a otimização das nossas APIs que estão executando no Azure. Se não entendeu olha o tamanho que elas possuem no ambiente de 64 bits e compara com o tamanho do App Service Plan B1 e S1, vai perceber que a matemática não vai bater.

O GC é inteligente e pode funcionar em uma ampla variedade de cenários. No entanto, podemos definir o tipo de GC com base nas características da carga de trabalho, em outras palavras de acordo com o App Service Plan. O dotnet fornece os seguintes tipos de GC:

Workstation: GC da estação de trabalho, que é projetada para aplicativos cliente. É o padrão do GC para aplicativos independentes. Para aplicativos hospedados, por exemplo, aqueles hospedados pelo ASP.NET, o host determina o padrão do GC. Vai um spoiler vai ser o tipo Server.
Server: GC que se destina a aplicativos de servidor que precisam de alto rendimento e escalabilidade.

Otimização

Aqui é onde vou citar o blog da microsoft, a visão que eles possuíam do ambiente de hospedagem das aplicações dotnet:

Keep in mind that it’s very common to run only one server process on a dedicated machine so you don’t get into this situation.
-- Maoni, Workstation GC for server applications?

Não é o que estamos utilizando no contexto atual, usamos servidores com 1 núcleo e 1.75GB de ram para hospedar de 3 a 10 aplicações. Essa é a questão!!! Precisamos mudar o padrão e utilizar como uma aplicação que vai funcionar na máquina do cliente em outras palavras precisamos sair do Server GC para o Workstation GC. Mas ao começar essa otimização precisamos alterar uma tag no .Api.csproj, vamos colocar a tag *ServerGarbageCollection como false. Mais informação aqui.

Porem ao alterar essa tag precisamos alterar outra ConcurrentGarbageCollection para false, se você está executando várias instâncias de aplicativo, considere o uso do Workstation GC com a coleta de lixo simultânea desabilitada, ConcurrentGarbageCollection false. Isso resultará em menos troca de contexto, o que pode melhorar o desempenho.

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
    <GenerateDocumentationFile>true</GenerateDocumentationFile>
    <IncludeOpenAPIAnalyzers>true</IncludeOpenAPIAnalyzers>
    <ServerGarbageCollection>false</ServerGarbageCollection>
    <ConcurrentGarbageCollection>false</ConcurrentGarbageCollection>
  </PropertyGroup>

Fiz um teste e você pode ver como a combinação de ServerGarbageCollection false com ConcurrentGarbageCollection true aumenta o tempo de processamento.


BenchmarkDotNet=v0.12.1, OS=ubuntu 20.04
Intel Core i7-7500U CPU 2.70GHz (Kaby Lake), 1 CPU, 2 logical cores and 1 physical core
.NET Core SDK=3.1.405
  [Host]                : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  Server                : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  ServerConcurrent      : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  Workstation           : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  WorkstationConcurrent : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT

IterationCount=15  LaunchCount=2  WarmupCount=10

Method	Job	Concurrent	Server	Mean	Error	StdDev	Median	Gen 0	Gen 1	Gen 2	Allocated
WithoutHttpCompletionOption	Server	False	True	428.7 ms	72.57 ms	108.62 ms	428.8 ms	-	-	-	389.94 KB
WithHttpCompletionOption	Server	False	True	483.2 ms	54.60 ms	81.72 ms	516.0 ms	-	-	-	146.13 KB
WithGetStreamAsync	Server	False	True	458.3 ms	63.28 ms	94.72 ms	514.9 ms	-	-	-	146.64 KB
WithoutHttpCompletionOption	ServerConcurrent	True	True	519.6 ms	12.83 ms	17.98 ms	515.4 ms	-	-	-	381.52 KB
WithHttpCompletionOption	ServerConcurrent	True	True	354.8 ms	50.80 ms	72.85 ms	327.6 ms	-	-	-	145.77 KB
WithGetStreamAsync	ServerConcurrent	True	True	490.3 ms	75.63 ms	110.86 ms	516.2 ms	-	-	-	148.85 KB
WithoutHttpCompletionOption	Workstation	False	False	484.2 ms	57.89 ms	83.03 ms	513.9 ms	-	-	-	307.69 KB
WithHttpCompletionOption	Workstation	False	False	432.8 ms	75.27 ms	105.52 ms	508.2 ms	-	-	-	146.98 KB
WithGetStreamAsync	Workstation	False	False	580.9 ms	60.71 ms	87.07 ms	534.8 ms	-	-	-	148.18 KB
WithoutHttpCompletionOption	WorkstationConcurrent	True	False	544.1 ms	61.84 ms	90.64 ms	530.3 ms	-	-	-	307.95 KB
WithHttpCompletionOption	WorkstationConcurrent	True	False	661.8 ms	94.76 ms	132.85 ms	710.2 ms	-	-	-	151.16 KB
WithGetStreamAsync	WorkstationConcurrent	True	False	565.5 ms	129.98 ms	182.21 ms	541.9 ms	-	-	-	143.86 KB

Exemplo

No mês de janeiro uma API começou a ter muitos problemas de estouro de memória, lembrando que essa aplicação está utilizando o plano B1 e não está sozinha no Service Plan. Olha como estava o consumo de memória na época:

Podemos notar que essa api consumia uns 280mb em média, mas teve um pico de 800mb. Depois de aplica essa otimização observe como está o consumo de memória um mês depois:

O consumo de memória não passa de 200mb. Já está rodando a alguns dias e não voltamos a ter problemas com essa API.

O que foi possível observar é uma considerável redução do consumo de memoria e uma aplicação mais estável no Service Plan B1.

Estudos futuros

Existem outras opções que posso alterar, mas como é um assunto bem complicado fica para uma publicação futura. Nem comentei quando estamos trabalhando em um ambiente de container (ex: docker), podemos definir um limite para a heap sem precisar altera o tipo de GC. Caso queriam saber mais, curte esse material:

Referencia

Vou deixar uma lista de conteúdo para você conhecer mais sobre o assunto.

.ltag__user__id__426430 .follow-action-button { background-color: #008000 !important; color: #dce9f3 !important; border-color: #008000 !important; }

Pode me chamar de Juscélio Reis

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

HttpClient: melhoria de performance ao otimizar o uso de memória

Pode me chamar de Juscélio Reis — Thu, 04 Feb 2021 21:37:42 +0000

Neste último mês fiquei investigando incidentes relacionados a alto consumo de memória por parte das nossas aplicações. Consegui encontrar alguns problemas e quero compartilhar com vocês, vamos começar com a utilização do HttpClient, esse cara pode ser um vilão se não for bem utilizado. As APIs da Wiz têm uma característica de chamar outras APIs e me atrevo a dizer que é mais consumo de API do que utilização de banco de dados. Nesse artigo quero explicar como você pode otimizar o desempenho do HttpClient ao lidar com dados como cargas úteis JSON no HttpResponseMessage.

Teoria

O que eu não sabia era que por padrão, na maioria dos casos, ao usar HttpClient e seus metodos (GetAsync, PostAsync e SendAsync), todo o corpo da resposta é lido em um buffer de memória antes que o método seja concluído. Nesse ponto, a conexão TCP, usada para a solicitação fica inativa e estará disponível para reutilização para outra solicitação, um ponto aqui é que estou falando do dotnet core 3.1, se for falar do dotnet 5, existem opções melhores como é o caso da utilização do protocolo http2, aí a história é outra.

Na maioria dos casos esse comportamento é aceitável, já que evita o uso da conexão tcp pelo período mínimo de tempo necessário. Mas... em casos que não temos memória sobressalente, aí entramos no caminho infeliz da história pois essa abordagem padrão introduz alguma sobrecarga de memória. Já que a resposta da API, vou generalizar aqui, o JSON é armazenado em buffer usando um MemoryStream, podemos acessar esse buffer pela classe HttpResponseMessage. Dependendo do tamanho da carga de resposta, isso pode significar que armazenamos em buffer uma grande quantidade de dados na memória.

Solução

O que eu não sabia era que existe uma sobrecarga desses métodos esperando um enum HttpCompletionOption, esse enum possui 2 valores o padrão é o ResponseContentRead, esse aí informa para o HttpClient que é para ler o corpo do JSON e colocar em memória mesmo que a nossa aplicação não vai usar esse objeto, sim isso é possível. O segundo valor é o que iremos começar a utilizar aqui na Wiz chamado ResponseHeadersRead, esse cara indica para o HttpClient quando os cabeçalhos de resposta forem totalmente lidos. O corpo da resposta pode não ser totalmente recebido neste momento.

O principal benefício é o desempenho. Ao usar esta opção, evitamos o buffer MemoryStream intermediário, em vez de obter o conteúdo diretamente do fluxo exposto no Socket. Isso evita alocações desnecessárias, o que é uma meta em situações altamente otimizadas.

Aqui vai um exemplo, quero serializar uma lista de livros apenas quando receber um status code 200. Se eu receber um 500 vou lançar uma exception e não preciso do conteúdo da API que estou consumindo.

A forma de utilizar esse enum é bem simples, olha como fica:

_httpClient.GetAsync("http://openlibrary.org/search.json?q=tdd", HttpCompletionOption.ResponseHeadersRead);

O normal é analisar o conteúdo de alguma forma. Vou mostrar um código de como podemos escrever nossa chamada para isso.

using var response = await _httpClient.GetAsync("http://openlibrary.org/search.json?q=tdd", HttpCompletionOption.ResponseHeadersRead);

response.EnsureSuccessStatusCode();

if (response.Content is object)
{
      var stream = await response.Content.ReadAsStreamAsync();

      var data = await JsonSerializer.DeserializeAsync<Search>(stream);

      // do something with the data or return it
}

Usamos o EnsureSuccessStatusCode para garantir que o status code recebido é um 2xx. Em caso afirmativo, verificamos se há conteúdo disponível na resposta. Agora podemos acessar o fluxo do conteúdo de resposta usando ReadAsStreamAsync.

O problema dessa abordagem é que assumimos mais responsabilidade em relação aos recursos do sistema, uma vez que a conexão com o servidor remoto fica presa até decidirmos que terminaremos com o conteúdo. A maneira como sinalizamos isso é descartando o HttpResponseMessage, que então libera a conexão para ser usada para outras solicitações. Por isso não esquecer do using.

using var response = await _httpClient.GetAsync

Outra forma de garantir isso é usar o try/finaly, veja um exemplo:

var response = await _httpClient.GetAsync("http://openlibrary.org/search.json?q=tdd", HttpCompletionOption.ResponseHeadersRead);

response.EnsureSuccessStatusCode();

Search data = null;

try
{

      if (response.Content is object)
      {
            var stream = await response.Content.ReadAsStreamAsync();
            data = await JsonSerializer.DeserializeAsync<Search>(stream);
      }
}
finally
{
      response.Dispose();
}

if (data is object)
{
      // intensive and slow processing of books list. We don't want this to delay releasing the connection.
}

Estudo de caso

Fiz um programa de teste para ter um benchmark da performance do que citei nesse artigo. Essa analise é feita tanto no Windows como no Linux, usando o dotnet core 3.1. Vocês podem acessar aqui.

Observe a coluna Allocated, usando um sistema Windows com o método WithHttpCompletionOption chegamos a uma performance de 26,87% em comparação com WithoutHttpCompletionOption que representa 73,13% do consumo de memória.

Agora usando um sistema Linux com o método WithHttpCompletionOption chegamos a uma performance de 28,62% em comparação com o método WithoutHttpCompletionOption que representa 71,38% do consumo de memória.

Windows


BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
Intel Core i7-7500U CPU 2.70GHz (Kaby Lake), 1 CPU, 4 logical and 2 physical cores
.NET Core SDK=3.1.404
  [Host]           : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  Server           : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  ServerForce      : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  Workstation      : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  WorkstationForce : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT

IterationCount=15  LaunchCount=2  WarmupCount=10

Method	Job	Force	Server	Mean	Error	StdDev	Median	Gen 0	Gen 1	Gen 2	Allocated
WithoutHttpCompletionOption	Server	False	True	477.6 ms	65.79 ms	96.43 ms	515.4 ms	-	-	-	404.48 KB
WithHttpCompletionOption	Server	False	True	673.4 ms	73.56 ms	103.12 ms	723.6 ms	-	-	-	162.16 KB
WithGetStreamAsync	Server	False	True	703.2 ms	149.15 ms	213.91 ms	662.3 ms	-	-	-	162.66 KB
WithoutHttpCompletionOption	ServerForce	True	True	414.7 ms	65.04 ms	93.27 ms	363.7 ms	-	-	-	394.98 KB
WithHttpCompletionOption	ServerForce	True	True	642.0 ms	81.61 ms	106.12 ms	642.8 ms	-	-	-	163.63 KB
WithGetStreamAsync	ServerForce	True	True	707.8 ms	97.39 ms	139.68 ms	727.4 ms	-	-	-	162.81 KB
WithoutHttpCompletionOption	Workstation	True	False	659.7 ms	96.77 ms	132.46 ms	643.2 ms	-	-	-	394.62 KB
WithHttpCompletionOption	Workstation	True	False	530.2 ms	9.43 ms	12.59 ms	528.1 ms	-	-	-	162.35 KB
WithGetStreamAsync	Workstation	True	False	439.2 ms	65.54 ms	98.10 ms	452.9 ms	-	-	-	161.59 KB
WithoutHttpCompletionOption	WorkstationForce	False	False	499.3 ms	52.65 ms	77.17 ms	517.6 ms	-	-	-	394.89 KB
WithHttpCompletionOption	WorkstationForce	False	False	626.4 ms	69.05 ms	94.52 ms	600.1 ms	-	-	-	162.98 KB
WithGetStreamAsync	WorkstationForce	False	False	508.5 ms	57.64 ms	82.67 ms	524.8 ms	-	-	-	162.39 KB

Linux


BenchmarkDotNet=v0.12.1, OS=ubuntu 20.04
Intel Core i7-7500U CPU 2.70GHz (Kaby Lake), 1 CPU, 2 logical cores and 1 physical core
.NET Core SDK=3.1.405
  [Host]           : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  Server           : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  ServerForce      : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  Workstation      : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  WorkstationForce : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT

IterationCount=15  LaunchCount=2  WarmupCount=10

Method	Job	Force	Server	Mean	Error	StdDev	Median	Gen 0	Gen 1	Gen 2	Allocated
WithoutHttpCompletionOption	Server	False	True	426.4 ms	73.53 ms	100.64 ms	409.1 ms	-	-	-	389120 B
WithHttpCompletionOption	Server	False	True	360.1 ms	53.91 ms	77.31 ms	331.1 ms	-	-	-	152472 B
WithGetStreamAsync	Server	False	True	328.8 ms	12.37 ms	17.74 ms	323.7 ms	-	-	-	149624 B
WithoutHttpCompletionOption	ServerForce	True	True	421.0 ms	71.88 ms	103.09 ms	426.8 ms	-	-	-	406960 B
WithHttpCompletionOption	ServerForce	True	True	515.3 ms	71.17 ms	104.32 ms	520.8 ms	-	-	-	149936 B
WithGetStreamAsync	ServerForce	True	True	525.4 ms	142.11 ms	203.81 ms	515.6 ms	-	-	-	150136 B
WithoutHttpCompletionOption	Workstation	True	False	NA	NA	NA	NA	-	-	-	-
WithHttpCompletionOption	Workstation	True	False	523.6 ms	94.41 ms	138.38 ms	515.3 ms	-	-	-	149520 B
WithGetStreamAsync	Workstation	True	False	582.9 ms	288.63 ms	404.62 ms	354.0 ms	-	-	-	150072 B
WithoutHttpCompletionOption	WorkstationForce	False	False	523.4 ms	44.34 ms	62.16 ms	527.0 ms	-	-	-	389112 B
WithHttpCompletionOption	WorkstationForce	False	False	523.0 ms	11.63 ms	16.68 ms	518.3 ms	-	-	-	150680 B
WithGetStreamAsync	WorkstationForce	False	False	427.7 ms	78.15 ms	104.33 ms	497.9 ms	-	-	-	151472 B

Pode me chamar de Juscélio ReisFollow

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

Teste de integração com SqlServer e Azure Devops

Tiago Brito — Thu, 17 Dec 2020 12:54:29 +0000

Há poucos dias atrás fiz uma implementação para integrar meus testes com o Sql Server.

Motivação

O que me levou a escrever esse tipo de teste foi:

Quero escrever um testes que seja o mais aderente ao ambiente de produção - ou seja, se vai rodar em Sql Server – tenho que escrever um testes que rode em Sql Server
Quero testar consultas mais complexas;
Quero testar cada método da minha classe de repositório, com cenário próprio, sem precisar rodar o sistema inteiro para fazer realizar este teste;
Possibilidade de testes transacionais

Para rodar os testes segui os seguintes passos:

Montei um Sql Server em um container;
Escrevi um código para criação da estrutura de banco, cenário e execução dos teste de repositórios;
Escrevi os testes propriamente ditos;
Configurei o pipeline do Azure para subir uma instância do Sql Server em tempo de build antes de rodar os testes integrados com repositórios.

Exemplo do método de repositório que quero testar

public async Task<IEnumerable<User>> GetByEmailAsync(string email) 
{ 
     var query = @" 
SELECT  
      u.Id, u.FirstName, u.LastName, u.PersonalIdentificationNumber, 
      u.Email, u.ProfileCode, u.DateCreated 
FROM  
          [dbo].[User] u                 
WHERE  
    u.Email = @Email 
    AND u.TenantId = @TenantId"; 

    return await _dapperContext.DapperConnection 
                   .QueryAsync<User>( 
                        query, new { Email = email, TenantId = this.TenantId() }); 
}

SqlServer no meu ambiente de desenvolvimento

Criei um container (docker) para instância do Sql Server. Para subir o Sql Server disponibilizo meu docker-compose que utilizei para inicialização do container;

Meu sistema operacional é o Windows então, utilizei o docker for windows disponível Aqui

Salve um arquivo em alguma pasta no seu computador com esse conteúdo. No meu ambiente, salvei aqui [C:_devz\dockers\sqlserver]

docker-compose.yml

version: '3' 

services: 
    db: 
        image: mcr.microsoft.com/mssql/server:2017-latest-ubuntu 
        environment: 
            SA_PASSWORD: "Q1w2e3r4!" 
            ACCEPT_EULA: Y 
            MSSQL_PID: Express 
        ports: 
            - "1433:1433" 
        volumes: 
            - mssql-volume:/var/lib/mssql 
        networks: 
            - mssql_docknet            
networks: 
    mssql_docknet: 
        driver: bridge                
volumes: 
    mssql-volume:

Para executar o container, execute no prompt como abaixo:

> cd C:\_devz\Dockers\sqlserver [Esse é o local onde está o docker-compose.yml] 

> docker-compose up –d

Código para estrutura e conexão com banco de dados

Para que meu teste funcionasse precisei de uma instância do Sql Server funcionando - instância que configurei acima;

Para ter cenários e testes independentes, antes que os testes fossem executados:

Criei uma classe de contexto compartilhado que o xunit disponibiliza;
Esse contexto cria o banco de dados;
Esse contexto cria as tabelas configuradas no Entity;

[CollectionDefinition("DatabaseTestCollection")] 
public class DatabaseCollection : ICollectionFixture<DatabaseFixture> 
{ 
}

Com essa classe eu defini um contexto global para todos os meus testes. Essa classe é assim mesmo - não tem código nenhum em seu corpo.

Na classe DatabaseFixture tenho as informações do banco de dados e a inicialização do banco;

Nesta classe configurei as informações do Entity e do Dapper;
Com essas informações, meu banco de dados de teste é criado;

public DapperContext _dapper; 
public IConfiguration _configuration; 

public DatabaseFixture() 
{ 
////minha string de conexão que se conecta com o container montado
    var connectionString = $"Server=localhost;Database=gamificacao_test;User ID=sa;Password=Q1w2e3r4!;Trusted_Connection=False;"; 

////Adicionei algumas configurações para rastrear problemas de banco ao rodar meus testes
    ContextOptions = new DbContextOptionsBuilder<EntityContext>() 
                        .UseSqlServer(connectionString) 
                        .EnableSensitiveDataLogging() 
          .UseLoggerFactory(LoggerFactory.Create(builder => { builder.AddDebug(); })) 
                        .Options; 

////Como se trata de um cenário de testes algumas coisas coloquei em memória por não ser relevante para o testes
    var myConfiguration = new Dictionary<string, string> 
    { 
        { "ConnectionStrings:GamificacaoDB", connectionString } 
    }; 

    _configuration = new ConfigurationBuilder() 
        .AddInMemoryCollection(myConfiguration) 
        .Build(); 

    IdentityServiceMock = new Mock<IIdentityService>(); 
    IdentityServiceMock.Setup(x => x.GetTenantId()) 
        .Returns("Wx1"); 

    Context = new EntityContext(ContextOptions, IdentityServiceMock.Object); 

    _dapper = new DapperContext(_configuration); 

    //// Cria o meu banco de testes
    InitializeDatabase();
} 

////Repositorios da minha API que pretendo testar
public ActionRepository ActionRepository {  

    get { return new ActionRepository(Context, _dapper, IdentityServiceMock.Object); } } 

public UserRepository UserRepository {  

    get { return new UserRepository(Context, _dapper, IdentityServiceMock.Object); } } 

protected virtual void InitializeDatabase() 
        { 
            using (var context = new EntityContext(ContextOptions, IdentityServiceMock.Object)) 
            { 
                context.Database.EnsureDeleted(); 
                context.Database.EnsureCreated(); 
            } 
        }

O repositório que pretendo testar

Estou testando o repositório de usuários (UserRepository). O método em questão está utilizando Dapper e minha consulta é muito simples.

public async Task<IEnumerable<User>> GetByEmailAsync(string email) 
{ 
     var query = @" 
SELECT  
      u.Id, u.FirstName, u.LastName, u.PersonalIdentificationNumber, 
      u.Email, u.ProfileCode, u.DateCreated 
FROM  
          [dbo].[User] u                 
WHERE  
    u.Email = @Email 
    AND u.TenantId = @TenantId"; 

    return await _dapperContext.DapperConnection 
                   .QueryAsync<User>( 
                        query, new { Email = email, TenantId = this.TenantId() }); 
}

O Teste

Quando a instância do SqlServer iniciou não tenho nenhuma informação nas tabelas para executar os testes. Então, preciso criar esses dados. Para isso, utilizei as mesmas classes de criação de objetos que já temos em nossa estrutura. Veja no teste abaixo: Criei 1 Usuário.

Para o contexto dos testes criei um método estendido para as entidades. Nesse método consigo inserir no banco de dados o que está na entidade. Isso facilita inclusão de dados nas tabelas sem a necessidade de chamar o repositório para inserir.

public static class EntityExtensions 
{ 
    public static T Persist<T>( 
           this T entity,  
           EntityContext context) where T : class 
    { 
        context.Add(entity); 
        context.SaveChanges(); 

        return entity; 
    } 
}

Então, na linha onde temos user.Persist(_databaseFixture.Context) a tabela User será persistida.

O mesmo aconteceria com outros objetos onde chamando o .Persist().

[Fact] 
public async Task GetByMail_TestAsync() 
{ 
    //Cenario 
    var tiago = new Domain.Models.User 
    { 
        Email = "tiagobrito@wizsolucoes.com.br", 
        FirstName = "Tiago", 
        LastName = "Brito", 
        ProfileCode = "A", 
        PersonalIdentificationNumber = "15476338731" 
    }; 

    tiago.Persist(_databaseFixture.Context); 

    //Execução 
    var userToCompare = await _databaseFixture.UserRepository                                 .GetByEmailAsync("tiagobrito@wizsolucoes.com.br"); 

     ///Validação 
    userToCompare.ElementAt(0).FirstName.Should().Be("Tiago"); 
    userToCompare.ElementAt(0).LastName.Should().Be("Brito"); 
}


 var userToCompare = await _databaseFixture.UserRepository                           .GetByEmailAsync("tiagobrito@wizsolucoes.com.br");

Na linha acima temos a execução do repositório. Nesta etapa, todos os meus dados já estão persistidos e, se alimentei as tabela corretamente e minha classe de repositório estiver com a consulta correta, os dados virão. Estamos testando apenas essa unidade. Fica bem simples e não preciso rodar o sistema inteiro.

Para validar os retornos utilizamos o que já conhecemos

Eu utilizo uma biblioteca para assert fluente – considero que a leitura do teste fica bem legal. pode ser encontrada Aqui

userToCompare.ElementAt(0).FirstName.Should().Be("Tiago"); 
userToCompare.ElementAt(0).LastName.Should().Be("Brito");

Configuração do pipeline para testes de integração com Sql Sever no Azure

Como mencionado no primeiro tópico, utilizo um container para subir uma instancia do Sql Server Express e realizar os testes. No Azure Devops fiz o mesmo: no arquivo azure-pipelines.yml do projeto descrevi o recurso que precisava nas extensões, segundo o novo modelo de pipeline, identifiquei o serviço que vou utilizar. No caso, o Sql Server.

# ASP.NET Core
# Build a Web project that uses ASP.NET Core.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core
# YAML reference:
# https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema

variables: 
    azResourceName: 'meu-projeto'

resources:
  repositories:
    - repository: dotnettemplate
      type: git  
      name: meurepositorio/modelos
      ref: refs/tags/v1.1
  containers:
  - container: mssql
    image: mcr.microsoft.com/mssql/server:2017-latest-ubuntu
    ports: 
      - 1433:1433
    options: -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=Q1w2e3r4!' -e 'MSSQL_PID=Express'

pool:
  vmImage: 'ubuntu-latest'

schedules:
  - cron: "0 0 * * *"
    displayName: Build Noturno
    always: true
    branches:
      include:
        - master

trigger:
  batch: true
  paths:
    exclude:
    - README.md

stages:
- stage: Build
  pool: Wiz Hosted Ubuntu 1604
  jobs:
    - job:
      continueOnError: true
      services:
        localhostsqlserver: mssql
      steps:
          #Essas linhas com powershell são apenas para testes. podem ser removidas
        - task: PowerShell@2
          displayName: 'delay 10'
          inputs:
            targetType: 'inline'
            script: |
              # Write your PowerShell commands here.
              start-sleep -s 10
        - task: CmdLine@2
          inputs:
            script: 'sqlcmd -S localhost -d master -U sa -P Q1w2e3r4! -Q "SELECT @@version;"'
         #Esse template compila aplicações .net
        - template: dotnetcore.yml@dotnettemplate
- stage: Uat
  condition: and(succeeded(), or(contains(variables['Build.SourceBranch'], 'master'), contains(variables['Build.SourceBranch'], 'releases')))
  dependsOn: [Build]
  jobs:
    - deployment: 
      environment: staging
      strategy:
        runOnce:
          deploy:                              
            steps:
            - task: AzureRmWebAppDeployment@4
              displayName: Publish 
              inputs:
                ConnectionType: 'AzureRM'
                azureSubscription: 'xxx'
                appType: 'webApp'
                WebAppName: '$(azResourceName)-hml-api'
                packageForLinux: '$(Pipeline.Workspace)/drop/**/*.zip'

O YML abaixo é bem simplificado e é o que utilizamos na Wiz. Isso porque nossa equipe de governança trabalhou algum tempo para torná-lo simples assim.


resources: 
  repositories: 
  - repository: coretemplate 
    type: git 
    name: meu/repositorio 

  containers: 
  - container: mssql 
    image: mcr.microsoft.com/mssql/server:2017-latest-ubuntu 
    env: 
      ACCEPT_EULA: Y 
      SA_PASSWORD: Q1w2e3r4! 
      MSSQL_PID: Express 
    ports:  
      - 1433:1433 
    options: --name mssql 

pool: 
  vmImage: 'ubuntu-latest' 

schedules: 
  - cron: "0 0 * * *" 
    displayName: Build Noturno 
    always: true 
    branches: 
      include: 
        - master 
trigger: 
  batch: true 
  paths: 
    exclude: 
    - README.md 

extends: 
  template: main.yml@coretemplate 
  parameters: 
    technology: 'dotnetcore' 
    dotnetcoreAppType: 'apiApp' 
    azResourceName: 'gamificacao' 
    azSubscriptionUAT: 'xxx' 
    azSubscriptionPRD: 'xxx' 
    dotnetcoreDotNetVersion: '3.x' 
    dotnetcoreBuildProject: '**/*[API].csproj' 
    dotnetcoreBuildConfiguration: Release 
    dotnetcoreTestProject: '**/*[Tt]ests/*.csproj' 
    dotnetcoreNugetFeed: 09b2821a-2950-4eff-a722-dbc8adf4da55 
    buildServices: 
      mssql: mssql 
    releaseServices: 
      mssql: mssql

No Azure podemos visualizar os resultados

[Série] Governança de API: Contrato da API

Pode me chamar de Juscélio Reis — Wed, 05 Aug 2020 19:35:57 +0000

Recapitulando:

A área de governança precisa cruzar o anseio e desejos dos outros setores da empresa, com o objetivo de construir uma ponte entre o momento atual da empresa com o que pode acabar sendo uma futura estratégia de governança de API.

É clichê, mas resumindo fica assim: a área de governança busca alinhar a estratégia com a execução.

😒: Todo novo framework da moda tem essa frase. Como é possível esse alinhamento com a governança?

O monitoramento do desempenho passado é útil na avaliação de opções no momento presente, para determinar metas, políticas e ações futuras (direção). 😎

Aqueles que não conhecem a história estão fadados a repeti-la.
-- Edmund Burke

Como vai conseguir monitorar o passado se não sabe o que monitorar? No catalogo de API precisa existir no mínimo 4 informações, sendo elas o recurso, a estrutura, a capacidade e a sensibilidade. Logo ter um catalogo de API é o primeiro passo para o sucesso!

Para recapitular pode ir direto na fonte:

[Série] Governança de API

Pode me chamar de Juscélio Reis for DEVz Wiz ・ Jul 21 '20

#api #governance #development #devops

[Série] Governança de API: Centralização

Pode me chamar de Juscélio Reis for DEVz Wiz ・ Jul 28 '20

#api #governance #development #devops

O contrato da API: o primeiro e mais importante passo

Sem duvidas aqui é o ponto mais importante e mais complicado de ser feito, mas quando bem feito só temos ganhos. Para entender mais o motivo de começar com o contrato leia esse artigo:

Por que devemos começar nossas APIs pelo contrato?

Pode me chamar de Juscélio Reis ・ Jul 13 '20

#apidevelopment #openapi #apigovernance

Em um programa de desenvolvimento de API a primeira etapa é justamente a construção de um contrato. Com um contrato bem feito conseguimos automatizar rotinas, melhorar a experiência do desenvolvedor, permitir a independência dos times, acelerar a entrega das APIs para o mercado, melhora o entendimento das suas APIs, facilitar a rotina de testes 👻, gerar SDKs tanto para o cliente quanto para o servidor (ação automatizada é claro), possibilidade de ativar e desativar suas APIs e como não podia deixar de ser, monitorar o passado!

😒: o mundo real não é assim, ninguém para para criar contratos. O que o gestor quer é código em produção. Contrato, só se for contrato com um cliente pagante.

É uma visão bem comum, se você for direto para a criação de sua API, não haverá retorno ao design. É como construir uma casa e depois procurar um arquiteto para elaborar planos. Isso não faz nenhum sentido. 😎

No entanto, as equipes de software frequentemente fazem escolhas semelhantes. Eles podem gerar uma especificação de API a partir do código, o que parece eficiente. Infelizmente, quando você criou uma API no código, perdeu muitas das vantagens da abordagem do design primeiro. Quando o design da sua API existe antes da implementação, você pode obter feedback antecipado, conectar sua API às ferramentas desde o início e colaborar entre departamentos e funções. 😎

Colocar ordem no caos é uma tarefa árdua, ou exigir que desenvolvedores sigam um método que não seja o eXtreme Go Horse (XGH). Mas é necessário dar o primeiro passo. Assim também é implantar um programa de API, tenha em mente qual resultado deseja obter, e não foque no tamanho do percurso.

Suba o primeiro degrau com fé. Não é necessário que você veja toda a escada. Apenas dê o primeiro passo.
-- Martin Luther King

Você sabe quem usará sua API? Mesmo para um projeto interno, é provável que você tenha vários consumidores. Uma especificação de API permite que você compartilhe detalhes sobre como a API funcionará. Você pode enviar o documento de especificação em si ou usar ferramentas para criar um protótipo de sua API ou documentação. Você pode gerar servidores simulados com base em suas especificações, conforme descrito em outra seção, e fazer com que seus consumidores façam chamadas ao vivo.

Sua colaboração também pode ir além das equipes técnicas. Você pode obter ótimas informações sobre produtos, marketing, parcerias e muitas outras áreas da sua organização.

🙋‍♂️: Eu ouvi um amém irmãos?! 🙌🙌

O software raramente é construído inteiramente por desenvolvedores. Existem partes interessadas em toda a organização. E embora muitos desenvolvedores possam ter muita atenção ao produto, eles nem sempre têm a visibilidade da imagem completa. Se sua organização possui um grupo de produtos, é nesse ponto que a voz do cliente é mais ouvida. Envolva qualquer pessoa que entenda como uma API será usada nas discussões ao criar a API.

Quando você entender como o software será usado, poderá projetá-lo melhor. O maior erro no design da API é tomar decisões com base em como o sistema funciona, e não no que os consumidores precisam oferecer suporte. Para projetar casos de uso, você precisa conversar com os consumidores ou, pelo menos, incluir aqueles que os conhecem melhor.

Uma sugestão de ferramenta que faz muito bem esse papel e para melhorar seu dia é gratuita Stoplight Studio

stoplightio / studio

The modern editor for API Design and Technical Writing.

Stoplight Studio

Studio is Stoplight's next generation application for API design, modeling, and technical writing. A primary goal of Studio is to enrich, not replace, your existing workflows. When running locally it works fully offline, with folders and files on your computer just like your favorite IDE. When running in the browser, the web-native Git support allows you to effortlessly work with your existing repositories safely and efficiently.

Documentation

To learn more about Studio and the Stoplight platform, see our Platform Documentation.

Features

Full Support for OpenAPI v2 and v3

Studio comes with full support for the OpenAPI versions 2 and 3 specification formats for all functionality. That means full validation, mocking, and modeling support for both versions of the OpenAPI specification.

Graphical API Design

Form-based designing means you don't need to be an OpenAPI expert to get started. Studio has a "write" (code) mode with full OpenAPI autocomplete…

View on GitHub

Para gerar um mock desse contrato criado pelo Stoplight Studio é possível usar Prism na linha de comando e entregar esse mock para o dev front-end.

stoplightio / prism

Turn any OpenAPI2/3 and Postman Collection file into an API server with mocking, transformations and validations.

Prism Overview

Prism is a set of packages for API mocking and contract testing with OpenAPI v2 (formerly known as Swagger) and OpenAPI v3.x.

Prism provides:

Mock Servers: Life-like mock servers from any API specification document.
Validation Proxy: Contract Testing for API consumers and developers.
Comprehensive API Specification Support: OpenAPI v3.1, OpenAPI v3.0, OpenAPI v2.0 (formerly Swagger) and Postman Collections.

Ways to Use Prism

Hosted Prism

Stoplight provides hosted mock servers for convenience so that API consumers can experiment with an API without the need for backend code.

Use one of these options for instant, hosted mock servers:

Stoplight Platform: Collaborative API Design Platform for designing, developing and documenting APIs with hosted mocking powered by Prism.
Stoplight Studio: Free visual OpenAPI designer that comes integrated with mocking powered by Prism.

Learn more in the hosted Prism documentation.

Self-hosted Prism

Prism is an open-source…

View on GitHub

🧙: Já temos o contrato e o mock da API, que tal criar um código de API para rodar no servidor usando 1 linha de comando? Te apresento meu amigo, Openapi Generator

😒: Da onde ele veio?

🧙: Do github

😒: O que ele faz?

🧙: Gera SDK, código do desenvolvedor e documenta tudo. O melhor amigo do Dev SAGAZ.

OpenAPITools / openapi-generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)

OpenAPI Generator

Master (7.10.0)

⭐⭐⭐ If you would like to contribute, please refer to guidelines and a list of open tasks. ⭐⭐⭐

‼️ To migrate from Swagger Codegen to OpenAPI Generator, please refer to the migration guide ‼️

📔 For more information, please refer to the Wiki page and FAQ 📔

📔 The eBook A Beginner's Guide to Code Generation for REST APIs is a good starting point for beginners 📔

⚠️ If the OpenAPI spec, templates or any input (e.g. options, environment variables) is obtained from an untrusted source or environment, please make sure you've reviewed these inputs before using OpenAPI Generator to generate the API client, server stub or documentation to avoid potential security issues (e.g. code injection). For security vulnerabilities, please contact team@openapitools.org. ⚠️

‼️ Both "OpenAPI Tools" (https://OpenAPITools.org - the parent organization of OpenAPI Generator) and "OpenAPI Generator" are not…

View on GitHub

CLIENT generators

ada
android
apex
bash
c
clojure
cpp-qt5-client
cpp-restsdk
cpp-tizen
cpp-ue4 (beta)
csharp
csharp-dotnet2 (deprecated)
csharp-netcore
dart
dart-dio
dart-jaguar
eiffel
elixir
elm
erlang-client
erlang-proper
flash
go
go-experimental (experimental)
groovy
haskell-http-client
java
javascript
javascript-apollo (beta)
javascript-closure-angular
javascript-flowtyped
jaxrs-cxf-client
jmeter
k6 (beta)
kotlin
lua (beta)
nim (beta)
objc
ocaml
perl
php
powershell (beta)
python
python-experimental (experimental)
r
ruby
rust
scala-akka
scala-gatling
scala-httpclient-deprecated (deprecated)
scala-sttp (beta)
scalaz
swift4-deprecated (deprecated)
swift5 (beta)
typescript (experimental)
typescript-angular
typescript-angularjs-deprecated (deprecated)
typescript-aurelia
typescript-axios
typescript-fetch
typescript-inversify
typescript-jquery
typescript-node
typescript-redux-query
typescript-rxjs

SERVER generators

ada-server
aspnetcore
cpp-pistache-server
cpp-qt5-qhttpengine-server
cpp-restbed-server
csharp-nancyfx
erlang-server
fsharp-functions (beta)
fsharp-giraffe-server (beta)
go-gin-server
go-server
graphql-nodejs-express-server
haskell
java-inflector
java-msf4j
java-pkmst
java-play-framework
java-undertow-server
java-vertx
java-vertx-web (beta)
jaxrs-cxf
jaxrs-cxf-cdi
jaxrs-cxf-extended
jaxrs-jersey
jaxrs-resteasy
jaxrs-resteasy-eap
jaxrs-spec
kotlin-server
kotlin-spring
kotlin-vertx (beta)
nodejs-express-server (beta)
php-laravel
php-lumen
php-silex-deprecated (deprecated)
php-slim-deprecated (deprecated)
php-slim4
php-symfony
php-ze-ph
python-aiohttp
python-blueplanet
python-flask
ruby-on-rails
ruby-sinatra
rust-server
scala-akka-http-server (beta)
scala-finch
scala-lagom-server
scala-play-server
scalatra
spring

DOCUMENTATION generators

asciidoc
cwiki
dynamic-html
html
html2
markdown (beta)
openapi
openapi-yaml
plantuml (beta)

SCHEMA generators

avro-schema (beta)
mysql-schema

CONFIG generators

apache2
graphql-schema
protobuf-schema (beta)

Que tal dar o primeiro passo? Se esta na duvida olha essa musica que fizeram para quem não quis arriscar:

Introduçao
Centralização
Contrato da API
Diretrizes de estilo
Reutilização
Automação
Versionamento
Política de descontinuação
Rastreamento / Observabilidade
Descoberta de API

Referencial

Pode me chamar de Juscélio ReisFollow

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

[Série] Governança de API: Centralização

Pode me chamar de Juscélio Reis — Tue, 28 Jul 2020 02:19:30 +0000

Dando continuidade a nossa serie sobre Governança de API, vamos falar de Centralização. Quando queremos organizar a bagunça sempre lembro dessa fala do Deming:

Não se gerencia o que não se mede,
não se mede o que não se define,
não se define o que não se entende,
e não há sucesso no que não se gerencia
-- William Edwards Deming

Olhando atentamente essa fala, é possível inferir que para alcançar o sucesso é de extrema importância entender o contexto do problema e sua nuances. Não será diferente com o assunto desse artigo, afinal vivemos em um tempo complexo. A cada minuto que passa surge uma nova tecnologia, um novo serviço e uma nova forma de pensar, antigamente era mais simples, os sistemas eram todos construido para atender todas as necessidades, vulgo monolito, e todas as regras de negócios podiam ser extraídas de um único local. Atualmente estamos implementando microserviços, mesmo que não seja preciso leia mais sobre aqui. A quantidade de API ou serviços no meio corporativo só tem aumentado. Imagina quando começar a ser tudo (serverless)[https://aws.amazon.com/pt/serverless/] 🤪.

Sem levantar as nuances de certos contextos bem específicos do seu sistema. A forma mais simples pra iniciar o processo de entendimento do seu ambiente é criar uma lista com todas as APIs internas e externas. Informando uma breve descrição sobre características chaves para que qualquer ser humano consiga entender qual a utilidade e quando precisa consumir sua API. Essa descrição deve conter pelo menos os campos abaixo:

Recurso: descreve o motivo dessa API ter sido projetada, e o que ela consegue entregar, usando uma linguagem que os seres humanos, leigos, possam digerir;
Estrutura: uma descrição esquemática das APIs, incluindo URIs, estruturas de dados, segurança, etc. Podemos citar como exemplo aqui o OpenAPI;
Capacidade: qual a quantidade de requisições que essa api deve suportar, quantas requisições seu cliente já consumiu;
Sensibilidade: a API consome ou expõe dados que possam estar sujeitos a restrições regulatórias ou de privacidade, como dados de cartão de pagamento, dados de identificação pessoal e assim por diante.

Para tal inventario é dado o nome de Catalogo de API (vou usar esse termo daqui pra frente) ou Registro de API. Como exemplo de catalogo de API bem feito cito o ProgrammableWeb e o RapidAPI como exemplo a ser copiado.

O catalogo de API também ajuda a equipe de governança a criar e aplicar políticas. Existem alguns modelos para a construção dessa equipe, todos com o intuito de chegar no estado da arte em Governança de API.

Centralizado: Toda alteração arquitetural, desde a implementação de novos recursos até a aplicação ou introdução de novos elementos no cenário arquitetônico, sempre são revisadas e aprovadas por uma equipe centralizada. Esse modelo tem um grande problema de escalabilidade, já que isso pode fazer com que a equipe se torne um gargalo devido ao alto nível de demandas impostas a elas.
Descentralizado: Similar ao modelo anterior, mas formado por mais de uma equipe, menor, e essa possuindo autonomia para avaliar e validar certos aspectos da arquitetura, seja para um aplicativo específico ou para um conjunto de aplicativos relacionados. Agora o problema desse modelo é coordenar essas equipes, evitando que mudanças de uma equipe afete a outra equipe.
Distribuído: Formado por equipes especialistas em um conjunto de produtos e, portanto, responsáveis por eles. O conhecimento comercial e os aspectos de governança são cruciais para garantir que os controles corretos estejam em vigor.

Aqui eu indico o vídeo da Sensedia com o tema Repensando a Governança de APIs

Tenha um certo cuidado ao escolher o melhor modelo para sua organização. Como foi falado no post anterior, comece devagar e vai adaptando a sua realidade, reforçando as boas práticas e mudando o que não deu certo para o seu contexto.

Tome cuidado para não confundir catalogo de API com o portal do desenvolvedor, sob a ótica da governança todas as APIs são importantes, se é interna ou externa, ela deve estar no inventario. E o acesso a esse inventario deve ser divulgado para toda a empresa, principalmente para a área de negócio. Eles podem visualizar o que já existem e definir uma estratégia para consumir essas APIs de acordo com suas necessidades.

Mas um portal do desenvolvedor pode ser um produto, e como produto precisamos entender qual o seu publico alvo. Aqui é possível distinguir 3 tipos de publico alvo que uma organização geralmente possui:

Equipes internas: O objetivo inicial é permitir que suas equipes internas criem novas funcionalidades e aplicativos sobre suas APIs. Ao pensar no catalogo de API para equipes internas é importante pensar como que essas equipes vão consumir suas APIs, a experiência do desenvolvedor aqui é muito importante para ganhar escala.

The Wiz way to build technological solutions

Lucas Mindêllo ・ Jul 7 '20 ・ 3 min read

#microservices #governance #agile #devops
Parceiros e/ou Clientes: Seus parceiros de negócios e clientes são as próximas partes interessadas que podem fornecer mais valor agregado a sua organização por meio de APIs. A API do seu parceiro pode integrar-se ao aplicativo de RH de um cliente para otimizar as informações dos funcionários ou fornecer um benefício diferenciado para o seu cliente.
Desenvolvedores de terceiros: A etapa final é disponibilizar suas APIs para o público em geral e monetizar com isso 🤑. Se ainda não parou para pensar em ganhar dinheiro. Gaste um tempo e o explore esses sites aqui ProgrammableWeb e o RapidAPI.

Mantendo a inovação constante

É possível manter um fluxo de inovação constante, e apoiar a estratégia da sua organização? Para chegar nesse nível de maturidade é fundamental oferecer sustentação para tipo de público alvo, e manter uma alta taxa de inovação nesses portais, talvez até uma equipe dedicada exclusivamente na entrega dessas inovações.

Construir esses portais ajudam a entregar diferencial para os desenvolvedores que procuram APIs com o intuito de agregar valor no seu produto. A inovação e o diferencial desse produto aparece em como você pensa na forma que seu publico vai solicitar acesso, gerar suas chaves de API ou tokens OAuth. Como o desenvolvedor vai consumir sua API se será através de um contrato como Swagger ou usando um SDK feito por você.

Não fique preso apenas no inventario para o catalogo de APIs. Pense em como será a experiência do desenvolvedor, como esse produto vai ajudar nas entregas do dia a dia desse desenvolvedor. Só uma sugestão, é possível disponibilizar SDKs para qualquer tipo de linguagem de programação, um canal de ajuda, suporte, informações dos logs de alterações, mudança de contrato ou quando essa API vai deixar de ser suportada pela organização.

Agora que possui essas informações centralizadas é possível realizar uma analise do impacto de uma determina alteração, visualizar as dependências de cada API e conseguir enxergar a como estão sendo expostos os campos mais sensíveis. Existem ferramentas como o Stoplight, que entrega de uma forma visual essas visualizações. Para conseguir extrair o máximo dessas ferramentas será preciso entender o conceito de Contrato da API, e este é o assunto do próximo artigo dessa serie.

Introduçao
Centralização
Contrato da API
Diretrizes de estilo
Reutilização
Automação
Versionamento
Política de descontinuação
Rastreamento / Observabilidade
Descoberta de API

Referencial

.ltag__user__id__426430 .follow-action-button { background-color: #008000 !important; color: #dce9f3 !important; border-color: #008000 !important; }

Pode me chamar de Juscélio Reis

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

[Série] Governança de API

Pode me chamar de Juscélio Reis — Tue, 21 Jul 2020 01:30:42 +0000

Nos últimos meses tenho notado um aumento substancial da utilização do termo API. Empresas estão cada dia mais criando e consumindo APIs e a procura por desenvolvedores que sabem construir APIs também tem crescido. Existem inúmeras maneiras de construir e fornecer uma API, para isso podemos citar grandes empresas que possuem soluções prontas e de alto custo visando entregar uma API no menor tempo possível, ou podemos construir do zero a um baixo custo nossas próprias soluções e entregar uma API gastando um tempo razoável.

Mas a maioria dessas soluções não são capazes de entregar um recurso fundamental: Gerenciamento do Ciclo de vida do desenvolvimento. Um desenvolvedor passa algum tempo criando APIs úteis e robustas, mas acaba lutando com a evolução orgânica do seu código e com as mudanças que o meio negocial pode impor no desenvolvimento, como a famosa frase: precisamos dessa alteração para amanhã. Será se esse desenvolvedor é capaz de informa qual o verdadeiro impacto que uma simples mudança de parâmetro pode trazer para todos os clientes?

👾🎤 Isso não faz sentido, o que mais existe por ai são ferramentas de ALM, DevOps ou acompanhamento de projeto.
-- Leitor ansioso

Para esses leitores, só posso responder que continuem lendo. E que o foco desse artigo é Governança de APIs. E por ser um tema bem especifico, precisamos de ferramentas bem especificas. É diferente do que construir um software que vai rodar apenas no navegador ou no desktop. Deixa apresentar como é a construção de uma API sem o gerenciamento do ciclo de vida do desenvolvimento.

Para as empresas cuja a estratégia de negócio tem como objetivo entregar API para um mercado em potencial, a governança é uma necessidade. Não sabe do que estou falando sugiro que naveguem no site ProgrammableWeb ou procure pelos temas Open Banking ou Open Insurance.

Atividades da governança de API

Foi falado um monte sobre governança de API e gerenciamento do ciclo de vida do desenvolvimento focando na entra de API. Mas afinal o que seria isso, quais são as atividades que diferenciam de uma construção de software para web ou desktop.

Primeiro preciso fazer uma pergunta a você; você sabe onde estão todas as APIs da sua empresa? Nesse exato momento consegue informar quais clientes estão consumindo suas APIs?

Nesse momento consigo definir a Governança de API como a disciplina que vai desenvolver um trabalho para entender onde as pessoas estão, ferramentas, serviços, habilidades, melhores e piores práticas. E cruzar com o anseio e desejos dos outros setores da empresa, com o objetivo de construir uma ponte entre o momento atual da empresa com o que pode acabar sendo uma futura estratégia de governança de API.

De nada adianta implantar uma solução completa e robusta que já foi validada em outros times, se não trabalhar pessoas, ferramentas, processos e cultura dos envolvidos.

A cultura come a estratégia no café da manhã
-- Peter Drucker

A governança é especialmente benéfica para organizações que possuem um trabalho de construção de API ou arquiteturas de microsserviços, entregando consistência dos seus serviços para toda a organização. Além de ajudar a evitar problemas como código duplicado, acoplamento rígido entre componentes, falta de confiabilidade e economia.

Afinal o desejo de quem trabalha no time de governança é que as pessoas se importem com o design da API e estejam abertas a aprender como outras pessoas estão projetando suas APIs. E que os próprio time consiga defender o valor que um bom projeto pode agregar ao negocio em vez de simplesmente responder um ticket do JIRA. Pois o ticket não diz nada sobre a API ser bem projetada e consistente com outras equipes, a governança entre aqui.

Esse foi apenas o primeiro artigo da serie sobre Governança de API. Para os próximos episódios vamos abordar os seguintes temas com a visão da governança.

Introdução
Centralização
Contrato da API
Diretrizes de estilo
Reutilização
Automação
Versionamento
Política de descontinuação
Rastreamento / Observabilidade
Descoberta de API

Referencial

.ltag__user__id__426430 .follow-action-button { background-color: #008000 !important; color: #dce9f3 !important; border-color: #008000 !important; }

Pode me chamar de Juscélio Reis

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

The Wiz way to build technological solutions

Lucas Mindêllo — Tue, 07 Jul 2020 20:47:47 +0000

Hello, I'm Lucas Mindêllo, an IT Manager of Wiz and I'm responsible to define the Wiz way of working in technological solutions. So, I need to provide you a background of Wiz challenges that I'm trying to address.

We are Wiz, we sell insurance and financial products using our business units. So, we have an initiative shaping the way all our sales structures works.

For that, we're organized in Squads where each one looks for a singular business unit, each one with different needs and, as head of the development team, I need to help our Dev team to be able to work, build solutions with a corporate vision, and delivering value on every sprint. By the way, we mainly use Scrum, although that needs another article.

How we keep governance in our development?

I believe that we have three main pillars to address, a frame to deliver the same vision to all developers, a well-known process and management on those pillars. This article will focus on the development frame.

To deliver that, we need to level some ground premises:

We develop using microservices architecture;
We deliver autonomy to all squads;
We need to level knowledge with our DEVs;
We need to maintain corporative system governance.
And this frame results in white-label solutions for our costumers. Based on components and low effort to change the look-n-feel.

What a component represents?

Besides the frontend component concept, we've extrapolated it to backend/frontend connection. We did that, somehow a component is configurable to any similar need.

The image above represents a simple component that has the CRM and two databases as sources. We believe that a project standard for components and pages is enough to address the governance needs for the frontend, although we need to better shape the backend architecture.

How we address the backend governance?

Focused to maintain the squads' autonomy and reuse the majority of our developed code, we have split our microservices into two categories: Wiz Services and Squad Services.

We've limited to Wiz Services only corporative business rules, somehow any business unit should use the service routes seamless. With that in mind, we had to enforce a higher code review policy and deployment.

As we need all DEVs to be able to evolve our Wiz Services, we've defined .NET Core as our standard framework for Wiz Services.

To address the Triple A need on every element connection, we've developed a SSO API, based on OpenID and JWT token. We did that someway the same SSO solution is used for a user or service identification.

Another auxiliary service is Wiz Log. This solution is focused to log our business events. Our main objective is to be able to keep track of some business events and to be able to analise that information.

I think that the Wiz Log can be explained in another article.

All of that is unecessary if we don't standardize our microservice code.

What is the Wiz Microservice Project Standard?

We think that is worth to split the application in domain layers, that way we've made our interpretation of DDD (Domain Driven Design). We've split it in 3 layers, API, domain and infra.

I think that the success of a well-designed API depends on a good domain definition. The Domain layer is where we define what are the entities that our microservice will represent. If we take a CRM-API as reference, one main entity is Client and every client has some attributes that is common to all business units needs. That's the main responsibility of the Domain Layer.

The Infra Layer should translate the API entity to the datasource elements. Using the same API-CRM as an example, in this layer a client should be represented as an Account and Contact in Salesforce. This way, for any reason, if we need to integrate our API to another CRM, we just need to translate those entities to that CRM.

And finally, the API Layer is the presentation layer. It's where we expose our REST endpoints. By the way, we use RESTFull on our microservices, which improves our development velocity.

Conclusion

I think we're on a good way to develop great solutions with governance and keeping a good velocity.

Forem: DEVz Wiz

Devops #1 - Qualidade x Tempo

Stoplight/Prism-CLI - Acelerando o desenvolvimento e aumentando a integração

Sumário

Instalação do @stoplight/prism-cli

Código back-end & OpenAPI Documentation

Prism Mock Server

Prism Proxy Server

Conclusão

GC: Otimizando para o ambiente do Azure

Azure

Garbage Collection

Otimização

Exemplo

Estudos futuros

Referencia

Pode me chamar de Juscélio Reis

HttpClient: melhoria de performance ao otimizar o uso de memória

Teoria

Solução

Estudo de caso

Windows

Linux

Pode me chamar de Juscélio ReisFollow

Teste de integração com SqlServer e Azure Devops

Motivação

Para rodar os testes segui os seguintes passos:

Exemplo do método de repositório que quero testar

SqlServer no meu ambiente de desenvolvimento

Código para estrutura e conexão com banco de dados

O repositório que pretendo testar

O Teste

Configuração do pipeline para testes de integração com Sql Sever no Azure

No Azure podemos visualizar os resultados

[Série] Governança de API: Contrato da API

Recapitulando:

[Série] Governança de API

Pode me chamar de Juscélio Reis for DEVz Wiz ・ Jul 21 '20

[Série] Governança de API: Centralização

Pode me chamar de Juscélio Reis for DEVz Wiz ・ Jul 28 '20

O contrato da API: o primeiro e mais importante passo

Por que devemos começar nossas APIs pelo contrato?

Pode me chamar de Juscélio Reis ・ Jul 13 '20

stoplightio / studio

The modern editor for API Design and Technical Writing.

Stoplight Studio

Documentation

Features

Full Support for OpenAPI v2 and v3

Graphical API Design

stoplightio / prism

Turn any OpenAPI2/3 and Postman Collection file into an API server with mocking, transformations and validations.

Prism Overview

Ways to Use Prism

Hosted Prism

Self-hosted Prism

OpenAPITools / openapi-generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)

OpenAPI Generator

CLIENT generators

SERVER generators

DOCUMENTATION generators

SCHEMA generators

CONFIG generators

Referencial

Pode me chamar de Juscélio ReisFollow

[Série] Governança de API: Centralização

The Wiz way to build technological solutions

Lucas Mindêllo ・ Jul 7 '20 ・ 3 min read

Mantendo a inovação constante

Referencial

Pode me chamar de Juscélio Reis

[Série] Governança de API

Atividades da governança de API

Referencial

Pode me chamar de Juscélio Reis

The Wiz way to build technological solutions

How we keep governance in our development?

What a component represents?

How we address the backend governance?