Resultados da busca

Moesif é uma plataforma de inteligência e análise para APIs (API Observability e API Monitoring) que capacita equipes de desenvolvimento e produto a entender o uso de suas APIs e a melhorar a experiência do usuário. Neste post, vamos explorar o que é Moesif, suas principais funcionalidades, benefícios de usá-lo e como ele pode ser implementado para otimizar a performance de APIs. O que é Moesif? Moesif é uma solução avançada de monitoramento e análise de APIs que fornece insights detalhados sobre como as APIs estão sendo usadas, o comportamento dos usuários, e a performance das chamadas de API. Ele permite que as empresas acompanhem em tempo real a saúde de suas APIs, identifiquem rapidamente problemas de performance ou bugs, e entendam melhor as necessidades e comportamentos dos usuários finais. Principais Funcionalidades do Moesif Monitoramento de APIs em Tempo Real: Moesif oferece monitoramento em tempo real das atividades da API, permitindo que as equipes vejam imediatamente como as APIs estão sendo usadas e identifiquem quaisquer problemas de performance. Análise Comportamental do Usuário: A plataforma proporciona uma análise profunda do comportamento do usuário, ajudando a entender como os usuários interagem com as APIs e identificar pontos de atrito ou oportunidades de melhoria. Detecção e Diagnóstico de Problemas: Com Moesif, é possível detectar automaticamente anomalias e problemas de performance, diagnóstico de erros, e entender a causa raiz para solucioná-los rapidamente. Personalização e Segmentação: Moesif permite segmentar usuários e chamadas de API por diversos critérios, facilitando a personalização da análise e a geração de insights mais relevantes para cada caso de uso. Implementando Moesif A implementação do Moesif geralmente começa com a integração do SDK da plataforma com sua API. Moesif suporta uma ampla gama de linguagens de programação e frameworks, tornando a integração simples e direta. Após a configuração inicial, as equipes podem começar a monitorar chamadas de API, analisar dados de uso, e gerar relatórios personalizados para obter insights valiosos. O Moesif possui uma série de SDKs e Conectores para diversos motores de API Gateways e plataformas de desenvolvimento, como exemplificado abaixo: Como exemplo de integração com Node.js (Express.js): // 1. Import Modules var express = require('express'); var app = express(); var moesif = require('moesif-nodejs'); // 2. Set the options, the only required field is applicationId. var options = { applicationId: 'Your Moesif Application Id', logBody: true, identifyUser: function (req, res) { if (req.user) { return req.user.id; } return undefined; }, getSessionToken: function (req, res) { return req.headers['Authorization']; } }; // 3. Initialize the middleware object with options var moesifMiddleware = moesif(options); // 4a. Start capturing outgoing API Calls to 3rd parties like Stripe // Skip this step if you don't want to capture outgoing API calls moesifMiddleware.startCaptureOutgoing(); // 4b. Use the Moesif middleware to start capturing incoming API Calls // If you have a body parser middleware, apply Moesif middleware after any body parsers. // Skip this step if you don't want to capture incoming API calls app.use(moesifMiddleware); Ao integrar o middleware dos backends ou do API Gateway, a plataforma Moesif, começa a receber os dados e informações de tráfego das requisições e respostas: Benefícios de Usar Moesif Melhoria na Experiência do Usuário: Ao entender melhor como os usuários interagem com suas APIs, as empresas podem otimizar suas interfaces e fluxos de trabalho para oferecer uma experiência mais suave e intuitiva. Redução de Tempo de Inatividade: A capacidade de identificar e resolver rapidamente problemas de performance ou bugs significa que as empresas podem minimizar o tempo de inatividade, mantendo a satisfação do cliente. Desenvolvimento Orientado por Dados: Moesif fornece dados acionáveis que podem guiar o desenvolvimento de produtos, ajudando as equipes a priorizar recursos e melhorias baseadas nas necessidades reais dos usuários. Compliance e Segurança: A plataforma também ajuda a monitorar e garantir a conformidade com regulamentos de privacidade e segurança de dados, um aspecto cada vez mais crítico para empresas em todos os setores. Conclusão Moesif emergiu como uma ferramenta essencial para empresas que dependem de APIs para seus produtos e serviços. Ao oferecer monitoramento em tempo real, análises detalhadas do comportamento do usuário, e ferramentas poderosas de diagnóstico e personalização, Moesif ajuda as empresas a otimizar suas APIs, melhorar a experiência do usuário, e conduzir decisões de desenvolvimento mais informadas. Se você está procurando uma maneira de levar sua estratégia de API para o próximo nível, Moesif pode ser a solução que você precisa, e a Skalena está pronta para ser sua empresa de apoio para trazer essa inovação e solução para o dia-a-dia da sua empresa. Fale com a gente hoje mesmo, para saber mais de como podemos ajudar neste sentido.

Com o crescimento exponencial do volume de dados gerados diariamente, a capacidade de processar e analisar informações em tempo real tornou-se uma necessidade em diversos setores. O Apache StreamPipes surge como uma solução eficaz para esse desafio, permitindo a construção de pipelines de fluxo de dados para analisar, processar e visualizar fluxos de eventos em tempo real. Vamos explorar alguns cenários em que o Apache StreamPipes pode ser aplicado, demonstrando sua versatilidade e poder. 1. IoT Industrial (IIoT) Manutenção Preditiva: Em fábricas e plantas industriais, a quebra de maquinário pode causar paralisações caras. Utilizando sensores e o StreamPipes, é possível monitorar máquinas em tempo real para detectar padrões que indiquem uma possível falha. Assim, manutenções podem ser programadas proativamente, evitando custos e interrupções inesperadas. Otimização de Energia: Monitorar o consumo de energia de ativos industriais e identificar áreas de desperdício, possibilitando intervenções para uma operação mais eficiente e sustentável. 2. Cidades Inteligentes Gestão de Tráfego: Em cidades congestionadas, a análise de dados em tempo real de câmeras e sensores de tráfego pode ajudar a controlar semáforos e sinalizações, melhorando o fluxo e reduzindo engarrafamentos. Monitoramento Ambiental: Sensores de qualidade do ar e de águas podem fornecer dados em tempo real para agências municipais, possibilitando respostas rápidas a eventuais problemas de poluição. 3. Saúde e Monitoramento de Pacientes Dispositivos Wearables: Pacientes com doenças crônicas podem ser monitorados à distância, com dispositivos wearables enviando dados em tempo real para profissionais de saúde através do StreamPipes, permitindo intervenções imediatas em situações de risco. 4. Agricultura de Precisão Monitoramento de Cultivos: Sensores podem ser utilizados para monitorar condições de solo, umidade, e saúde das plantas. Agricultores recebem insights em tempo real, permitindo-lhes otimizar irrigação, fertilização e práticas de colheita. 5. Setor Energético Redes Elétricas Inteligentes: A distribuição de energia pode ser otimizada através do monitoramento e análise em tempo real da demanda e oferta de energia, ajustando-se automaticamente para evitar sobrecargas e desperdícios. Conclusão O Apache StreamPipes, com sua capacidade de integrar diversos dispositivos e fontes de dados, oferece um ambiente ideal para desenvolver soluções de análise em tempo real para os mais variados setores. Em uma era dominada por dados, ferramentas como essa são essenciais para transformar informações brutas em insights valiosos e ações imediatas. Os casos de uso mencionados aqui são apenas a ponta do iceberg. Com a crescente evolução do ecossistema de IoT e a expansão da análise de dados, as possibilidades com o StreamPipes são virtualmente infinitas.

