A brief overview of Relay for the Vancouver JavaScript meetup

1. RELAY
SEAMLESS SYNCING FOR REACT

2. A LITTLE ABOUT BROOKE
SHAMELESS SELF PROMOTION
• Full stack developer at MetaLab and Robot Overlord
• Come see me for stickers and buttons after the talk 😉
• Organizes a few meetups
• Leaving the country in February, so giving a few talks before then
• Have been using Relay “professionally” since October 2015
• ~6 weeks after the initial technical preview was open-sourced
• Maintain awesome-relay, but honestly there’s not a ton written about Relay yet (repo will grow when there is more)

3. ONCE UPON A TIME…
VALUE PROPOSITION
• GraphQL + Relay version
• Took roughly a day
• Built a GraphQL type and tested it
• “Can we have a RESTful version for the old API?”
• Marty + REST version
• Took the most of the remainder of the week
• Had to build a custom route, controller, presenter, and serializer…
• …and then write tests for everything above

4. REACT + GRAPHQL + HELPERS = RELAY
WHAT WE’RE GOING TO COVER
• Why another front-end framework?
• A brief React refresher
• GraphQL
• Relay
• Closing thoughts
• Q&A

5. ANOTHER
FRAMEWORK?

6. THINGS WORK, SO WHY BOTHER
LEARNING ANOTHER FRAMEWORK?
ANOTHER
FRAMEWORK?

7. DEVELOPER HAPPINESS IS IMPORTANT
BECAUSE FUN!
• It can’t be overstated as an important factor in long-term project success
• It’s fun to learn new things, be on the leading edge, &c
• It’s fun to contribute back to young project, or even open an Issue on the repo
• Removing boilerplate helps us get more done faster, which makes us feel good!

8. INDIVIDUAL AND INDUSTRY PROGRESS ARE IMPORTANT
BECAUSE PROGRESS!
• Otherwise our jobs would still involve writing FORTRAN on punch cards
• Open progress as a collective profession gets more eyes than internal solutions

9. EXPERIMENTING WITH NEW WAYS OF DOING THINGS IS IMPORTANT
BECAUSE NEW IDEAS!
• It might not end up being The One True Way, but it still a progression towards The
Next Big Thing

10. DIFFERENT FRAMEWORKS HAVE DIFFERENT STRENGTHS & GOALS
BECAUSE DIFFERENT USE CASES!

11. RELAY ISN’T GOING TO DISAPPEAR
BECAUSE FACEBOOK!
• Relay is Facebook backed
• Not disappearing any time soon
• Tied to the future of other tech, like React Native

12. THE PROBLEM

13. EFFICIENTLY SYNCING DATA IS HARD
THE PROBLEM
• Generally, we need a way to read from and write to a server
• Projects start simple: a single RESTful endpoint can describe what’s on the page
• But eventually…
• Pages start to require data from multiple resources
• Different pages need different attributes from the same resource

14. EXISTING SOLUTIONS

15. WRITE A CUSTOM ENDPOINT FOR EACH USE CASE
EXISTING SOLUTIONS
• Write a custom API endpoint for each use case
• No over- or under-fetching (if you’re willing to put in the time)
• Doesn’t scale: time consuming; brittle; confusing

16. THE CANONICALLY RESTFUL WAY
EXISTING SOLUTIONS
• Write general RESTful endpoints for each resource
• Can use multiple queries to load data for several resources
• Often get less data than you need (under-fetching)
• Therefore can need multiple requests
• Often get more data than you need (over-fetching)
• Requests are larger than they need to be (inefficient)

