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.
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
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
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
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