É com prazer que anunciamos a nossa parceria com a API7,a versão Enterprise do Projeto Apache APISIX, que pode ser uma grande alternativa para seus projetos e iniciativas de API Gateway e API Manager. Esta colaboração não é apenas uma aliança entre duas empresas; representa uma sinergia de visões, tecnologias e a determinação de conduzir a inovação no mundo das APIs. A API7 é conhecida por sua abordagem inovadora no design, monitoramento e gerenciamento de APIs. Suas soluções estão na vanguarda da tecnologia, proporcionando aos desenvolvedores e empresas as ferramentas necessárias para criar, gerenciar e otimizar APIs de maneira eficaz. Como grande aspecto da solução, podemos destacar a compatibilidade com o Kong API Gateway, que permite uma grande alternativa para esta solução. A Essência da Parceria Skalena e API7 Ao unir forças com a API7, buscamos criar um ecossistema mais integrado e eficiente, que permita aos nossos clientes aproveitar ao máximo a versatilidade das APIs. A fusão de nossos conhecimentos e a colaboração em projetos inovadores permitirá que alcancemos novos patamares em termos de funcionalidade, segurança e eficiência. O que Esperar? Integração Total: A colaboração com a API7 nos permitirá oferecer integrações mais profundas e robustas, abrindo portas para novas oportunidades e soluções, seja com a versão Opensource APISix e de acordo com a necessidade, levando a plataforma Enterprise On-Premises ou SaaS/Cloud API7 Inovação Contínua: Com a API7 ao nosso lado, continuaremos a explorar novas fronteiras tecnológicas, trabalhando juntos para desenvolver produtos e serviços pioneiros. Foco no Cliente: Nossa parceria reflete um compromisso conjunto em fornecer o melhor em atendimento e suporte ao cliente, garantindo que suas necessidades e objetivos estejam sempre em primeiro lugar. Segurança Elevada: No mundo digital, a segurança não é uma opção, é uma necessidade. Com a API7 ao nosso lado, elevamos nosso padrão de segurança, garantindo que seus dados e transações estejam sempre protegidos. Inovação Contínua: Esta parceria nos coloca na vanguarda da inovação em gerenciamento de API. Isso significa que você pode esperar soluções e atualizações cada vez mais avançadas, moldadas pelas demandas do mercado e as necessidades dos usuários. Parceria Exclusiva para Setor Público/Governo A Skalena é a parceria exclusiva da API7 (Fabricante por trás do projeto Open Source APISix), este modelo garante uma atuação forte em iniciativas de Governo que podem começar com a versão e produto Open Source. Parceria que se extende ao mundo A Skalena além de revenda na América Latina e Portugal, também apoia a API7 em clientes globais, localizados na Ásia e Europa. Em Direção ao Futuro A era digital está em constante evolução, e esta parceria com a API7 é um passo ousado em direção ao futuro. Estamos comprometidos em fornecer soluções que não apenas atendam, mas superem as expectativas. Tenho o prazer de anunciar nossa parceria com Skalena.Juntos, API7.ai e Skalena vão revolucionar o mercado no Brasil com nossas tecnologias de ponta e expertise.Nossa missão sempre foi capacitar empresas em todo o mundo por meio de gerenciamento de API eficiente.A Skalena compartilha nossa visão, tornando-a a parceira perfeita para expandir nosso alcance no Brasil.Em colaboração com nosso parceiro, a API7.ai se dedica a fornecer soluções abrangentes para design, desenvolvimento, portal, monetização e muito mais de APIs, otimizando soluções e desbloqueando oportunidades de crescimento.Esta parceria marca o início de uma emocionante jornada que irá redefinir as possibilidades no Brasil.Esperamos ansiosamente uma parceria incrível pela frente!" Ming Wen, CEO & Co-founder da API7.ai Com a API7 ao nosso lado, estamos confiantes de que será possível construir casos de sucesso incrivelmente impactantes, como os que já tivemos a chance de atuar no passado. Agradecemos a todos os nossos clientes, parceiros e a incrível equipe da API7 por acreditar nesta visão compartilhada. Juntos, temos mais uma solução em nosso portfólio para ajudar a redefinir o que é possível no mundo das APIs. Em nossa nova roupagem de integradores multi-vendors a API7.ai traz uma importante peça para nosso arcabouço de soluções, que combinada com nossa temática de DevOps, Tracing, Segurança de APIs, Workflows, Integrações e o desenvolvimento acelerado de Microsserviços" Carlos Candeia, Head de Projetos e Soluções Skalena Quer saber mais? fale com a gente

