the presentation is about federated GraphQL in huge enterprises. I explain why and what for big enterprises need distributed GraphQL and classic one does not work.

1. GraphQL for distributed applications
Sber
2021

2. Who we are
Alex Tokarev
Head of RnD Platform V Sberbank – platformv.sber.ru
AWS and GCP expert
The man who cares about architecture
Pavel Zhurov
Senior Cloud Engineer at VTB
Kubernetes security nerd
For God’s sake, be careful with hostPath in production

3. Agenda
• Gateways evolution
• GraphQL
• Federated GraphQL
• DSG library
• Q&A session

4. API stages
API 1
API 1
API 1
API 1

5. API stages
API 1
API 2
API 3
API 5
API 100500

6. API stages
G
a
t
e
w
a
y
API 1
API 2
API 4
API 1
API 1
API 1
API 1

7. API stages
B
F
F
B
F
F
BFF
API 1
API 2
API 3
API 1
API 1
API 1
API 1
API 1
API 2
API 100500

8. GraphQL
• Query language over HTTP
• Strongly typed schema
• Introspectable = self-documented
• One endpoint
• Declarative data fetching
• Fewer server requests
• Frontend-driven data selection

9. GraphQL

10. GraphQL

11. GraphQL principles
• More data and services can be
accessed from a single query
• One central catalog of all available
data that all graph users can look to
• Implementation cost is minimized,
because graph implementation work
isn't duplicated
• Central management of the graph

12. GraphQL gateway
• ds
GraphQL
Schema
+
server
API
API 1
API 2
API 100500

13. GraphQL principles
• More data and services can be
accessed from a single query
• One central catalog of all available
data that all graph users can look to
• Implementation cost is minimized,
because graph implementation work
isn't duplicated
• Central management of the graph

14. GraphQL principles
• More data and services can be
accessed from a single query
• One central catalog of all available
data that all graph users can look to
• Implementation cost is minimized,
because graph implementation work
isn't duplicated
• Central management of the graph
Works for smaaaaaall teams!

15. Conway’s Law
“Organizations which design systems (in the broad sense used here)
are constrained to produce designs which are copies of the
communication structures of these organizations”

16. Top-secret transformation
• Unify but decouple
• Curate but fast move
• Distribute ownership and implementation

17. Transformation
• divide graph across multiple teams
• each team has independent GraphQL service
• track the definition of graph in a schema registry
• schema registry should store the history of
changes to the graph and who made them
• implement federated query planner and executor

18. Architecture
GraphQL
gateway
API
GraphQL
schema
+
server
GraphQL
schema
+
server
GraphQL
schema
+
server
GraphQL
schema
+
server
Registry

19. Federated schema

20. Federated schema

21. Plan resolution

22. DSG
• Что-то от Юры

23. DSG
• Что-то от Юры

24. DSG
• Что-то от Юры

25. DSG
• Что-то от Юры

26. DSG
• Что-то от Юры

27. DSG
• Что-то от Юры

28. DSG
• Что-то от Юры

29. Federated cons
• Up to 10 ms overhead
• PII identification is complicated
• Dedicated CI/CD and governance for schemas
• No opensource schema registry

30. Federated GraphQL pros
• Unified problem domain graph tailored for UI
• No bottleneck in terms of development
• Backend developers don’t waste time createing BFF

31. Next steps
• Cost based optimizer
• Calcite-based API calls
• API calls statistic
• Extra-calls remover
• AuthN and AuthZ
• PII information governance
• Observability and advanced troubleshooting
• GraphQL as a service

32. Success enterprise GraphQL path
• SchemaFirst approach
• Federation is a must
• Collaborative schema design
• Deprecation and backward compatibility from day 0
• Proper tooling
• Learning materials

33. Q&A