Breaking up the Monolith: Layered GraphQL Architectures

Transcript

1. Layered GraphQL Architectures Breaking up the Monolith

2. Johannes Schickling Based in San Francisco Co-founder & CEO @prisma

   @schickling @schickling

3. GraphQL is more than a REST wrapper GraphQL is great

   for… • Client-server communication • Service-to-service communication • Domain-driven design • Data modeling • Code generation • …

4. Architectures are about tradeoffs • The one best architecture doesn’t

   exist • Architecture means always moving around tradeoffs • Scale • Performance • Development velocity • Cost • …

5. Talk Overview Traditional Monolith Layers & Services: Breaking up the

   Monolith Service-to-service communication Architecture Case Studies 1 2 3 4

6. What won’t be covered FOCUS OF THIS TALK TALK DOESN’T

   COVER • “Write path” (data processing/pipelines) • Infrastructure / Network • Deployment / CI/CD • “Read path” & state abstractions

7. Traditional Monolith

8. Traditional Monolith • Popular frameworks: Ruby on Rails, Laravel, Django,

   Meteor • DHH calls it the “Majestic Monolith”

9. GraphQL Monolith Architecture • 3 tier architecture • Trend: Frontend

   and backend separated • Backend deployed as one package Frontend Backend Database

10. Benefits of a Monolith Easy to get started, develop &

    debug No problems of distributed computing Simple infrastructure setup & easy deployment Global type-safety (when using typed language)

11. Problems of a Monolith Developing a monolith becomes harder and

    harder over time Big/Growing monoliths can lead to the following problems: • Development velocity (hard to change, merge conflicts, …) • Operational complexity (scaling, bottleneck, …) • Code complexity (separation of concerns, …)

12. Breaking up the Monolith Layers & Services Breaking up the

    Monolith

13. Layers & Services • Goal: Break up complexity into smaller

    parts • 2 possible dimensions: • Vertically: (Abstraction) Layers • Horizontally: Services • Layers/services either logical or infrastructure • Some layers can be auto-generated

14. Complexity Analysis Typical areas of code complexity • Blurry boundaries

    & coupling between logical domains • No separation of concerns • State handling } Introduce abstraction layers } Split up into services

15. Data Abstraction Layers Presentation Layer API Layer Domain Model Data

    Access Layer Database Layer

16. Data Abstraction Layers Presentation Layer API Layer Domain Model Data

    Access Layer Database Layer

17. Data Abstraction Layers Domain Model Data Access Layer API Layer

    Presentation Layer Database Layer

18. Data Abstraction Layers Domain Model API Layer Data Access Layer

    Presentation Layer Database Layer

19. Challenges 1. Service-to-service communication 2. Preserve type-safety across services/layers 3.

    Requires changes to infrastructure setup & deployment workflow

20. Service-to-service communication

21. Service-to-service communication • How to communicate between services / layers

    • Request-response (sync) or message passing (async) • Considerations: • Cross language/platform compatibility • Efficiency (low network & serialization overhead) • Great workflow • Code generation

22. How it works • Each service exposes a schema based

    on which service clients will be generated • Components: • Wire protocol (HTTP, gRPC) • Serialization format, IDL & type system (Protobuf, Thrift, Msgpack, …) • Framework & tooling (e.g. codegen) • Options: • RPC frameworks: gRPC, Thrift, … • Manual: REST / JSON over HTTP Service A Service B Generated Client for Service A Server for Service A (exposes schema) Serialized Data

23. Code Generation Workflow 1. Define schema in IDL 2. Choose

    programming language(s) 3. CLI scaffolds server code and generates client libraries Example: Generates gRPC client in Go based on Protobuf schema protoc -I helloworld/ helloworld/helloworld.proto --go_out=plugins=grpc:helloworld

24. GraphQL • Service-to-service communication using GraphQL • A Binding is

    (generated) schema-specific GraphQL client • Bonus: Supports schema delegation (~schema stitching) const serviceA = new ServiceA('http://service-a.example.com') const users = await serviceA.users({ activated: true }) const commentsWithAuthor = await serviceA.request(`{ comments { text author { name } } }`)

25. Comparison: GraphQL vs gRPC gRPC: Low-level & performant • Server:

    Single handler function Very efficient / performant Supports streaming Static API (no queries) Requires explicit field ordering GraphQL: Flexible & powerful • Server: resolvers functions Flexible queries Supports schema delegation Bigger ecosystem Still early outside of JS/Node

26. End-to-end type-safety • Global type-safety for decoupled & distributed systems

    • GraphQL acts as glue between all layers & services • Especially powerful in CI/CD setups

27. Architecture Case Studies

28. 3 different architectures Stateless Monolith Microservice Architecture Layered Service Architecture

29. Stateless Monolith • Similar to monolith but all state is

    moved into data services • Stateful: in-mem state across reqs Pros: Can be run serverless Cons: Still code complexity issues

30. Microservice Architecture • Thin GraphQL gateway layer • Often auto-generated

    based on schema merging • Microservices contain business logic + each MS has its own database Pros: Rigid boundaries & scalable Cons: Infrastructure overhead

31. Layered Service Architecture • Based on Microservice Architecture • GraphQL

    gateway layer is optional • Presentation services give frontend engineers more flexibility/control • Pros/Cons: Same as MS architecture

32. Key Takeaways GraphQL is a great foundation for any architecture

    GraphQL shines at service-to- service communication A “Stateless Monolith” is a great starting point for new backends 1 2 3

33. • DB-agnostic Data Access Layer (think ORM) • Prisma turns

    your DB into a GraphQL API • Your API server delegates queries to Prisma Prisma

34. We’re hiring prisma.io/jobs San Francisco Berlin

35. Thank you @schickling @schickling