[ETP] Impactos da descontinuação da API do e-estado

ESTUDO TÉCNICO PRELIMINAR - ETP

Autores:

José Lucas da Silva Costa,

João Pedro Rocha Brito,

Jônatas Neves Legal

1 - INTRODUÇÃO

A SETIC fornece vários serviços e cada um com sua responsabilidade, foi identificado que o SAURON realiza atribuições além de suas responsabilidades, quebrando esse princípio. Atualmente o sistema retorna claims de dados funcionais do usuário autenticado, o que foge da sua responsabilidade e invade a responsabilidade de outras APIs de dados funcionais. Deve se levar em conta também que a antiga API do E-estado que é utilizada, será descontinuada. O SAURON não retornará mais dados funcionais, mas continuará sendo enviado as informações básicas de usuário, nome e e-mail e também os perfis de acesso.

2 - O QUE É NECESSÁRIO PARA ATENDER A NECESSIDADE

A ação que deve ser tomada é tentar minimizar os impactos dos sistemas que utilizam o SAURON e E-estado, o time de desenvolvimento utiliza o Scrum como ferramenta para a entrega de produtos, essas entregas devem contemplar as adaptações necessárias para esta melhoria. Para melhor se situar no assunto, O Scrum é uma estrutura iterativa e incremental para gerenciar o desenvolvimento de produtos. Ele define uma estratégia de desenvolvimento de produto flexível e holística, onde uma equipe de desenvolvimento trabalha em conjunto para alcançar um objetivo comum..

Atualmente o SID por exemplo, utiliza massivamente a seguinte API:

https://e-estado-api.master.local/api/movimentacoes/nomeOuCpf/

Esta API é solicitada com certa frequência e causa alguns problemas de desempenho em determinadas requisições que possua secretarias, onde a quantidade de servidores é maciça, vejamos relatório de desempenho de uma requisição no Kibana:

Fonte: SETIC-RO

Considerando que o SID mantém a média de 1000 requisições à essa rota e também considerando que este processamento acontecerá de modo monotarefa, então o tempo atual que está em média a 656 milissegundos é muito alto. Vinculado a isso a API antiga do E-estado não possui mais suporte técnico e supostamente deve ser descontinuada.

Outro fator de impacto para os sistemas do time TITÃS é a desvinculação de alguns dados do SAURON, dados esses que não são sobressalentes devido o E-estado já conter as mesmas informações. Essa desvinculação causará a demanda de manutenções, em especial o sistema SKALA, que não foi previamente preparado para se ter essa independência, cenário este que é um pouco diferente no SID pois ao perceber esse problema o time se antecipou e fez preparativos para que o SID pudesse buscar dados essenciais no SAURON e o restante no E-estado.

3 - COMPLEXIDADE DE CADA FUNCIONALIDADE

teste.

4 - POSSÍVEIS PROBLEMAS

Quando uma API falha ou possui problemas de desempenho, essa falha reflete na SETIC. Os usuários finais e clientes provavelmente não reconhecerão que um terceiro pode ser o culpado. E dependendo da importância dessa API para um processo de transação, essa falha pode afetar seus resultados imediatamente. Encontrar problemas de desempenho apenas algumas semanas antes da data de lançamento de um sistema em produção de uma API de aplicativo, é uma ocorrência comum. Um tempo de alta resolução é preciso até frações de milissegundos. Essa precisão o torna ideal para produzir medições precisas de tempo. Cada medição medida na Performance API é um tempo de alta resolução. A API de alto desempenho faz parte da API de tempo de alta resolução. À medida que o aplicativo aumenta, ele pode enfrentar problemas de desempenho. Portanto, é melhor ter testes de carga/desempenho desde o início. A maioria das empresas de desenvolvimento de software tem equipes de teste dedicadas que realizariam testes de integração para garantir que não haja gargalos devido ao uso imenso de APIs RESTful expostas por clientes REST.

5 - VALOR AGREGADO

A melhoria de desempenho em API está sendo amplamente utilizada na indústria de software para permitir a integração de múltiplas aplicações de forma eficiente. Embora os aplicativos tenham sido submetidos a muitos testes manuais e automatizados antes do lançamento, é possível que surjam problemas na produção. Neste estudo técnico, vimos os problemas comuns encontrados, seguidos pelas práticas para minimizar os problemas.

6 - CONCLUSÃO DO ESTUDO

O presente ESTUDO TÉCNICO PRELIMINAR, elaborado pelos integrantes TÉCNICOS do time TITÃS, considerando a análise dos desafios técnicos envolvidos e citados, conclui pela VALIDAÇÃO DAS REGRAS DE REMARCAÇÃO ATUAIS, uma vez que foram considerados a análise técnica do código envolvido, principalmente potenciais problemas que afetem a disponibilidade do serviço. Em complemento, os contratempos identificados são administráveis, pelo que RECOMENDAMOS A REVISÃO CONSTANTE DAS REGRAS, uma vez que, o projeto está suscetível a mudanças solicitadas pelos responsáveis do SID.