GraphQL for service-to-service communication protocol

In this presentation I'll talk in the "microservices architecture" context

I think many people use REST / gRPC

=> I'm always thinking "why not graphql"

public GraphQL (aggregation), internal REST / gRPC

So far I often saw such pattern

To be honest I also have chosen this architecture once

and failed

=> why not graphql also for internal communication

They usually say that "no need to use graphQL because the cost of internal communication is low"

3 reasons why we should use GraphQL for communication between microservices

1. Easy to evolve our services

2. Good API Interface and documentation system

3. Easy to make GraphQL Aggregation Layer for Frontend

Make our services easy to evolve

Why

(In the microservices context,) Services need to be evolved independently

We often want to make changes for APIs, explicitly or implicitly

All the changes possibly break the consumers using that service

(e.g. delete existing element from payload, etc...)

How?

Two important points

Consumer won't be broken by unrelated change

In GraphQL world, consumers are always Tolerant Readers :automaticyusho:

Consumers explicitly define what they need, so they never be broken if some fields they doesn't use are deleted

Provider can be aware when a change will break some consumers

How providers can be aware the breaking changes of itself?

e.g. I want to delete this field of an endpoint

Three ways

Use Contracts between consumer and provider (c.f. Consumer-driven Contract Testing)

Check Production Logs

for example, count the endpoint calling by checking nginx logs

Share or ask to other teams manually

It's necessary anyway, but we want to reduce it

Use Contracts between consumer and provider (c.f. Consumer-driven Contract Testing)

Here "Persisted Query" comes in

Persisted Query is basically a technique that client should register the queries before they use it

It can be regarded as Providers

Check Production Logs

On RESTful / gRPC, we can check logs per endpoints

cannot check in field-level

On GraphQL, can check in field-level

So, GraphQL Query can solve both

Good API Interface and documentation system

No need to describe more from me. GraphiQL perfectly works

Conclusion:

GraphQL is also good for service-to-service communication

I think it's the best choice for many organization