17. PRE-FETCH EVERYTHING THAT THE USER MIGHT WANT
`
• Prefetch all of the data that the user might want on initial page load
• Inefficient (serious over-fetching) & poor performance
EXISTING SOLUTIONS

18. WHAT IF THE CLIENT CONTROLLED THE RESPONSE SHAPE?
THERE MUST BE A BETTER WAY
• Wouldn’t it be nice if we could…
• ask the server for specific information, ad hoc
• compose queries
• nest queries to mirror the UI’s nesting
• Facebook has a pretty popular website, and make frequent changes
• Updating a RESTful API would not keep up
• Explored a few solutions; settled on their GraphQL
• Netflix and Cognitect have come up with similar solutions
• Falcor
• The Om Next data resolver + Datomic

19. REACT
A QUICK REFRESHER
BEFORE WE GO ON

20. REACT
PHILOSOPHY
VIRTUAL DOM
JSX
COMPONENTS

21. I’M GOING TO MOVE SOMEWHAT QUICKLY, OTHERWISE
STOP ME IF SOMETHING IS UNCLEAR

22. MORE THAN “THE V IN MVC”
PHILOSOPHY
• A functional approach
• Limit & control state
• Prefer keeping your data unchanged (immutable)
• Isolate any changing (mutable) data
• Components are functions that take props and return a chunk of Virtual DOM
• Declarative (“what”) > imperative (“how”)
• Data flow
• Of course, DRY

23. JS OBJECT UPDATES ARE MUCH FASTER THAN A BROWSER’S RENDERER
VIRTUAL DOM
• Instead of manipulating the DOM directly, we update a JSON representation it
• Can then diff the DOM, and make focused changes
• This makes re-rendering extremely fast
• We only get real DOM changes
when we need then
• Get multiple changes at once
(no flickering in and out)
• HTML & JSX are trees, so parents
“own” their children

24. WHO PUT HTML IN MY JS?
JSX
• Handy HTML-like syntax that compiles down to pure JS
• Can mix and match with HTML elements (more or less)
• Pass arguments as “props”
• Nested elements are “props.children”

25. WHO PUT HTML IN MY JS?
JSX

26. ROLL YOUR OWN HTML TAGS
• Can write custom components for your display logic
• Just assign a name to the JSX (or plain JS) from previous slide
• Take props, and render plain HTML
COMPONENTS

27. ROLL YOUR OWN HTML TAGS
COMPONENTS

28. GRAPHQL
IDEOLOGY
DECLARATIVE SYNTAX
TYPES
QUERIES
MUTATIONS
INTROSPECTION

29. SINCE ALL SCHEMAS ARE TECHNICALLY GRAPHS…
IDEOLOGY
• “REST gives you data per resource, so let’s try something else”
• Being RESTless(?) is developer heresy
• One endpoint to rule them all; usually /grahql
• Request only what you need
• Let the server figure out how
• Want JSON to express relationships between objects, but get duplication
• So, dedup nodes that have multiple connections
• Graphs are strictly more expressive than relational schemas
• Can rewrite any relational structure as a graph

30. “I WANT SOME DATA THAT LOOKS LIKE THIS“
DECLARATIVE SYNTAX

31. GETTING CONTRACTS INTO YOUR APPLICATION
TYPES
• User definable “shapes” or “structs”
• Fields be required or optional
• Enforce data consistency
• Catch bugs early
• Keep the database clean
• Doubles as documentation

32. THE “GET REQUEST” OF GRAPHQL
QUERIES

33. PASSING ARGUMENTS
QUERIES
Set up like a function
(arguments -> graph fragment)

34. THE “PUT/POST/DELETE/SIDE-EFFECT” OF GRAPHQL
MUTATIONS
• “Mutations” are how you change (“mutate”) the world outside of the FE app
• Update a field in the database
• Send an email
• Fire the missiles
• Set up like a function (arguments -> graph fragment)

35. THE “PUT/POST/DELETE/SIDE-EFFECT” OF GRAPHQL
MUTATIONS

36. ORDER A SIDE OF DOCS WITH YOUR API
INTROSPECTION
• Can construct a regular query to get metadata
• First-class!
• The schema itself
• the whole thing, or just a portion
• Descriptions of fields
• Descriptions and fields on types
• Descriptions and fields on mutations
• Which fields are required
• What the fragments it can return are
• &c.

37. GRAPHQL LIVE DEMO

38. RELAY
ARCHITECTURE
CONTAINERS
LOCAL VS REMOTE DATA
PROS & CONS
TOOLS

39. IT’S PRETTY NEW™
RELAY
• React was publicly released at the end of May, 2013
• Relay’s technical preview made available in mid-August, 2015
• Facebook has been using parts of it internally for a while (~2 years?)
• They have also been using GraphQL with iOS applications for a while, too

40. FLUX-ISH
ARCHITECTURE

41. MAGICAL BOXES TO HANDLE YOUR COMPONENT’S DATA NEEDS
CONTAINERS
• Wraps a “plain” component (HOC)
• Fetches data from the server
• Translates GraphQL to JSON
• Composable (KILLER FEATURE)

42. OSTENTATION FTW!
CONTAINERS

44. TALKING TO THE OUTSIDE WORLD
MUTATIONS

45. SEPARATION OF REMOTE AND LOCAL DATA
TRULY LOCAL DATA
• Relay really wants its client and server stores to be consistent
• If some data is not going to be synced to the server, it doesn’t belonging the graph
• Store such data in the React component state
• ex. partially filled form fields, locked buttons, which tab is visible, &c
• One store for Relay’s synced (“remote”) data, and several for purely local data

46. IT’S LIKE THEY WERE NEVER HERE
EPHEMERAL DATA
• Relay doesn’t really directly handle temporary data
• For example, let’s say the we want a temporary token that will not be persisted
• We have three options:
• Plain REST
• Plain GraphQL
• Fake it with a null node

47. FAKE IT ‘TILL THEY MAKE IT
THE NULL NODE KLUDGE
• Create an attribute on the User type node that returns null by default (initial query)
• Mutation to create the token
• Input: {userID: “PF8bxC7R51”}
• Output: {user { id: “PF8bxC7R51”, token: “i3g7BrhwHb” }}
• ie: works as normal
• This data probably doesn’t “belong” on the user, but it’s a convenient location
• If you refresh the page, you’ll need to go through the mutation again

48. PRETTY GREAT, BUT IT’S NOT ALL KITTENS AND RAINBOWS
PROS AND CONS
� Speeds up development
� Keeps things flexible
� Fun to use
� Very active repo
� Smart people working on it
� Feels like the future
� It’s (very) early days
� Documentation “could be better”
� Some unintuitive naming
� Few complete examples
� Bugs are sometimes the framework
� Doesn't handle local data

49. Q&A