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.

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