GraphQL for a Payments API

Transcript

1. GraphQL for a Payments API Challenges and Lessons Sadique Ali Koothumadan @sdqali
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", } }] }
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