E se migrar aplicações e serviços Java7 e Java 8 automaticamente para versões mais recentes como Java 17 fosse algo possível? Acompanhe este post e veja como isto é possível. Nos dias de hoje, o software está em constante evolução. A demanda para adaptar-se rapidamente às mudanças tecnológicas e otimizar a base de código para melhor performance, segurança e manutenibilidade nunca foi tão alta. Nesse cenário, a refatoração eficiente e precisa do código se torna vital. E é aqui que o OpenRewrite entra em cena. OpenRewrite O OpenRewrite é um projeto open source destinado a refatorar e modernizar bases de código de maneira programática. Em outras palavras, ele automatiza as mudanças no código, garantindo que sejam precisas, consistentes e repetíveis. Como o OpenRewrite funciona? O OpenRewrite define "recetas" (recipes) que são conjuntos de regras para modificar o código-fonte. Quando aplicadas, essas receitas identificam padrões específicos no código e realizam as alterações necessárias de acordo com as instruções definidas. Veja o exemplo abaixo da quantidade de receitas existentes no projeto: ✨ Principais características: Linguagem agnóstica: Embora muitas de suas receitas atuais sejam focadas em Java, a arquitetura do OpenRewrite é projetada para suportar múltiplas linguagens de programação. Integração com ferramentas populares: O OpenRewrite pode ser integrado a diversas ferramentas e IDEs, facilitando a adoção em ambientes de desenvolvimento existentes. Automatização segura: Ao contrário das ferramentas de busca e substituição tradicionais, o OpenRewrite tem consciência da AST (Árvore Sintática Abstrata) do código, garantindo refatorações precisas e minimizando erros. Customizável: As organizações podem criar suas próprias receitas para atender a padrões específicos ou exigências de modernização. Por que considerar o OpenRewrite na sua organização? No mundo do software, pequenas ineficiências ou inconsistências no código podem se acumular ao longo do tempo, tornando-se dívidas técnicas. OpenRewrite ajuda a resolver essas dívidas programaticamente, garantindo que as bases de código permaneçam limpas, modernas e em conformidade com as melhores práticas. Em resumo, o OpenRewrite é uma ferramenta inestimável para equipes de desenvolvimento que buscam otimizar e modernizar suas bases de código de forma eficiente e confiável. Se você ainda não conferiu, vale a pena dar uma olhada neste projeto open source e considerar sua adoção no seu fluxo de trabalho de desenvolvimento. 💻🔄🌟 Tutorial OpenRewrite Este tutorial pressupõe que você: Tenha algum conhecimento em Java; Neste exemplo usaremos o Maven, porém o Gradle também é suportado. Saiba como executar comandos na linha de comando; Consiga executar comandos básicos do Git. Este tutorial foi executado usando Java versão 11, certifique-se que esta versão seja a configurada em seu sistema: java -version openjdk version "11.0.19" 2023-04-18 LTS OpenJDK Runtime Environment Corretto-11.0.19.7.1 (build 11.0.19+7-LTS) OpenJDK 64-Bit Server VM Corretto-11.0.19.7.1 (build 11.0.19+7-LTS, mixed mode) Passo 1 : Clonando o repositório de exemplo Primeiramente faça o clone do projeto com o seguinte comando: git clone https://github.com/openrewrite/spring-petclinic-migration.git Uma vez clonado, entre no diretório em questão, para este exemplo, eu estou usando o VSCode como ferramenta de desenvolvimento. Passo 2: Adicionar rewrite-maven-plugin ou rewrite-gradle-plugin ao seu projeto Depois de verificar seu projeto, a próxima etapa é adicionar o plug-in de reescrita ao Maven ou Gradle. Siga as instruções na guia Maven fazer isso. Adicione um novo na seção do seu pom.xml que se parece com: org.openrewrite.maven rewrite-maven-plugin 5.3.2 Na linha de comando, tente executar ./mvnw rewrite:discover : Passo 3: ativar uma Recipe Antes de executar qualquer uma das recipes (receitas), você precisará atualizar a configuração do plug-in para marcar a(s) receita(s) desejada(s) como "ativa(s)". Vamos usar a receita como exemplo (o que garantirá que suas importações sigam uma ordem padrão. Para ativar esta receita, modifique seu arquivo pom.xml, para que as seções que você modificou anteriormente se pareçam com o exemplo abaixo: org.openrewrite.maven rewrite-maven-plugin 5.3.2 org.openrewrite.java.OrderImports Passo 4: execute uma receita (recipe) de refatoração simples Antes da execução veja os arquivos alterados no projeto: Agora que você ativou a recipe OrderImports, você pode executá-la executando o comando: ./mvnw rewrite:run Veja o resultado da execução do comando Maven: Veja o resultado dos arquivos alterados até o momento em nosso repositório local: Quando visualizamos o diff de uma das classes, veja o resultado da execução da Recipe ativada: Passo 5: Executar uma recipe com configuração YAML Algumas recipes são mais complexas que OrderImports e requerem configuração no arquivo rewrite.yaml, para executá-las. Por exemplo, a receita org.openrewrite.java.ChangePackage, tem três opções que precisam ser configuradas: Para usar esta receita para renomear o pacote org.springframework.samples.petclinic.vet para org.springframework.samples.petclinic.veterinary, crie um arquivo rewrite.yml na raiz do seu projeto que com a seguinte configuração: --- type: specs.openrewrite.org/v1beta/recipe name: com.skalena.VetToVeterinary recipeList: - org.openrewrite.java.ChangePackage: oldPackageName: org.springframework.samples.petclinic.vet newPackageName: org.springframework.samples.petclinic.veterinary Como pode perceber, nossa regra tem o nome de com.skalena.VetToVeterinary, e a lista de receitas ativas, no caso: ChangePackage recebe como parâmetros oldPackageName e newPackageName. Vamos executar mais uma vez o comando : ./mvnw rewrite:discover , para ver se nossa recipe foi registrada de acordo: Agora podemos adicionar a referência de de nossa Recipe e referenciá-la em nosso pom.xml do projeto, como no exemplo abaixo: org.openrewrite.maven rewrite-maven-plugin 5.3.2 org.openrewrite.java.format.AutoFormat org.openrewrite.java.OrderImports com.skalena.VetToVeterinary Se você executar novamente o comando: ./mvnw rewrite:run, você verá a Recipe executando a refatoração. Migrações Possíveis com OpenRewrite Em termos de possíveis cenários, veja alguns exemplos que você pode refatorar/modernizar com o OpenRewrite: A tabela acima mostra apenas exemplos do que pode ser feito, pois afinal, a abordagem do OpenRewrite é que qualquer empresa ou indivíduo possa escrever sua receita em Java, e esta por sua vez executar todo o processo de refatoração e modernização. Para fins de exemplos, este mesmo código, nós mudamos a declaração do plugin para esta: org.openrewrite.maven rewrite-maven-plugin 5.3.2 org.openrewrite.java.migrate.UpgradeToJava17 org.openrewrite.recipe rewrite-migrate-java 2.0.8 Ao executar o comando /mvnw rewrite:run, mesmo este projeto usando Java11, o plugin do OpenRewrite foi capaz de executar uma adaptação de código para ser compatível com o Java 17: OpenRewrite + Esteroides : Moderne.io Se você preferir, a empresa por trás do desenvolvimento do OpenRewrite, possui uma plataforma SaaS, onde todo este gerenciamento de atividades de manter seu código saudável, não só em termos de modernizações, mas também garantindo que seu código não tenha vulnerabilidades de segurança, onde além de apontá-las, a plataforma já pode remediá-las, ou seja, alterar o código, de forma que estes problemas sejam resolvidos até mesmo de forma automática. Para saber mais sobre o Moderne.io , visite hoje mesmo o site deles em: https://www.moderne.io Se interessou por esta tecnologia e quer conversar mais a respeito, envie uma mensagem para nós, vai ser um prazer conversar com você: https://www.skalena.com/contato

