Sensedia Connectivity Garage - Workshop Sensedia API Platform

Gabriel: Olá pessoal, muito boa tarde. Sejam todos muito bem-vindos a mais um Connectivity Garage. Eu sou o Gabriel Andrade e hoje eu tenho a honra de conduzir este espaço com vocês. Para quem já nos acompanha, sabe que o foco aqui é sempre trazer conteúdo técnico de qualidade e, principalmente, mostrar a prática de como as APIs estão transformando os negócios. Mas antes de a gente mergulhar no nosso tema de hoje, eu não estou sozinho.

‍

Gabriel: Eu queria convidar para abrir este evento comigo o Bruno. O Bruno é peça fundamental aqui nas nossas comunicações e vai nos dar as boas-vindas oficiais. Bruno, é com você.

‍

Bruno: Valeu, Gabriel! Boa tarde, pessoal. É um prazer estar aqui em mais um Connectivity Garage com todos vocês. Como o Gabriel adiantou, hoje o dia é especial porque o formato é de workshop. Nós sabemos que muita gente pede para ver a plataforma "por dentro", para entender como as engrenagens funcionam na hora de configurar uma estratégia de APIs.

‍

Bruno: Eu sou o Bruno e vou estar acompanhando vocês aqui no chat. Então, fiquem à vontade para mandar suas dúvidas, críticas ou sugestões. O Gabriel preparou um roteiro muito completo que vai desde o básico até algumas configurações bem avançadas que eu tenho certeza que vão agregar muito valor para o dia a dia de quem trabalha com arquitetura e desenvolvimento.

‍

Bruno: Gabriel, o pessoal já está ansioso aqui no chat. Vou devolver a palavra para você para que a gente possa, de fato, começar esse "mão na massa". Um ótimo workshop a todos!

‍

Gabriel: Perfeito, Bruno. Muito obrigado. Bom pessoal, agora que o Bruno já fez as honras da casa, vamos ao que interessa. Como eu mencionei, o nosso objetivo hoje é explorar a Sensedia API Platform. Eu vou simular aqui um cenário real: nós temos um serviço de backend que precisa ser exposto para um parceiro externo, mas ele não pode ser entregue de qualquer jeito. Precisamos de segurança, precisamos de controle e, em muitos casos, de transformação de dados.

‍

Gabriel: Eu vou começar agora compartilhando a minha tela do API Suite. Esta é a interface principal onde tudo acontece dentro da nossa plataforma. Do lado esquerdo, vocês conseguem ver o menu de navegação com as opções de APIs, conectores, interceptores, planos de acesso e toda a parte de segurança e governança.

‍

Gabriel: Para começar o nosso trabalho, o primeiro passo dentro do ciclo de vida é sempre a criação da API. Eu vou clicar aqui no botão de "Plus" na parte superior para adicionar uma nova API ao nosso catálogo.

‍

Gabriel: Aqui na tela de criação, eu vou definir o nome da nossa API como "Workshop Connectivity 2024". Um dos campos mais importantes que temos aqui é o campo de contexto. Eu vou definir esse contexto como "/v1/garage". É muito importante que vocês lembrem que esse contexto é o que identifica a sua API dentro do Gateway. Se você tiver várias APIs publicadas, o contexto é o que vai diferenciar para onde a requisição deve ser roteada no momento em que ela chega.

‍

Gabriel: Vou selecionar aqui que o tipo da minha API é uma API REST. Nós também suportamos outros formatos, mas para o exercício de hoje vamos focar no REST. Vou clicar em salvar e, pronto, a nossa API está criada, mas por enquanto ela é apenas uma casca vazia, uma definição no nosso catálogo.

‍

Gabriel: O próximo passo agora é definir os recursos que essa API vai ter. Eu vou entrar aqui na aba de "Recursos" e vou adicionar o primeiro deles. Vamos supor que o nosso cenário seja listar clientes de uma base de dados. Então, eu vou criar o recurso chamado "/clientes" e vou associar a ele o método GET.

‍

Gabriel: Vejam que aqui na interface eu já posso adicionar uma descrição para esse recurso. Isso é excelente porque essa descrição já vai compor a documentação automática que a plataforma gera para os desenvolvedores depois. Eu salvo o recurso e agora eu tenho um ponto de entrada. Mas para onde essa chamada vai? Eu preciso configurar o meu destino, o que nós chamamos de "Target".

‍

Gabriel: No campo de destino, eu vou colocar a URL do meu servidor de backend. Neste exemplo que estamos construindo, eu estou utilizando um serviço simulado que retorna uma lista em formato JSON com os dados dos clientes. Eu digito aqui o endereço completo do servidor. É importante notar que o Gateway agora já tem a inteligência necessária para saber que, toda vez que alguém chamar o endpoint "/v1/garage/clientes", ele deve encaminhar essa requisição para esse endereço que acabei de configurar.

‍

Gabriel: Vou clicar em salvar. Agora, um detalhe importante: para que as alterações tenham efeito, eu preciso fazer o deploy. Vou selecionar aqui o ambiente de Sandbox, que é o nosso ambiente de testes e experimentação. Pronto, a API está publicada e já pode receber chamadas nesse ambiente.

