GraphQL: Arquitetura de serviços no Medium
Tags: ptbr, graphql, webdev, architecture
Published: 2020-01-24 00:15:24

Há um tempo, [contamos a história](https://medium.engineering/2-fast-2-furious-migrating-mediums-codebase-without-slowing-down-84b1e33d81f4) 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*](https://en.wikipedia.org/wiki/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 *protobufs* nã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.

![](https://miro.medium.com/max/3604/1*HcISBhsiC8gaLbfanw4L1A.png)
_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

![](https://miro.medium.com/max/2806/1*BmEv_S_KuHP2NJJbcU1qzw.png)
_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

![](https://miro.medium.com/max/3166/1*KDWPV1Q40zj6QFlAKgwpmw.png)
_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

![](https://miro.medium.com/max/2880/1*B0nY7N8wYNlWOCEJba7CwQ.png)
_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

![](https://miro.medium.com/max/2474/1*VCs9aXb1RdBFYMhoFJsjjw.png)
_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

- [GraphQL Server Design @ Medium](https://medium.engineering/graphql-server-design-medium-34862677b4b8), escrito originalmente por [Sasha Solomon](https://twitter.com/sachee).