Introdução No mundo digital de hoje, as APIs (Application Programming Interfaces) tornaram-se os blocos de construção de aplicativos modernos, impulsionando a transformação digital ao conectar diferentes sistemas, plataformas e aplicativos. À medida que o número de APIs aumenta, também aumenta a complexidade de mantê-las. Documentar e acompanhar as APIs pode se tornar uma tarefa assustadora, ainda mais quando essas APIs são atualizadas com frequência. É aqui que o OpenAPI e ferramentas como o Optic entram em ação. O que é OpenAPI? OpenAPI é uma especificação para construir APIs que oferecem alguns grandes benefícios. Ele permite que desenvolvedores e arquitetos de software projetem, criem, documentem e gerenciem APIs - fornecendo uma interface padrão e independente de linguagem para APIs RESTful. O OpenAPI ajuda a acelerar o desenvolvimento, melhorar a qualidade da API e aprimorar a usabilidade e a adoção de APIs. No entanto, criar e manter um documento OpenAPI pode ser uma tarefa demorada e sujeita a erros, especialmente quando você precisa atualizá-lo manualmente sempre que sua API é alterada. Benefícios do uso do Optic Economiza tempo: com o Optic, você não precisa mais atualizar manualmente suas especificações de API. Ele sincroniza automaticamente sua API e sua documentação, economizando seu precioso tempo de desenvolvimento. Melhora a precisão: ao monitorar o tráfego da API, a Optic reduz as chances de erro humano que acompanham as atualizações manuais, garantindo que a documentação da API seja sempre precisa. Facilita a colaboração: Optic facilita a colaboração no desenvolvimento da API. Com a geração automática de especificações de API atualizadas, os membros da equipe podem entender facilmente o estado atual da API e colaborar com mais eficiência. Melhora a experiência do desenvolvedor: com uma especificação OpenAPI atualizada e precisa, os desenvolvedores podem entender rapidamente como usar sua API, aprimorando sua experiência geral. Configurando a Optic Antes de mergulharmos, você precisará instalar o Optic. Certifique-se de ter o Node.js instalado em seu sistema, pois o Optic o exige. Você pode instalar o Optic globalmente usando o gerenciador de pacotes npm da seguinte forma: npm install -g @useoptic/cli Inicializando o Optic em seu projeto Depois de instalado, você precisa inicializar o Optic em seu projeto de API. Navegue até o diretório do seu projeto e execute: api init Isso configurará o Optic em seu projeto, criando um arquivo de configuração optic.yml onde você pode definir a configuração e as tarefas da API. Configurando sua tarefa de API No arquivo optic.yml, defina as tarefas para sua API. Uma tarefa representa um determinado estado de sua API, como executar seus testes ou executar sua API em desenvolvimento. Aqui está um exemplo de configuração de uma tarefa para uma API Node.js executada no host local e na porta 3000: tasks:my_api:command: npm startinboundUrl: http://localhost:3000 Neste exemplo, my_api é o nome da tarefa, command é o comando para iniciar sua API e inboundUrl é a URL em que sua API está sendo executada. Iniciando o Optic com sua API Para iniciar sua API com Optic, você pode usar o comando api start seguido do nome da sua tarefa: api start my_api Agora, a Optic está observando o tráfego da sua API, observando qualquer alteração no comportamento da API. Fazendo alterações e revisando-as com o Optic Digamos que você adicionou um novo endpoint ou modificou um existente. Quando você usa sua API ou executa seus testes, a Optic observará essas alterações e sugerirá atualizações para sua especificação de API. Para visualizar essas alterações, você pode abrir o painel Optic do seu navegador, normalmente em http://localhost:34444. No painel, você verá uma lista de endpoints. A Optic sinalizará quaisquer alterações observadas em seu comportamento de API, permitindo que você as revise, documente e aprove. Quando estiver satisfeito com as alterações, clique no botão "Aprovar" e a Optic atualizará sua especificação OpenAPI. Conclusão Em um cenário digital em rápida mudança, ter uma ferramenta como a Optic para automatizar a tediosa tarefa de manter suas especificações de API é inestimável. Ele melhora a eficiência e garante que a documentação da API seja precisa e atualizada, aprimorando a colaboração e aprimorando a experiência geral do desenvolvedor. Portanto, seja você um veterano em APIs ou apenas começando no desenvolvimento de APIs, o Optic é uma ferramenta que vale a pena explorar. Para mais informações, confira: https://www.useoptic.com

