![Crédito da foto: Ken Yeung/VentureBeat](https://optimuscloud.com.br/wp-content/uploads/2024/05/1716571325_As-4-maneiras-pelas-quais-os-PCs-Copilot-da-Microsoft-150x150.jpg)
As 4 maneiras pelas quais os PCs Copilot+ da Microsoft remodelarão a computação empresarial
24 de maio de 2024![Korifi na KubeCon + CloudNativeCon EU 2024: principais vantagens](https://optimuscloud.com.br/wp-content/uploads/2024/05/1716573605_Korifi-na-KubeCon-CloudNativeCon-EU-2024-principais-vantagens-150x150.jpg)
Korifi na KubeCon + CloudNativeCon EU 2024: principais vantagens
24 de maio de 2024A engenharia de plataforma emergiu como uma disciplina fundamental para desbloquear a velocidade do desenvolvedor em arquiteturas nativas da nuvem. Desde a infraestrutura provisionada e orquestrada com Terraform e Kubernetes até a microcópia no frontend que é fornecida com um CMS headless, as equipes de engenharia estão escolhendo plataformas centralizadas para manter os componentes principais de sua arquitetura. Essas ferramentas não apenas eliminam tarefas redundantes — elas capacitam as equipes de engenharia de produto a fornecer recursos com mais rapidez, executar experimentos com menos trabalho e se concentrar menos na infraestrutura e mais nas necessidades do negócio.
É mais fácil do que nunca automatizar o provisionamento de infraestrutura e as políticas de segurança. Apenas um ano e meio depois que o ChatGPT tornou os “recursos de IA” um requisito repentino para todos os aplicativos, agora existem inúmeras empresas de “infraestrutura de IA como serviço”. Mas e quanto a um ingrediente-chave para qualquer arquitetura nativa da nuvem: APIs?
Embora inúmeras ferramentas simplifiquem e automatizem outros componentes essenciais das arquiteturas modernas nativas da nuvem, ainda contamos com back-ends para front-ends (BFFs) individuais e escritos à mão para fornecer todos os recursos de back-end para cada front-end.
A menos que a IA possa escrever uma série de backend-para-frontends usando REST por si só (pode?), precisaremos de uma solução melhor se quisermos reduzir o código clichê e fornecer funcionalidade em todas as nossas interfaces com mais rapidez.
Entre na Federação GraphQL
Para um desenvolvedor de API individual que está se esforçando, o GraphQL parece uma nova maneira de reduzir a superbusca e a subbusca entre clientes. Mas, quando entregue em escala, o GraphQL também fornece um ingrediente chave para melhorar a velocidade do desenvolvedor nas equipes de engenharia. GraphQL reduz o atrito entre o frontend e o backend. Quando entregue em escala, a federação GraphQL permite que as equipes da plataforma de API exponham qualquer número de APIs como um gráfico de autoatendimento e autodocumentação chamado “supergráfico”. Esse supergráfico abstrai a complexidade da API e separa o front-end do back-end, permitindo que ambas as equipes trabalhem com mais rapidez.
Veja como funciona:
- Os desenvolvedores de back-end contribuem com APIs GraphQL individuais ao supergrafo, que define os tipos e seus relacionamentos como um esquema.
- Um processo chamado composição combina esses esquemas de subgrafo em um único esquema unificado, automática ou manualmente.
- As equipes dos clientes têm autonomia para buscar todos os dados de que precisam do supergráfico usando um único ponto final — não importa onde os dados estejam armazenados.
A federação GraphQL oferece suporte a uma melhor estratégia de plataforma das seguintes maneiras:
- Reduzindo gargalos para enviar mudanças com segurança: como o GraphQL não requer versões, as equipes podem implementar mais recursos sem uma cadeia de e-mails passivo-agressivos ou reuniões intermináveis para evitar alterações significativas.
- Reduzindo a carga cognitiva para consumir uma API: para equipes de clientes, o GraphQL fornece uma linguagem de consulta declarativa que permite que as equipes de clientes busquem todos os dados de que precisam. Basta usar a introspecção para ver quais dados estão disponíveis, descrever os dados necessários para sua aplicação e você estará pronto para a corrida.
- Reduzindo a dívida técnica: Você sabe o que leva mais tempo do que escrever um backend para frontend para uma única interface? Escrevendo 50 backend para frontends. GraphQL pode atender a qualquer número de aplicativos, portanto não é necessário escrever ou manter um BFF para cada um.
- Melhorando a consistência entre aplicativos: quando os tipos e seus relacionamentos são claramente definidos na própria API, há menos trabalho para garantir a consistência entre as interfaces.
- Complexidade abstrata da API existente: GraphQL é frequentemente visto como uma alternativa ao REST. Mas o GraphQL pode buscar dados de outros endpoints REST. Ele fornece uma camada de abstração personalizada para ajudar as equipes a fornecer recursos com mais rapidez.
Ao pensar em sua estratégia de plataforma, lembre-se de que ela vai além da infraestrutura. Freqüentemente, há muitos atritos entre o back-end e o front-end que você pode resolver facilmente com GraphQL. Baixe o white paper “Engenharia de plataforma para APIs” para saber por que o GraphQL está rapidamente se tornando uma linguagem adotada pelas equipes de plataforma de API para melhorar a eficiência e a velocidade do desenvolvedor.
A postagem Federação GraphQL: a API que falta para sua estratégia de plataforma apareceu pela primeira vez em The New Stack.