React and GraphQL at Stripe
3 likes4,474 views
There are a lot of tools and processes involved in modern front-end development: Component development, design, data fetching, testing, and more. At Stripe, our team have put a lot of effort into making these things work together in a way that's more than the sum of their parts.
Ad
More Related Content
Similar to React and GraphQL at Stripe (20)
More from Sashko Stubailo (6)
Ad
Recently uploaded (20)
Ad
React and GraphQL at Stripe
- 1. React and GraphQL at Stripe Sashko Stubailo Engineering Manager, Dashboard Discovery @stubailo
- 2. O V E R V I E W 1. How GraphQL fits into the modern product development stack 2. Novel tools that we built at Stripe 3. Unexpected benefits we're excited about
- 3. M Y B A C K G R O U N D 1. Since 2015: Worked on open source GraphQL tooling at Apollo: Apollo Client, Server, etc 2. Since late 2018: Engineer on Stripe dashboard platform team, helped build out GraphQL implementation Important note: Everything I'm about to present was a team effort! It takes a village to build these things.
- 4. Developing in the Stripe Dashboard • Lots of product teams contributing at once • Needs to work together as a unified whole
- 5. S T R I P E ' S W E B S TA C K • React • Flow • Jest • Webpack • Ruby • GraphQL and Apollo (new)
- 6. GraphQL: Define a schema instead of a list of endpoints /authors /authors/1 /posts /posts/1
- 7. From separate API requests to one GraphQL query Fetch as few or as many fields as you want in one query, and traverse between types Queries are sent over POST requests to a single /graphql endpoint
- 8. Simple front-end data fetching
- 9. How do we make product development better?
- 10. P R O D U C T D E V E L O P M E N T Frontend API Backend
- 11. P R O D U C T D E V E L O P M E N T Components API Backend State management Tests Backend Component explorer Editor CI Monitoring Type generation
- 12. P R O D U C T D E V E L O P M E N T Components API Backend State management Tests Backend Component explorer Editor CI Monitoring Type generation The most valuable systems are those that can tie in to all of these aspects of development. Example: UI component systems
- 13. P R O D U C T D E V E L O P M E N T Components GraphQL API Backend Apollo Tests Backend Component explorer Editor CI Monitoring Type generation
- 14. P R O D U C T D E V E L O P M E N T Components GraphQL API Backend Apollo Tests Backend Component explorer Editor CI Monitoring Type generation GQL GQL GQL GQL GQL GQL GQL
- 15. Why does GraphQL have such a big impact? The schema defines capabilities Queries define data requirements
- 16. Why does GraphQL have such a big impact? Area GraphQL's benefit Frontend state Sophisticated data loading and management libraries API Incremental schema changes without versioning Monitoring Track individual field usage Tests Easy mocking Frontend types Static types per-query GraphQL contributes to every part of the workflow:
- 17. Tools we've built at Stripe: Data mocking
- 18. Why mocking? Write unit tests and examples without having to call a real API • Faster, more resilient tests • Possible to develop components before backend is built • Easy to generate edge case states Frontend Fake API
- 19. GraphQL makes mocking easy We can generate mocks automatically from a schema and query. Code snippet with graphql-tools:
- 20. Problem: What about edge cases? A globally mocked schema isn't well suited to test... Error states Long lists Loading indicators Counting number of requests
- 21. Per-request mocking Allows you to specify edge cases for this test, but now you lose the benefits of schema- based mocking. (Example from the Apollo docs)
- 22. Schema mocking with overrides Best of both worlds: Automatic mocks for general testing, and the ability to override specifics for a single test.
- 23. E X A M P L E S : S E T T I N G U P G L O B A L M O C K S This will allow most components to be rendered without any custom mocks at all.
- 24. E X A M P L E : D E F A U LT M O C K S In this example, we're just trying to check if the component renders correctly. The specific data isn't important, so we don't need to specify anything.
- 25. E X A M P L E : O V E R R I D I N G F I E L D S In this example, we want to assert for the presence of specific values in the rendered component. We wouldn't want to rely on global mocks having those specific values, so we specify them in the test.
- 26. M O C K F O R L O A D I N G / E R R O R S TAT E S We've also added helpers for a very common type of edge case: Errors and loading state.
- 27. S P Y I N G O N M U TAT I O N S Submitting a form and checking that it succeeded
- 28. O N E M O R E T H I N G : G R A P H Q L M O C K S I N O U R C O M P O N E N T S Y S T E M We have an internal prototyping environment called SailPen, which Jay Divock presented at DublinJS a few months ago. It also now supports GraphQL mocking!
- 29. Tools we've built at Stripe: Schema validation
- 30. Collaborating on an API You shouldn't have to be aware of the larger context when making a small, focused API change We need guard rails to be able to easily evolve the schema without introducing breakages
- 31. Schema guard rails To reduce the probability of breakages related from schema changes, we: 1. Generate a schema.graphql file and check it in to the monorepo 2. Generate Flow types for every query with apollo-codegen 3. Run a backwards compatibility checker in CI
- 32. S C H E M A . G R A P H Q L F I L E This file encodes the current state of the schema, and is automatically generated and checked in from the API code.
- 33. Generating Flow types apollo-codegen to generate Flow types for each query, mutation, and fragment.
- 34. Q U E R Y W R A P P E R B R I N G S T H E T Y P E S T O G E T H E R
- 35. Q U E R Y W R A P P E R
- 36. Backwards compatibility checker It's not enough to make sure that the current frontend is compatible with the current backend in the monorepo, since there might be people who haven't refreshed their frontend in a while.
- 37. How do we make breaking changes? Sometimes, you just don't want a field anymore, and you've verified that nobody is using it anymore. You can use a two step process to make a change in this case: 1. Mark as deprecated, merge 2. Delete, merge Note: Not yet ideal for things like modifications to an existing field.
- 38. Tools we've built at Stripe: Monitoring
- 39. What makes GraphQL different? The URL is no longer meaningful, since all GraphQL requests go to a single /graphql path Important information like the query name and fields are hidden in the POST request body, and need to be extracted
- 40. GraphQL-specific metadata We extract the operation name for logging and charts.
- 41. Query ownership We assign team owners to queries so that errors get routed to the team whose feature is broken.
- 42. Query ownership We assign team owners to queries so that errors get routed to the team whose feature is broken.
- 43. Benefits we've seen since adopting GraphQL
- 44. Commonly quoted benefits As seen on graphql.org and apollographql.com: • Reduced overfetching • Self-documenting, strongly typed schema • Great developer tools But there are more benefits that weren't mentioned there that really stood out to me at Stripe. Image from graphql.org
- 45. B E N E F I T S T O H I G H L I G H T : 1. Great community tools and docs 2. Easy to add and remove fields from the schema 3. Localized code changes and static types
- 46. Great community tools and docs • Apollo Client for data fetching • Apollo Codegen for Flow type generation • graphql-tools for mocking We're proud of the internal tooling we've built, but every new tool we built in-house is something to maintain GraphQL's well-specified nature allows these tools to be broadly useful to many organizations
- 47. Great community tools and docs We can leverage existing docs, and growing popularity of GraphQL, to onboard new developers faster than with custom internal tools
- 48. Easy to add and remove fields • We can implement things just the way we want them • Easy to iterate on the schema later if we didn't get it right the first time • Low cost to having unused fields
- 49. Eliminating the field/endpoint tradeoff: In REST, 3 places to add new data, each with tradeoffs: 1. A new endpoint 2. A new field on an existing endpoint 3. Front-end data transformation GraphQL eliminates this tradeoff - you can always just add a field! Easy to add and remove fields
- 50. Localized code changes and static types • Easier to review code • Fewer unintentional side effects • Faster to modify one component
- 51. C O N C L U S I O N 1. GraphQL can make data-related tooling work together across the stack 2. We're excited about some new tools we've built internally 3. GraphQL had additional unforeseen benefits for product development velocity Any questions about the talk or GraphQL in general? Also, we're hiring at Stripe, please reach out! Sashko Stubailo, @stubailo on Twitter