This document summarizes a meetup presentation about how the company CALLR began using GraphQL to enhance communication between their front-end and back-end developers. The presentation discusses how CALLR previously used JSON-RPC for their API instead of REST. It then explains how an informal discussion about GraphQL led to a workshop where they explored how GraphQL could help minimize communication issues by making API changes less disruptive and delivering data to front-end developers more declaratively. The presentation outlines benefits like improved teambuilding, expertise, and brand awareness that motivated CALLR to implement GraphQL.
Developing and Deploying Apps with the Postgres FDW
How fiddling with GraphQL enhanced communications between our back and front developers - Meetup #ParisAPI
1. Meetup #ParisAPI
06/28/2017
How fiddling with GraphQL enhanced communication
between our back and front developers
by Davy Peter Braun
Senior Frontend Engineer @ CALLR
2. Meetup #ParisAPI - By @davypeterbraun 2
CALLR - Global Voice and SMS services company
- Use-cases cover user acquisition/engagement, person-to-person
communications, much more...
- SMS and voice notifications (integrate to your app using API)
- Call tracking (get extra data from your tracked phone numbers)
- Custom IVR (Interactive Voice Response)
3. Meetup #ParisAPI - By @davypeterbraun 3
Development at CALLR (in a nutshell)
- Telecoms’ stack — “exotic” from a classic web developer’s POV
- 3 frontend (Angular), 3 backend (PHP) + 3 devops
- Communication barriers do happen...
4. Meetup #ParisAPI - By @davypeterbraun 4
We use JSON-RPC, not REST
- JSON-RPC
Stateless, very simple, lightweight, remote procedure call built
using the JSON format.
- Send a Request Object with structured fields
Single endpoint where you POST your request
jsonrpc, method, params (optional), id (optional)
- Receive a Response Object
jsonrpc, result (optional), error (optional), id
6. Meetup #ParisAPI - By @davypeterbraun 6
We use JSON-RPC, not REST
- Batch requests
Send an array of request objects, and server returns an array of
corresponding responses
9. Meetup #ParisAPI - By @davypeterbraun 9
How we try to minimize communications issues
- Well-rounded project managers
- Make sure project priorities are clearly outlined
- Shifted to a “user stories” based process encompassing both front
and back at the same time
10. Meetup #ParisAPI - By @davypeterbraun 10
Informal chit-chat leads to ad-hoc workshop
- Subject brought up by frontend devs, because React
- GraphQL == hype — the name rings everyone’s bell
- Heated conversation — “hype” or “progress”?
11. Meetup #ParisAPI - By @davypeterbraun 11
GraphQL
- Query language and a server-side runtime, for your API, on top of
your existing data / backend storage system(s)
- GraphQL service
- Define types
- Define fields on those types
- Provide functions to resolve each fields you may query
- Using w/o Relay (i.e. w/ Angular)?
-> POST GraphQL commands into back-ticked query strings
- Single HTTP endpoint fed with POST!
12. Meetup #ParisAPI - By @davypeterbraun 12
GraphQL
Type definitions
type Query {
user: User
}
type User {
id: ID
skills: [Skill]
name: String
company: String
}
type Skill {
name: String
techRelated: Boolean
proYears: Int
getsPaidForIt: Boolean
}
GraphQL query
{
user {
name
company
skills {
name
techRelated
}
}
}
GraphQL server-side response
{
"user": {
"name": "Davy Braun",
"Company": "CALLR",
"skills": [
{
"name": "Coding",
"techRelated": true
},
{
"name": "Branding",
"techRelated": false
},
{
"name": "Trading",
"techRelated": false
]
}
}
13. Meetup #ParisAPI - By @davypeterbraun 13
GraphQL
- Backend implementation relies on resolvers functions
- Query several data sources (e.g. different DBs)
at once transparently from the frontend
14. “Yeah that’s a bit like what we already have,
OK, bye”
TL;DR — ”what we have is better”
Or is it?
15. Meetup #ParisAPI - By @davypeterbraun 15
What could GraphQL help us with?
Make API
changes a
softer XP
Sweeter delivery
of data
Teambuilding Brand awareness
16. Meetup #ParisAPI - By @davypeterbraun 16
1/ Making API changes a softer experience
- If method is not new and changes, bump API version
- If method is new, add it (bump API version maybe?)
- Changes w/o API version bump -> breaking changes :(
- Many API versions -> technical debt grows :(
- Update docs, update SDKs (...ahem) :(
- Impedes continuous delivery :(
17. Meetup #ParisAPI - By @davypeterbraun 17
PEOPLE DON’T WANT
TO CHANGE CODE WHEN
OUR API CHANGE
18. Meetup #ParisAPI - By @davypeterbraun 18
2/ Sweeter delivery of data to the frontend
- Declarative style
Tell the server what you need. Not how you want to get it.
- Compositionality
Achieve better flexibility in your code composing/combining
fragments and queries
- Strong typing
Already hooked on TypeScript (strongly typed)
19. Meetup #ParisAPI - By @davypeterbraun 19
3/ Teambuilding...
- Yay! Brand new toy!
- Slowly building up a new, shared expertise
- It does add a line on our resume...
20. Meetup #ParisAPI - By @davypeterbraun 20
4/ …and brand awareness / visibility
- Expertise turned into content marketing, blog posts…
- Makes our “exotic” stack shine a little more in job fairs
- Allow us to come talk to you!