Qual a sua estratégia para migração de aplicações na sua organização? Em vários clientes que estamos atendendo, existem cenários que nos deparamos com inúmeros componentes legados nas organizações. Muito destes, são cruciais e fundamentais para o funcionamento dos negócios, porém, existem os desafios de fazer com que eles sejam modernizados da forma mais aderente as demandas de todas as indústrias no mercado. Padrão de Estrangulamento de Aplicações (Strangling Pattern) O Padrão de estrangulamento se tornou muito popular, tendo sido documentado no site microservices.io (https://microservices.io/patterns/refactoring/strangler-application.html), o objetivo deste padrão é fazer com que aplicações legadas possam ser alteradas de forma paulatina, mudando os serviços de maneira que os consumidores e os canais sejam impactados o mínimo possível. Tipos de Componentes Legados mais encontrados por nosso time de Consultoria Stored Procedures e componentes de Bancos de Dados Há mais de 20 anos atrás, era muito comum a construção de aplicações no modelo cliente-servidor (Client-Server), que poderia ser dividida em duas formas: Thin Client/Fat Server e Fat Client/Thin Server. Devido a capacidade computacional muito maior no lado servidor, o modelo Fat Server foi muito mais utilizado, o que resultou na criação de aplicações Desktop usando Delphi, Visual Basic, Fox pro, Oracle Forms, acessando Bancos de dados como inúmeras funções (Stored Procedures), devido ao grande poder dos bancos de dados da época, a exemplo, o Oracle, que possui o PL/SQL, que tem uma capacidade incrível para não só concentrar regras de negócios mas várias funções que facilitaram a construção de aplicações extremamente robustas. Vamos usar aqui um exemplo de arquitetura feita para um cliente com a combinação Delphi com Oracle: Muitos clientes possuem inúmeras regras de negócios, até integrações construídas com PL/SQL. Com a questão de suporte ao Windows, muitas destas aplicações por exemplo Delphi, mas até mesmo outras tecnologias da década de 90/2000 poderão ter problemas para continuarem em execução, por essa razão, algumas destas empresas estão literalmente desesperadas e a razão é "Como posso migrar para outro sistema essa solução, sendo que todas as minhas regras não conseguimos portar?" Qual foi a nossa proposta? Adquirir um novo ERP seria complexo, pois ainda haveria o problema de migração de regras de negócios. Sendo assim, o que sugerimos? 1- Um novo front-end single page application com Angular, portando a experiência de usuário do desktop, adicionando todas as melhorias dos dias modernos. 2- Esta nova aplicação SPA acessaria APIs REST, que atuam como fachadas para acesso a todas as funcionalidades e regras que estão ainda no Banco de Dados Oracle. 3 - O foco foram funcionalidades críticas, e com isso, novos usuários começaram a usar esse novo frontend, que interagia com os mesmos dados da aplicação legada Delphi. 4- Aos poucos, todas as funcionalidades foram portadas para a SPA, fazendo com que estas fossem 100% compatíveis com as funcionalidades da aplicação desktop Delphi. 5- Com os usuários migrados para essa nova UI na aplicação SPA, a aplicação desktop deixou de ser usada. 6- Com o uso das APIs, toda e qualquer funcionalidade escrita em PL/SQL poderia dar lugar a um novo microsserviço usando tecnologias como docker, kubernetes, protcolos como WebSockets etc. 7- A nova arquitetura além de microsserviços, agora possui 3 bancos de dados, algumas coisas ainda em Oracle, mas também convivendo com MongoDB e Redis. Benefícios para o Cliente e o Negócio Economia: O cliente não precisou investir num novo ERP, que seria um investimento significativo. Redução de Riscos de Migração e Customizações: Customizar um ERP trazendo regras já existentes é uma das tarefas mais arriscadas e também caras para modernizações neste sentido. Melhoria de Experiência: Usuários tiveram preservadas as funcionalidades do Desktop, com a riqueza de uma aplicação Single Page Application, com todas as melhorias aplicadas pela disciplinas de UX (User Experience). Atendimento de novos canais de negócios: Para acesso de terceiros ou parceiros, estes podem integrar através da APIs que agora agem como camada de entrada central para todos os serviços. Conclusão Este é um exemplo de trabalho que fazemos em vários clientes, atentando a particularidade de cada um deles, aplicando uma metodologia que chamamos de RNC(https://www.skalena.com/modernizacao-legados-skalena), em breve nós publicaremos a Parte II deste artigo, onde falaremos sobre estratégias para modernização WebServices/SOAP e na Parte III, sobre o conceito de Lift & Shift. Quer bater um papo, tomar um café ou até uma sessão de 30 minutos de conversa sobre estes e outros assuntos? Mande uma mensagem para a gente: https://www.skalena.com/contato

Construa dashboards sofisticados acessando suas bases da dados para exibir dados até mesmo em tempo real de várias fontes de dados. Dashboards & Business intelligence (BI) Esta é uma das áreas de tecnologia que possuem poucas soluções com uma versão interessante que seja open source, existem ferramentas fantásticas como Tableau, Power BI, mas muitas vezes trazem um custo que não consegue entrar nos orçamentos das empresas, ou mesmo começando mais econômicas, sofrem de usabilidade e na curva de aprendizagem. Isto era uma realidade até a chegada do Metabase. Começamos a usar o Metabase em um projeto interno, que estava nos demandando a criação de muitas páginas com gráficos e dashboards, e por mais que fossem criadas todas as possíveis visualizações, com certeza, novas seriam pedidas pelos clientes, daí a necessidade de termos uma solução neste sentido: Que pudesse extrair as informações de diferentes fontes de dados, e oferecesse uma forma fácil e rica de apresentá-los. Abaixo as possíveis bases de dados e repositórios de informações suportadas: Construindo Dashboard enriquecidos de informações Basicamente o que você precisa é saber SQL, sim, apenas SQL! Ai você vai perguntar e aqueles recursos hipsters tipo GraphQL? Não será necessário. Se você não tem familiaridade com SQL, você poderá ter que aprender alguns conceitos, mas se você se sente confortável com esta linguagem, você já está há 80% de entender como funciona o Metabase. Visualizações Quando a gente realiza as consultas, de cara, nós temos a possibilidade de definir como iremos exibir as informações, sejam em tabela, como na imagem acima, ou ainda em diversas formas gráficas como as exibidas na barra de ferramentas da mesma imagem. Conclusão Se você quiser saber mais como usar o Metabase, entre em contato com nosso time, será um prazer poder demonstrar como esta solução pode ajudar sua organização.

Rappi: Cenário de microsserviços de grande volume em plataforma de e-commerce com KrakenD Rappi é um aplicativo que auxilia os usuários em suas necessidades diárias de compras. De restaurantes, supermercados, farmácias, bebidas espirituosas, viagens, entregas, produtos fintech e muito mais. De forma geral, é uma empresa especializada em logística de entrega que superou os 3 bilhões de dólares de valor de mercado em apenas 4 anos! Cenário Inicial No nível técnico, Rappi é uma grande plataforma de comércio eletrônico e um dos 100 maiores consumidores de recursos da AWS em todo o mundo, executando sua plataforma, em números temos: "Mais de 7000 servidores EC2 e mais de 1.800 nós no EKS (Kubernetes). Sua stack é executada na AWS (Amazon Web Services) em uma combinação dupla de ECS e Kubernetes. Mais de 750 desenvolvedores de todos os tipos podem escolher sua linguagem de codificação, e a equipe Infra (Cloud Engineering - 70 pessoas) fornece as ferramentas necessárias para torná-lo realidade. Uma das ferramentas que permitem a agregação de serviços heterogêneos é o KrakenD. O Rappi executa mais de 2.000 microsserviços (em vez de nano serviços) no ECS e outros 1.500 microsserviços para o serviço Rappi Pay. Rappi conseguiu destruir o monólito em 2021, pudemos ver seus desenvolvedores bebendo em canecas e camisas com o slogan: "Eu matei o monólito” Como KrakenD ajudou Rappi? Antes da adoção do KrakenD, todas as equipes estavam desenvolvendo soluções personalizadas para resolver problemas transversais. No entanto, a Rappi queria padronizar as soluções para problemas comuns em seus microsserviços e acelerar o processo de desenvolvimento. Por exemplo, eles precisavam da validação do JWT na frente de todos os seus serviços, então adotaram Auth0 como provedor de identidade e KrakenD como validador front. A Rappi testou outras soluções antes de adotar o KrakenD, mas eles queriam uma solução simples com funcionalidades poderosas além de um “roteador simples”. Como resultado, a implementação completa do KrakenD na Rappi levou apenas 1 mês, apesar da complexidade organizacional. A Rappi opera hoje +20 gateways KrakenD diferentes (em vários containers cada) que agregam e oferecem acesso a um vasto catálogo de serviços. Cada gateway fornece um grupo funcional, como por exemplo, um “gateway de pedidos”. Os gateways da API KrakenD são servidos em um DNS comum como exemplo services.rappi.com colado com um roteador. Todas as métricas do KrakenD são enviadas para o Splunk SignalFX onde a Rappi pode acompanhar a evolução de seus serviços de forma centralizada. Conforme a configuração, a config do KrakenD é gerada automaticamente através de um arquivo YAML de parâmetros que define as regras para construir o layout final. Ele usa um modelo Jinja com mais de 35.000 linhas de condições, dando uma ideia da complexidade que uma organização como a Rappi suporta. Resultados e Planos Futuros O futuro do KrakenD na Rappi é brilhante, pois provou nos últimos dois anos que é uma ferramenta confiável e fácil de configurar. Nas palavras do próprio Nicolás Vila: "Nós não tivemos que lutar” A KrakenD ofereceu à Rappi a ferramenta de padronização necessária para consumir um número tão impressionante de microsserviços. Ao mesmo tempo, a simplicidade e flexibilidade do KrakenD permitiram à Rappi ajustar a configuração do KrakenD às suas ferramentas de integração contínua. O KrakenD foi adotado na Rappi em maio de 2020 e hoje continua a fornecer conteúdo para sua enorme base de usuários, oferecendo um serviço de API confiável que não causou nenhum tempo de inatividade. Sobre os autores Este estudo de caso foi escrito durante uma entrevista com Nicolás Vila (Cloud Architect), Ezequiel Arielli (Cloud Architect) e Carlos Castro (Tech Lead) @Rappi que participou da adoção do KrakenD e modernização de sua stack nos últimos dois anos . Tradução e Revisão Carolinne Morais Customer Success - Skalena Ltda Fonte: https://www.krakend.io/case-study/rappi/

O que é Architecture Decision Records (ADR)? Architecture Decision Record (ADR) é uma técnica de documentação utilizada pela maioria das empresas para documentar decisões importantes tomadas pelos membros da equipe e deixar registrado principalmente suas consequências. Como surgiu o ADR? Architecture Decision Record foi criado por Michael Nygard, com o intuito de deixar as decisões com grandes impactos na empresa salvas, tendo um fácil entendimento e as tornando uma documentação pratica, pois para ele as reuniões não encareciam de documentos altamente formais. Benefícios de implementar ADR Onboarding Rapidamente novos membros entendem as motivações e consequências das decisões no stack e em todas as tecnologias da Arquitetura. Passagem de Ownership Uma ADR pode ser passada para ser melhorada, ou versionada de uma Squad para outra, desde que todo o histórico de mudanças sejam rastreável Alinhamento: ADRs fazem com que haja alinhamento entre os times e remove esforços duplicados, criado códigos e APIs reusáveis ao longo dos projetos reduzindo a variância de soluções que times centrais devem suportar Quando implementar uma ADR? Então chegamos ao ponto de saber: Quando e como escrever um ADR? No momento em que houver uma decisão de impacto significativo tomada pelo time, deve ser escrito sempre um ADR. E de forma bastante simples, Michael Nygard propõem que time registre basicamente o contexto do problema, possíveis soluções, a decisão tomada e consequências usando um template markdown com algumas seções. Template de um ADR Um ADR leve, consiste em título, status, contexto, decisão e consequência (de acordo com @mtnygard). Modelo de template à seguir: Título: Deve ser curto e descritivo. Data: dd/mm/yyyy Status Proposta: A decisão ainda não foi aprovada. Aceita: Se foi aceita. Depreciada: Se não faz mais sentido. Substituída: A decisão foi substituída por outra em algum momento Rejeitada: A decisão inicialmente proposta foi rejeitada Contexto Traz as considerações e forças que levaram a tomar a decisão, incluindo tecnológicas, políticas, econômicas, sociais e relativas ao projeto. Decisão Descrição das decisões tomadas frente às forças e considerações, em voz ativa, sentenças completas e organizadas em parágrafos. Consequências Descrição das consequências após a tomada da decisão, incluindo as positivas e as negativas, quando houver. Tudo que puder afetar o time e o projeto deve ser registrado. Exemplos de um ADR Exemplo 1: No contexto do serviço de venda Web, Enfrentando a necessidade armazenar os dados de sessão de usuário e de forma consistente e atual através das instâncias das lojas Nós decidimos por usar o Database Session State Pattern E contra o Client Session State or Server Session State Para obter consistência e elasticidade de cloud Aceitando que a sessão de banco de dados precisa ser desenhada e implementada. Exemplo 2: Empresas que utilizam ADR O Spotify, é umas das maiores empresas do ramo da musica e é um belo exemplo de onde é implementado um ADR, a empresa utiliza o documento em vários departamentos da empresa para que os criadores de conteúdo consigam acessar seus avanços e ver as decisões tomadas pelos outros membros dos projetos, outra empresa do meio da Tecnologia que utiliza a técnica ADR, é a Conta Azul que é uma empresa de Software que vende e desenvolve uma plataforma de gestão de negócios. Conclusão Contudo conclui-se que um ADR(Architecture Decision Record) é um documento primordial para todas as empresas independente de se considerarem uma empresa de alto ou baixo porte, pois o mesmo oferece mais praticidade na organização e na visualização de ideias relativas em suas reuniões e assim conseguindo chegar em uma posição final dos projetos. Referências: https://engineering.atspotify.com/2020/04/when-should-i-write-an-architecture-decision-record/ Autores Crystian Printes Trainee na Skalena, estudante de Sistemas de Informação na Universidade Federal do Oeste do Pará. Luciana Lopes Trainee na Skalena, estudante de Sistemas de Informação na Universidade Federal do Oeste do Pará.

Além do KrakenD ser uma solução de API Gateway extremamente performática, ela ainda também apresenta versatilidade e facilidade para uso. O exemplo que vamos apresentar agora é muito útil em cenários que você tem que realizar o deploy das configurações do gateway em diferentes ambientes, isto pode ser na execução de pipelines CI/CD, que facilita muito o suporte para essa dinamismo em ambientes como Docker e até Kubernetes. Sem mais delongas, vamos ao exemplo proposto, veja a estrutura de nosso exemplo: ├── Dockerfile ├── krakend.json Vamos docker para mostrar a simplicidade do uso de variáveis de ambiente no arquivo de configuração do KrakenD (krakend.json). O KrakenD Config O arquivo de configuração do KrakenD é usualmente em formato JSON (mas suporta outros formatos também, como YAML/YML). Neste arquivo é exatamente onde definimos os endpoints, as configurações, os hosts, timeouts etc. Como exemplo do krakend.json , vamos pegar um exemplo simples: { "$schema": "https://www.krakend.io/schema/v3.json", "version": 3, "extra_config": { "telemetry/logging": { "level": "DEBUG", "prefix": "[KRAKEND]", "syslog": false, "stdout": true, "format": "default" } }, "timeout": "3000ms", "cache_ttl": "300s", "output_encoding": "no-op", "name": "APIS-Sample", "endpoints": [ { "endpoint": "/v1/cep/{CEP}", "timeout": "10s", "method": "GET", "output_encoding": "no-op", "extra_config": {}, "backend": [ { "url_pattern": "/ws/{CEP}/json/", "encoding": "no-op", "method": "GET", "extra_config": {}, "host": [ "{{ env "ENDPOINT" }}" ], "disable_host_sanitize": false } ] } ] } Dica: Quem quiser ler um JSON de forma mais simples, recomendamos essa ferramenta online: http://json2table.com Lendo este arquivo de configuração de forma mais visual como está abaixo, podemos entender de forma simples ao que este arquivo se destina: Neste exemplo, podemos entender o seguinte: Temos uma API declarada, com o endereço /v1/cep/{CEP} que é uma chamada do tipo GET, que chama um Endpoint no host como exemplo em questão: http://meuhost.com.br , neste caso, este valor de HOST, pode ser diferente de acordo com o ambiente, por exemplo: LOCAL: http://localhost:8080 Homologação: https://qa.meuserver.com.br Produção : https://meuserver.com.br Dessa forma, ao invés de ter 1 arquivo de configuração para cada ambiente, podemos ter 1 único arquivo que pode inserir valores dinâmicos, de acordo com as variáveis de ambiente, por isto, nós temos essa referência a uma variável de ambiente ENDPOINT, que está declarada no arquivo de configuração, veja o exemplo: "host": [ "{{ env "ENDPOINT" }}" ], Com base nesse exemplo acima, poderemos apontar o endereço de forma contextual e usando o Docker para isto. Nós criamos um arquivo Dockerfile para empacotar nossas APIs: FROM devopsfaith/krakend COPY config/krakend.json /etc/krakend/krakend.json ENTRYPOINT [ "/usr/bin/krakend" ] CMD [ "run", "-c", "/etc/krakend/krakend.json"] Você precisará fazer o build dessa imagem Docker antes de executá-la, pode usar o comando abaixo: docker build -t /krakend-env-vars . E no momento que for executar seu container, levando em consideração que nossa imagem tem o nome de: skalenatech/krakend-env-vars : docker run -e "ENDPOINT=https://viacep.com.br/" -e "FC_ENABLE=1" -p 8080:8080 skalenatech/krakend-env-vars Veja que nós passamos 2 variáveis de ambiente para execução do Docker: FC_ENABLE=1 - Isto irá informar o KrakenD runtime que ele deverá ler informações externas, entre estas: variáveis de ambiente. ENDPOINT - O endereço do seu endpoint que será injetado no seu arquivo de configuração. A execução deste exemplo resulta nos seguintes screenshots : Execução KrakenD via docker, veja agora a execução: Conclusão O arquivo krakend.json é o coração da execução do runtime para as APIs, e existem várias boas práticas para torná-los mais dinâmicos, aqui vimos uma das estratégias, mas existem outras. Referências: https://www.krakend.io/docs/configuration/environment-vars/

Nota: Este post se refere a versão 1.4 do KrakenD Neste post, iremos mostrar o KrakenD API Gateway (de acordo com benchmarks públicos o mais performático do mercado) integrado ao RabbitMQ, um popular middleware de processamento de mensagens. Nosso exemplo irá seguir o seguinte exemplo: No caso acima, o KrakenD fornecerá um back-end pronto para uso para publicar uma mensagem na troca especificada no RabbitMQ. Componentes que usaremos Docker - para executar facilmente o RabbitMQ Binário KrakenD (mas você também pode usar a distribuição do Docker) Primeiros Passos Executando o servidor RabbitMQ e o console de gerenciamentoPor favor, execute o seguinte comando docker: docker run -it --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3-management O resultado será o seguinte no seu console: Você poderá ver a ferramenta web de gestão do RabbitMQ como no exemplo abaixo: (Observe que a porta de saída para o Management Console é 15672. Criando a configuração do KrakenD Este post é baseado na seguinte página de documentação: https://www.krakend.io/docs/backends/pubsub/, nesse caso usaremos KrakenD para definir automaticamente um Backend para publicar um Payload (conteúdo) como uma mensagem, e podemos conseguir consequentemente, lê-lo de volta (o consumindo [ Consumer] ). Se o backend que interage com sua camada de mensagens exige muita complexidade, regras de negócios, etc, recomendamos que crie um backend específico para tratá-lo sem limitações e capaz de fazer o que você precisar, em qualquer nível de customizações. Veja aqui o código fonte do arquivo krakend.json : { "version":2, "port":8080, "endpoints":[ { "endpoint":"/produce/{key}", "method":"POST", "backend":[ { "extra_config":{ "github.com/devopsfaith/krakend-amqp/produce":{ "exchange":"testdiuscoa", "durable":true, "delete":false, "exclusive":false, "no_wait":true, "mandatory":true, "immediate":false, "name":"radiuscoa", "routing_key":"Key" } }, "host":[ "amqp://guest:guest@localhost:5672" ], "disable_host_sanitize":true } ] }, { "endpoint":"/consume", "backend":[ { "extra_config":{ "github.com/devopsfaith/krakend-amqp/consume":{ "name":"queue-1", "exchange":"testdiuscoa", "durable":true, "delete":false, "exclusive":false, "no_wait":true, "no_local":false, "routing_key":[ "#" ], "prefetch_count":10 } }, "host":[ "amqp://guest:guest@localhost:5672" ], "disable_host_sanitize":true } ] } ] } Ao executar o KrakenD com o seguinte comando : krakend run -c krakend.json Você precisa ter o binário do krakend instalado para executar este exemplo O console irá exibir a seguinte saída no console: Agora podemos testar os endpoints expostos pelo KrakenD que podem publicar as mensagens: curl -i --location --request POST 'http://localhost:8080/produce/foo' --data-raw '{"foo":"bar"}' HTTP/1.1 200 OK **Content-Type**: application/json; charset=utf-8 **X-Krakend**: Version 1.1.1 **X-Krakend-Completed**: false **Date**: Wed, 18 Nov 2020 06:12:28 GMT **Content-Length**: 5 null Veja que a publicamos via HTTP POST um payload com o conteúdo em formato JSON, com uma propriedade chamada foo e o seu conteúdo bar. O API Gateway retornou um HTTP 200 OK, ou seja, uma resposta com sucesso, não existe mensagem de retorno por padrão, vamos nos basear no código de retorno HTTP. Este Payload publicado, está agora na fila do RabbitMQ chamada de queue-1, e agora espera que algum consumidor poderá ler esta mensagem e processá-la. O KrakenD também tem a capacidade de consumir estas mensagens da fila, e consequentemente chamar outros microsserviços/endpoints etc. curl -i --location --request GET 'http://localhost:8080/consume' HTTP/1.1 200 OK **Content-Type**: application/json; charset=utf-8 **X-Krakend**: Version 1.1.1 **X-Krakend-Completed**: true **Date**: Wed, 18 Nov 2020 06:15:53 GMT **Content-Length**: 14 {"foo":"bar"} Dessa vez, ao invés de um POST , estamos chamando um HTTP GET, este por sua vez, irá ver se existe alguma mensagem na fila do RabbitMQ e nos retornar os dados, tanto que você pode ver o conteúdo do Payload, que é o mesmo enviado anteriormente. Se você receber algum erro ou não funcionar conforme demonstrado, adicione a seguinte variável de ambiente: export RABBIT_SERVER_URL='guest:guest@localhost:5672' Conclusão Este é um post que é a tradução de um material nosso em Inglês de 2020 (https://skalena.github.io/api-methodology/public/cont/krakend-with-rabbitmq/) , que resolvemos deixá-lo em Português também, para servir de referência para a comunidade e empresas que usam o KrakenD. Atualizações no KrakenD 2.0 No KrakenD 2.0, existem algumas atualizações para tratar processamento de mensagens, para conferir veja este post: https://www.skalena.com/post/krakend-2-0-community Async API Vale a menção deste conceito novo, que permite o processamento orientado a eventos (assíncrono) para canais e consumidores que processam informações usando as APIs como ponto de entrada, confira mais aqui: https://www.asyncapi.com

por Albert Lombarte Mar 7, 2022 KrakenD 2.0 é a nova versão principal do KrakenD trazendo muitas melhorias para o API Gateway. GraphQL, plugins de request/modifier específicos, agentes assíncronos, fácil configuração, melhor registro e um roteador mais flexível. Guia de migração Se você é um usuário existente do KrakenD, leia “Migrando do KrakenD 1.xe 0.x”. O que há de novo? As adições e mudanças mais relevantes no KrakenD 2.0 são: GraphQL Conversão de REST para GraphQL ou consumo direto de GraphQL por meio do gateway. Use o GraphQL para definir novas consultas de back-end e expô-las como endpoints REST regulares para seus clientes, federar conteúdo. Documentação GraphQL Novos tipos de plug-ins Os modificadores de plug-in de solicitação/resposta são dois novos tipos de plug-ins Go para modificar diretamente solicitações e respostas de e para back-ends, complementando os plug-ins de manipulador e cliente existentes. Os usuários que estão atualmente usando lógica personalizada em scripts Lua podem aumentar seu desempenho. Documentação do modificador de plug-in Sinalizadores de roteador configuráveis Existem muitos sinalizadores de roteador configuráveis, como retornar o erro de gateway para o cliente (por exemplo: um tempo limite), opções de redirecionamento, OPÇÕES automáticas, melhores maneiras de obter o IP real (incluindo por meio de proxies confiáveis) ou remover entradas dos logs, e como ocultar o ponto de endpoint /__health. Veja todos os novos sinalizadores de roteador Mais amigável ao desenvolvedor O KrakenD sempre foi fácil de configurar, mas queríamos melhorar os logs e as informações disponíveis durante o desenvolvimento: O comando krakend check adiciona agora vários níveis de detalhamento e cores de depuração para facilitar a compreensão da configuração Um novo comando krakend check-plugin permite que você verifique a compatibilidade de seus plugins personalizados Reduzimos e classificamos todos os namespaces extra_config, para melhor compreensão e uso dos componentes. Quando havia um componente semelhante a URL, como "github_com/devopsfaith/krakend-cors", agora se torna uma categoria/funcionalidade como "security/cors". Uma nova ferramenta de migração cuida da transição de 0.xe 1.x para 2.x para tornar o processo simples. Logs melhores com mais contexto. Todas as linhas de log foram reescritas, adicionando um prefixo que as agrupa com mais informações, como qual endpoint ou backend levantou a linha de um componente específico. Plugins com acesso ao logger: Se você tinha plugins personalizados, agora eles podem usar o registrador KrakenD para enriquecer a saída do seu gateway. Imagem do Docker baseada em Alpine: Imagem do Docker que se estende do Alpine, tornando-a uma imagem muito leve e sem arrastar todos os problemas de segurança de contêineres maiores como o Debian. Agentes assíncronos Antes desta versão, qualquer atividade do KrakenD era precedida por uma chamada para a API. Agora, o KrakenD é capaz de ouvir filas e atuar como consumidor ou produtor por conta própria, sem exigir uma solicitação do usuário final. Por exemplo, quando o KrakenD detecta que uma nova mensagem entrou em uma fila (muitas tecnologias suportadas), ele pode acionar uma chamada para um back-end de sua escolha. Documentação de agentes assíncronos. Migre agora para o KrakenD 2.0! A sintaxe de configuração do KrakenD mudou um pouco do KrakenD 1.x. Execute a ferramenta de migração para aplicar essas alterações automaticamente. Migre agora clicando aqui! Autor Albert Lombarte (KrakenD) Tradução e Revisão Carol Morais (Skalena Ltda) Customer Success