• GraphQL Server Design @Medium
  • Sasha Solomon
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: EmilyQiRabbit
  • Proofread by KarthusLorin, Weibinzhu

Medium GraphQL service design

Some time ago, we showed you how to use GraphQL to migrate projects to React. Js and a service-oriented structure. Now, we want to show you how the GraphQL service structure helps smooth out the migration.

Before we start designing the GraphQL service, we must keep three things in mind:

At present we use protocol buffers as the data model schema from the back end. But the way we use data changes, and protocol buffering doesn’t follow. This means that our data format is not always what the client needs.

In the GraphQL service, the data being passed is at various stages of the client’s “ready” stage. Instead of mixing them up, we should make each ready state clearer so that we know exactly what data is being used by the client.

Now that we’re transitioning to a service-oriented structure, we want to make sure that adding new data sources to the GraphQL service is easy and that the data source is clear.

With this in mind, we can construct a service framework with three different roles:

Fetchers, repositories (Repos), and GraphQL schemas.

Responsibility block

Each layer has its own responsibilities and only interacts with its top layer. Let’s talk about exactly what each layer does.

Getter Fetchers

Get data from any number of sources

The purpose of a getter is to get data from a data source. The data retrieved by the GraphQL service should have been added or changed to the business logic.

The getter should correspond to a REST or gRPC port. The getter requires a protocol buffer protobuf. This means that any data retrieved by the getter must follow the schema defined by the protocol buffer.

The repository

Design data according to client needs

The GraphQL model uses repositories as data warehouses. The repository “stores” processed data from the data source.

In this step, we can package or expand fields and objects, move data, and so on, converting the data into the format the client needs.

This step is necessary to transition from legacy systems because it gives us the freedom to update data formats for clients without updating or adding interfaces and corresponding protocol buffers.

The repository only gets data from the getter and never actually requests external data itself. In other words, repositories create only the data formats we need, but they don’t “know” where the data is fetched from.

GraphQL model

Derive the client model from the repository object

The GraphQL model is the format selected when data is sent to the client.

The GraphQL model only uses data from the repository and never interacts directly with the getter. This allows for a clear separation of concerns.

In addition, the GraphQL model is completely derived from the repository model. The model doesn’t change the data at all, and it doesn’t need to: the repository has already converted the data into the format we want, so the model just needs to use the data. There is no confusion about what data formats look like or where we can manipulate them.

GraphQL service data stream

How does data flow through the GraphQL service

As the data moves through different layers, its format becomes more like what the client needs. It’s clear where the data comes from for each step, and we know what each part of the service is responsible for.

These abstract boundaries mean that we can incrementally migrate legacy systems by replacing different data sources without rewriting the entire system. This makes our migration approach clear and easy to follow, while making it easy to work toward a service-oriented architecture without changing everything at once.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.