GraphQL: Arquitetura de serviços no Medium

Image for post
Image for post

Há um tempo, contamos a história de como estamos migrando para o React.js e uma arquitetura orientada a serviços com a ajuda do GraphQL. Agora, queremos contar a história de como a estrutura do nosso servidor GraphQL ajudou a tornar nossa migração muito mais suave.

Tínhamos três coisas em mente quando começamos a projetar nosso servidor GraphQL:

Deve ser fácil alterar a forma dos dados

Atualmente, usamos protocol buffers como um esquema para dados do nosso back-end. No entanto, a maneira como usamos nossos dados mudou ao longo do tempo, mas nossos protobufsnão evoluiram. Isso significa que nossos dados nem sempre têm a forma que os clientes precisam.

Deveria ficar claro quais dados são para o cliente

No nosso servidor GraphQL, os dados estão sendo transmitidos e existem em diferentes estágios de “prontidão” para o cliente. Ao invés de misturar os estágios, queríamos tornar explícito os estágios de prontidão, para sabermos exatamente o que os dados significam para o cliente.

Deveria ser fácil adicionar novas fontes de dados

Como estamos migrando para uma arquitetura orientada a serviços, queríamos garantir que fosse fácil adicionar novas fontes de dados ao nosso servidor GraphQL e deixar explícito de onde vêm os dados.

Com isso em mente, criamos uma estrutura de servidor com três funções distintas.

Fetchers (Buscadores), Repositories (Repositórios) e o Schema(Esquema) do GraphQL.

Image for post
Image for post

como as camadas de bolo de responsabilidades

Cada camada tem suas próprias responsabilidades e somente interage com a camada acima dela. Vamos falar sobre o que cada camada faz especificamente.

Fetchers

Image for post
Image for post

buscar os dados de qualquer número de fontes

Os Fetchers buscam dados em fontes de dados. Os dados que são buscados pelo servidor GraphQL já devem ter passado por quaisquer adições ou alterações na lógica de negócios.

Os Fetchers devem corresponder a um endpoint REST ou preferencialmente a um gRPC. Fetchers requerem um protobuf. Isso significa que todos os dados que estão sendo buscados por um Fetcher devem seguir o esquema definido pelo protobuf.

Repositories

Image for post
Image for post

moldar os dados para o que o cliente precisa

Os repositórios são o que os esquemas do GraphQL usarão como representação de dados. O repositório “armazena” os dados limpos e originais de nossas fontes de dados.

Nesta etapa, elevamos (hoist up) e nivelamos (flatten) campos e objetos, movemos dados, etc. Alterando a forma dos dados para ser da forma que o cliente realmente precisa.

Essa etapa é necessária para a mudança de um sistema legado, pois nos dá a liberdade de atualizar o formato dos dados para o cliente sem precisar atualizar ou adicionar endpoints ou seus protobufs correspondentes.

Os repositórios acessam apenas os dados recuperados dos Fetchers e nunca realmente os buscam. Em outras palavras, os repositórios apenas criam a forma dos dados que queremos, mas eles não “sabem” de onde obtemos os dados.

Esquema GraphQL

Image for post
Image for post

derivar o esquema para o cliente baseado nos nossos objetos do repositório

O esquema do GraphQL é o formato que nossos dados terão quando forem enviados aos clientes.

O esquema do GraphQL usa apenas dados dos repositórios e nunca acessará os Fetchers diretamente. Isso mantém clara a nossa separação de preocupações.

Além disso, nosso esquema GraphQL é completamente derivado de nossos objetos nos repositórios. O esquema não altera os dados, nem precisa: o repositório já mudou a forma dos dados para ser o que precisamos, portanto, o esquema precisa apenas usá-los e é isso. Dessa forma, não há confusão sobre qual é a forma dos dados ou onde devemos manipular/transformar os dados.

Fluxo de Dados do Servidor GraphQL

como os dados fluem através do nosso servidor GraphQL

A forma dos dados se torna mais parecida com o que o cliente precisa ao passar por cada uma das camadas distintas. É claro de onde vêm os dados em cada etapa e sabemos pelo que cada parte do servidor é responsável.

Esses limites de abstração significam que podemos migrar incrementalmente nosso sistema legado, substituindo diferentes fontes de dados, mas sem reescrever todo o sistema. Isso tornou nosso caminho de migração claro e fácil de seguir e facilita o trabalho em direção à nossa arquitetura orientada a serviços sem alterar tudo de uma vez.

Créditos

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store