Recommendation for using gRPC in Federation architecture

[ankit-joinwal]

Hi,

Wanted to explore the possibility of using gRPC for communication between Federation Gateway and downstream services?
Is it followed at Netflix? I did read somewhere that Netflix uses gRPC for internal services.
Are the DGS services in Netflix supporting both GraphQL and gRPC or gRPC services are separated from GraphQL services?

[berngp]

The Gateway does not translate from GraphQL to gRPC. Application developers that decide their app be part of the federated grapgh implement their GrapghQL endpoint, mostly via DGS, even if they already provide gRPC endpoints as well.

[ankit-joinwal]

so if i understand correctly, gRPC is utilised for inter-service communication between DGS services and GraphQL for communication between Federation Gateway and DGS services? is that correct?

[paulbakker]

We don't use gRPC for gateway -> DGS communication. We considered this for a while, expecting performance benefits, but in reality, there doesn't seem much of a win. The actual transport is hardly a factor in the flow.

Before adopting GraphQL we were mostly standardized on gRPC for service->service communication. Because we have a large ecosystem of gRPC services, we see the following patterns:

• An existing gRPC service adds GraphQL (over HTTP) as a second endpoint, to become part of a federated graph. This works great if the service is still under active development so that most code can be shared between the gRPC and GraphQL endpoints.
• A new DGS is put in front of existing gRPC service(s). The DGS is basically just using a gRPC service as just another backend/datastore.
• More services are using GraphQL for service->service communication. GraphQL is particularly nice when serving a large data model to a variety of clients.

These patterns all have their own use cases, and it's really about tradeoffs for each individual scenario. Performance doesn't seem to be a huge factor though.