‍

Gabriel: Agora que a nossa API já está roteando para o backend, vamos falar sobre o coração da plataforma Sensedia, que são os interceptores. O interceptor é o que permite que a gente adicione inteligência e regras de negócio no fluxo da chamada sem precisar programar uma única linha de código no backend original. Se vocês olharem aqui na tela, temos dois fluxos distintos: o fluxo de Request, que é tudo o que acontece quando a mensagem está indo para o servidor, e o fluxo de Response, que é o que acontece quando a resposta está voltando para o cliente.

‍

Gabriel: Vamos simular um problema real. Imagine que esse meu backend de clientes é um sistema legado e ele exige uma chave de autenticação fixa num cabeçalho que eu não quero revelar para o meu desenvolvedor externo por questões de segurança. Eu vou aqui na nossa lista de interceptores, procuro o interceptor de "Header" e simplesmente arrasto ele para dentro do fluxo de Request.

‍

Gabriel: Agora eu configuro esse interceptor. Vou definir o nome do cabeçalho como "X-Backend-Token" e colocar o valor secreto. O que vai acontecer agora? O desenvolvedor faz uma chamada simples para o Gateway e o Gateway, antes de entregar a mensagem para o backend, "carimba" essa mensagem com o token secreto. Isso traz uma camada de abstração de segurança muito potente.

‍

Gabriel: Outro cenário muito comum é a transformação de dados. Muitas vezes o seu backend é antigo e só fala XML, mas o seu novo aplicativo em React ou Flutter precisa receber JSON. Para resolver isso, eu vou utilizar o interceptor de XSLT. Eu vou arrastar ele agora para o fluxo de Response, porque eu quero transformar o que o meu servidor responde antes de o cliente receber.

‍

Gabriel: Vou abrir a configuração do XSLT. Como vocês podem ver aqui no código que estou colando na tela, eu consigo mapear exatamente quais campos eu quero extrair do XML original. Eu uso os comandos de seleção para dizer que o campo "nome_completo_usuario" do XML deve ser entregue apenas como "nome" no JSON final. Eu defino toda essa lógica de mapeamento aqui dentro da plataforma. O Gateway processa isso de forma extremamente rápida em memória.

‍

Gabriel: Eu clico em salvar e valido o script. O legal do XSLT na Sensedia é que ele permite inclusive que você faça condicionais. Se um campo vier vazio do backend, eu posso definir um valor padrão aqui no interceptor. Isso limpa muito o trabalho do desenvolvedor de frontend.

‍

Gabriel: Agora que nós já vimos como transformar os dados e como injetar cabeçalhos de segurança, vamos para um ponto que é vital para qualquer arquiteto de soluções: a resiliência do sistema. Muitas vezes, o nosso backend não tem a mesma capacidade de escala que o Gateway. Se o seu aplicativo móvel viralizar e você receber milhares de acessos por segundo, o seu servidor interno pode virar um "gargalo" e cair.

‍

Gabriel: Para evitar esse cenário de indisponibilidade, nós utilizamos o interceptor de Spike Arrest. Eu vou buscá-lo aqui na nossa lista de políticas de tráfego e vou arrastá-lo para o início do nosso fluxo de Request. É importante que ele esteja no começo, porque queremos barrar o excesso de chamadas antes mesmo de processar qualquer lógica pesada.

‍

Gabriel: Vou configurar o Spike Arrest para um limite de 10 requisições por segundo (10 TPS). O que isso significa na prática? Significa que a plataforma vai monitorar cada milissegundo. Se no décimo primeiro milissegundo chegar uma nova chamada dentro do mesmo segundo, o Gateway nem chega a chamar o seu backend. Ele já responde diretamente para o cliente com um erro HTTP 429 — "Too Many Requests". Isso garante que o seu servidor trabalhe sempre dentro da zona de conforto.

‍

Gabriel: Mas e se eu quiser um controle por volume total, algo mais comercial? Para isso, eu usaria o interceptor de Quota. Enquanto o Spike Arrest protege contra picos repentinos, a Quota serve para limitar, por exemplo, que um parceiro específico só possa fazer 5.000 chamadas por mês. Eu posso configurar isso atrelado à "API Key" ou ao "App" que está chamando. É assim que muitos dos nossos clientes criam seus modelos de monetização de APIs.

‍

Gabriel: Vamos agora para a parte de visibilidade. Não adianta ter tudo configurado se eu não sei o que está acontecendo. Vou adicionar um interceptor de Log no fluxo de saída. Eu quero logar o tempo de resposta do meu backend. A plataforma permite que eu capture variáveis do sistema, como o target.response.time. Com isso, eu consigo gerar dashboards depois para saber se o meu serviço está ficando lento em horários de pico.

‍

Gabriel: Outro recurso muito poderoso que eu quero mostrar para vocês é o Conditional Interceptor. Imaginem que eu só quero aplicar a transformação XSLT que fizemos antes se o cliente enviar um cabeçalho específico pedindo "format=legacy". Eu consigo clicar no interceptor de XSLT e definir uma condição: request.header.format == "legacy". Se essa condição não for atendida, o Gateway pula esse passo e entrega o JSON padrão. Isso dá uma flexibilidade absurda para a mesma API atender clientes modernos e legados ao mesmo tempo.

