GraphQL for a Payments API

Transcript

1. GraphQL for a Payments API Challenges and Lessons Sadique Ali

   Koothumadan @sdqali
2. None

3. GraphQL at Braintree is part of our ongoing platform’s digital

   transformation, which allows us to deliver an always improving developer and online consumer experience.

4. https://graphql.braintreepayments.com

5. SDK ❤

6. Card API REST + JSON REST + XML GRPC Tokenize

   Tokenize Tokenize ACH ACH ACH Card Card ☁ ☁ ☁ ☁ ☁ ☁ JS SDK Python SDK Ruby SDK Java SDK Go SDK

7. No Absolutisms

8. Why GraphQL?

9. • Consumers of our API are tech-savvy • Direct Integrations

   • Added benefits for SDKs

10. • “Choose your payload” • Mobile friendly • Faster integration

    • Interactive tooling • Evolvability

11. Technology Choices

12. “GraphQL exists because JavaScript people love JSON too much”

13. ReportEdgeResolverFactory ?

14. ReportEdgeResolverFactory

15. • graphql-java • java-dataloader • graphql-java-tools

16. Schema files

17. • cards • tokenize • report • merchant Along domain

    boundary?

18. util and common are where things go to die.

19. • inputs • types • queries • mutations • ...

    Along GraphQL concepts?

20. To Relay or Not?

21. • Consistent input structure • Connections and pagination • IDs

    and Refetching Relay goodies

22. Global IDs

23. • /transactions/wv3e1js/close • /merchants/tw763ex IDs in the REST world

24. • Format • Backwards compatibility Global IDs

25. • Opaque url-safe Base64 encoded strings • Attach global_ids to

    legacy responses Global IDs

26. • Certain entities won’t have Global IDs Global IDs

27. Query Complexity

28. • Assign complexity factor to entities • Instrumentation to enforce

    limit Max Complexity

29. API Visibility

30. • Server side consumers • Client side consumers • Admin

    panel • ... Control what consumer can see what

31. • Detect consumer • Reject if invisible Visibility Instrumentation

32. Authorization

33. @NeedToBe(ADMIN) /admin-endpoint adminEndpoint() { // ... } REST

34. type Query { panelData: PanelData } type PanelData { transactions:

    [Transaction], # Merchant portal failures: [Transaction] # Admin panel } GraphQL

35. Design for Partial Success

36. Card GraphQL API REST + JSON REST + XML GRPC

    Tokenize Tokenize Tokenize ACH ACH ACH Card Card ☁ ☁ ☁ ☁ ☁ ☁

37. Card GraphQL API REST + JSON REST + XML GRPC

    Tokenize Tokenize Tokenize ACH ACH ACH Card Card ☁ ☁ ☁ ☁ ☁ ☁

38. Card GraphQL API REST + JSON REST + XML GRPC

    Tokenize Tokenize Tokenize ACH ACH ACH Card Card ☁ ☁ ☁ ☁ ☁ ☁

39. Card GraphQL API REST + JSON REST + XML GRPC

    Tokenize Tokenize Tokenize ACH ACH ACH Card Card ☁ ☁ ☁ ☁ ☁ ☁

40. • Be comfortable serving nulls • Collect all the errors

    Partial successes

41. Error handling

42. { error : { “user_message”: “...”, “developer_message”: “...”, “details”: [{

    “code”: “...”, “in”: “header”, “at”: “authorization” }] } } REST

43. • Represent multiple errors • Support legacy error codes

44. { errors : [{ message: "No report exists because there

    are no transactions on that date.", locations: [{ line: 3, column: 5, }], path: [ "report", "transactions", ], extensions: { errorType: "user_error", errorClass: "NOT_FOUND", } }] }
45. None

46. Team workflow

47. • Multiple products contributing to the schema • Custodians of

    the schema need to play a balancing act

48. • Collaboration • Always propose schema changes first

49. Focus on the Schema

50. Thank You :D