Recently released by Facebook, GraphQL isn't only useful for client-server communication. Viktor will show how Red Badger used the reference implementation - graphql-js - at the Financial Times as a generic data presentation layer over a set of backend APIs and how to deal with related requirements like caching or authorisation.

1. GraphQL
at the Financial Times

2. GraphQL

3. REST
GET id data

4. REST
GET id data
GET id2 moreData
GET data.id yetMoreData

5. REST
GET id data
GET id2 moreData
GET data.id yetMoreData
ᐧᐧᐧ

6. REST
GET id data
GET id2 moreData
GET data.id yetMoreData
ᐧᐧᐧ

7. GraphQL
• Query based: a single request fulfils exactly the
client’s data needs
• Query language specification
• Programming language agnostic

8. {
article(id: 3500401) {
id
title
mainImage(width: 50) {
src
alt
}
}
}
{
“article”: {
“id”: 3500401,
“title”: “Hello World”,
“mainImage”: {
“src”: “http://…”,
“alt”: “Hello”
}
}
}
Example

9. Viktor Charypar
@charypar
github.com/charypar

10. The problem with REST

11. service service service service service service
client client client

12. service service service service service service
client client client

13. service service service service service service
client client client

14. “I just have a website…”

15. service service service service service service
/path /other/path /a/different/path

16. It’s the backend complexity…

17. service service service service service service
/path /other/path /a/different/path
GraphQL

18. How GraphQL works
• user-defined type system - “schema”
• server describes what data is available
• clients describe what data they require
• user-defined data fetching (“how do I get an article”)
• backend agnostic

19. graphql-js
• reference implementation built by Facebook
• github.com/graphql/graphql-js
• currently 0.2.x
• schema definition, query parsing and execution
• no network transport

20. Financial Times

21. Next FT
• project to replace and improve the current ft.com
• displaying content from a set of REST APIs
• github.com/Financial-Times/next-front-page

22. Demo

23. Next FT backend
• CAPIv1 & CAPIv2
• different content available (e.g. fastFT not in v2 yet)
• slightly different response format
• CAPIv1 through Elasticsearch as a feature toggle

24. Front page data sources
• top stories & opinions: editorial driven CMS pages
• editor’s picks: mix of searches and pages, moving
towards lists
• fastFT: CAPI content by concept + notification feed
• popular stories and live blogs not from CAPI
• related content = extra round of requests

26. API backends are complex

27. backend APIs are storage-centric
front-end APIs are product-centric

28. service service service service service service
/path /other/path /a/different/path
GraphQL

29. Demo

30. Practical problems
• caching, Elasticsearch, mock data
• swappable backends
• first attempt: pass backend as a type parameter
• horrible hard to maintain monstrosity. Don’t.
• second attempt: execution context rootObject
• more flexible, keeps the schema clean

31. Results
• significantly simpler and cleaner
• very easy implementation (~3 days)
• starts a little tedious, rapidly speeds up
• still very early days for graphql-js

32. Viktor Charypar
@charypar
github.com/charypar