GraphQL for a Payments API

7e92d8fa80b54b06ad9c97b768c7029f?s=47 Sadique Ali
November 09, 2018

GraphQL for a Payments API

7e92d8fa80b54b06ad9c97b768c7029f?s=128

Sadique Ali

November 09, 2018
Tweet

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