‍

Gabriel: Agora que configuramos toda essa inteligência — segurança, transformação, controle de tráfego e logs — vamos para a prova de fogo. Eu vou clicar novamente em "Deploy" para garantir que todas essas novas regras estejam ativas no nosso ambiente de testes. Deploy concluído com sucesso.

‍

Gabriel: Vou abrir o API Browser. Notem que ele já carrega a documentação que a gente começou a preencher lá atrás. Vou selecionar o recurso GET /clientes, vou passar os headers necessários e clicar em "Send". Olhem aqui no console: a resposta veio limpa, transformada pelo XSLT, e no log aqui embaixo eu consigo ver que o Spike Arrest monitorou a chamada. Se eu clicar freneticamente no botão de enviar, vejam só, o erro 429 apareceu. O sistema barrou o meu "ataque" simulado.

‍

Gabriel: Agora que validamos o fluxo técnico, eu quero mostrar para vocês a parte de Analytics e Governança. Não basta a API funcionar; o gestor precisa saber quem está usando. Eu vou navegar aqui no menu lateral para a parte de "Dashboards". Notem que, de forma nativa, a plataforma já começa a plotar os gráficos de consumo. Eu consigo ver o total de requisições, a taxa de erro (quantos 400 ou 500 estamos devolvendo) e, principalmente, o tempo de latência.

‍

Gabriel: Se eu clicar em um cliente específico, eu consigo ver o comportamento dele. Isso é fundamental para o time de suporte. Se um parceiro liga dizendo que a integração está lenta, eu venho aqui, filtro pelo ID dele e consigo provar se a lentidão está no nosso Gateway, na rede, ou se o backend dele é que está demorando para responder. É a visibilidade total do ecossistema.

‍

Gabriel: Outro ponto importante é a Documentação (Developer Portal). Tudo o que nós preenchemos de descrição nos recursos e nos parâmetros agora está consolidado. Eu vou abrir aqui o portal que o desenvolvedor externo enxerga. Vejam que ele tem o botão de "Try it out", onde ele pode testar a API ali mesmo, ler os códigos de erro e entender quais headers ele precisa enviar. Uma documentação bem feita reduz em até 60% o custo de suporte técnico na integração de novos parceiros.

‍

Gabriel: Vamos falar rapidamente sobre Segurança Avançada. Além do Spike Arrest, nós temos interceptores para proteção contra ataques de injeção, como SQL Injection ou Cross-Site Scripting (XSS). Eu posso adicionar um interceptor de "JSON Threat Protection" que analisa se o payload que o cliente está enviando não é grande demais ou se contém caracteres maliciosos. Isso traz uma paz de espírito enorme para o time de segurança da informação.

‍

Gabriel: Bruno, eu vi que surgiram algumas perguntas aqui no chat enquanto eu fazia a configuração do XSLT. Uma delas é sobre o suporte a protocolos legados como o SOAP. Sim, pessoal, a plataforma lida muito bem com isso. Nós temos o interceptor de "SOAP to REST", que faz o mapeamento automático do envelope SOAP para um objeto JSON. Você expõe uma API moderna para o seu desenvolvedor, mas por trás o Gateway fala com aquele seu serviço antigo em XML sem problemas.

‍

Bruno: Perfeito, Gabriel. Teve uma outra pergunta aqui sobre a questão dos ambientes. O pessoal quer saber se é fácil promover uma API de Sandbox para Produção sem ter que refazer tudo manualmente.

‍

Gabriel: Excelente pergunta. Na Sensedia, nós trabalhamos com o conceito de Promotion. Uma vez que você validou tudo no Sandbox, você clica no botão de promover para o próximo ambiente. A plataforma carrega todas as configurações, mas permite que você altere apenas as variáveis que mudam, como a URL do backend de produção e as chaves de segurança. É um processo seguro e auditável.

‍

Gabriel: Para a gente caminhar para o encerramento, eu queria deixar um recado: a plataforma é um canivete suíço. O que eu mostrei aqui hoje é apenas 10% do que ela pode fazer. Nós temos orquestração de microserviços, integração com cache externo, suporte a gRPC e muito mais. O convite que eu faço é que vocês testem esses interceptores e criem seus próprios fluxos.

‍

Bruno: Show de bola, Gabriel. Acho que ficou muito claro o poder da ferramenta e como ela acelera a entrega. Queria agradecer muito a sua aula hoje aqui no Garage. Pessoal, lembrando que esse material fica disponível para vocês consultarem. Acessem a nossa documentação oficial e o nosso fórum de desenvolvedores se precisarem de ajuda em algum caso específico.

‍

Gabriel: Valeu pessoal, muito obrigado pela atenção de todos. Espero que esse "mão na massa" tenha ajudado a destravar alguns conceitos. Nos vemos no próximo Connectivity Garage. Um abraço e boa tarde a todos!

‍

Bruno: Valeu pessoal, até a próxima! Tchau, tchau.

‍