Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction to GraphQL (or How I Learned to Stop Worrying about REST APIs)

6,001 views

Published on

Talk for FOSSASIA 2016 (http://2016.fossasia.org)
----
This talk will give a brief and enlightening look into how GraphQL can help you address common weaknesses that you, as a web / mobile developer, would normally face with using / building typical REST API systems.

Let's stop fighting about whether we should implement the strictest interpretation of REST or how pragmatic REST-ful design is the only way to go, or debate about what REST is or what it should be.

A couple of demos (In Golang! Yay!) will be shown that are guaranteed to open up your eyes and see that the dawn of liberation for product developers is finally here.

Background: GraphQL is a data query language and runtime designed and used at Facebook to request and deliver data to mobile and web apps since 2012.

Hafiz Ismail (@sogko) is a contributor to Go / Golang implementation of GraphQL server library (https://github.com/graphql-go/graphql) and is looking to encourage fellow developers to join in the collaborative effort.

Published in: Technology

Introduction to GraphQL (or How I Learned to Stop Worrying about REST APIs)

  1. 1. Introduction to GraphQL Or How I Learned to Stop Worrying about REST APIs
  2. 2. Who Am I
  3. 3. Hafiz Ismail @sogko on all social media https://wehavefaces.net
  4. 4. What is this about?
  5. 5. What is this about? I'll try to convince you that GraphQL helps to address some of the more common headaches developers faced when building a REST API -backed application.
  6. 6. Who is this for?
  7. 7. Who is this for? Developers, developers, developers
  8. 8. Let's start!
  9. 9. Typical architecture of a web application using REST API
  10. 10. Understanding common issues that developers face How?
  11. 11. Let's try to design and build a REST application together! Yay!
  12. 12. Goal: A newsfeed SPA Mobile-first REST API for data fetching
  13. 13. Designing the REST API Two resources - Users - Posts POST /posts GET /posts/1 PUT /posts/1 DELETE /posts/1 ... POST /users GET /users/1 PUT /users/1 DELETE /users/1 ... Someone said: Let's achieve strict REST! We can do this!
  14. 14. Let's see what happen
  15. 15. Render newsfeed GET /posts?limit=10 { "posts": [ { "id": 1, "title": "Hello world!", "author": 10, "viewCount": 23, "likedCount": 3, "likedBy": [1, 3], }, ... ] } - Great! Oh wait, we need to get author's name and avatar URL
  16. 16. Render newsfeed GET /posts?limit=10 GET /users/10 { "user": { "id": 10, "name": "John Doe", "nickname": "Johnny", "age": 23, "avatar_url": "/avatar/10.jpg" } } - So we make another request to get the author for the first post...
  17. 17. Render newsfeed GET /posts?limit=10 GET /users/10 GET /users/20 { "user": { "id": 20, "name": "Emily Sue", "nickname": "M", "age": 25, "avatar_url": "/avatar/20.jpg" } } Wait, so we have to do a separate request for each post to get information for its author? Hhnnggghhh !
  18. 18. Issue #1: Multiple round trips This is no bueno
  19. 19. Issue #1: Multiple round trips One possible solution: - A new endpoint /newsfeed But now you have a singleton REST resource that is too tightly- coupled to your client UI. You then tell yourself "it's not that bad. We're still REST-ish." Eventually, you launch your app with its mobile client and it went viral! Yay!
  20. 20. New requirement! Here comes your product designer with changes
  21. 21. New requirement! • It has been a year since you first launch your mobile client, and you have several versions of the client out in the wild. • Your product designer said: "We need to stop showing the view_count because of reasons" • What do you do now?
  22. 22. • Removing the view_count field from /newsfeed is not an option. • Older version of your mobile client depends on it. (What if they crash? #nilpointerreference) • So newer version of the mobile client does not need the view_count field, but to cater to the older versions, the /newsfeed still need to return it.
  23. 23. • What if this keeps happening? Newer clients would be requesting data that they essentially don't need anymore. • Not that bad when you just start out, but in the long run, it'll be something nagging at you • Sleepless nights are ahead for you.
  24. 24. Issue #2: Overfetching of data
  25. 25. Issue #2: Overfetching of data Wouldn't it be nice if there client receives only the data that it requires and had requested? One possible way to go about this: • Endpoint accepts parameter to specify the fields that you are interested in Not a bad solution, but yet another thing to worry about.
  26. 26. From a humble SPA to a full-fledge product You and your core team have build this complex API that serves a great purpose.
  27. 27. From a humble SPA to a full- fledge product • Your CEO recently announced that he envisions that your product should have a client for every device / platform imaginable. • iOS, Android, OSX, Windows, Linux • Raspberry Pis, BBC micro:bits • Cars • Your mom's toaster
  28. 28. From a humble SPA to a full- fledge product • New hires/developers join in. • How do you quickly allow new developers to study your API • What resources are available, • What parameters are accepted • Which ones are required, which ones are not?
  29. 29. From a humble SPA to a full- fledge product • If only you had used Swagger / RAML / API Blueprint when you started. • Now you have to invest time/effort into it. • Or probably you already did, bonus points for you !
  30. 30. Issue #3: Documenting your API now becomes a thing.
  31. 31. Issue #3: Documenting your API now becomes a thing. • More than just writing down the specs in a formal form so that it can be referenced • How you allow one to discover and explore your API? • Big enough concern that some parts of the community has banded together to create tools for this. (Which is a great thing, yay open-source) • But yet another thing for you to worry about.
  32. 32. Had enough? So how do we proceed from here?
  33. 33. Here's where GraphQL can help
  34. 34. What is GraphQL?
  35. 35. What is GraphQL? GraphQL is a data query language and runtime designed and used at Facebook to request and deliver data to mobile and web apps since 2012 Source: http://graphql.org
  36. 36. What is GraphQL? What you need to know: - A GraphQL query is a string interpreted by a server that returns data in a specified format. Which format? Another propriety format from FB aye?
  37. 37. What is GraphQL? Here is an example query and its response:
  38. 38. What is GraphQL? Here is an example query and its response:
  39. 39. Wait, so how does GraphQL address the issues previously raised? Does it even lift, bruh?
  40. 40. Wait, so how does GraphQL address the issues previously raised? Let me show you
  41. 41. Recap of the issues Issue #1: Multiple round trips. Issue #2: Overfetching of data. Issue #3: Documenting your API now becomes a thing.
  42. 42. It's demo time! !
  43. 43. Review of demo Hope nothing crashes
  44. 44. Review of demo • How to do a query • curl • GraphiQL (https://github.com/graphql/graphiql) • Uses introspection queries to allow one to explore API
  45. 45. Review of demo • Addressed the issues that we had previously raised 1. One query is all your probably need to render your UI fully 2. Your clients would only get data that it is interested in. 3. Built-in documentation and introspection as part as Schema definition.
  46. 46. What's next?
  47. 47. What's next? If you're interested to learn more about GraphQL - GraphQL : https://graphql.org - #graphql - Twitter : https://twitter.com/search?q=graphql - Medium : https://medium.com/search?q=graphql - https://wehavefaces.net #shamelessplug - A couple of introductory articles (Go + GraphQL + Relay) - More articles coming soon
  48. 48. What's next? GraphQL libraries for many platforms available - graphql-js (NodeJS) - graphql-ruby (Ruby) - graphene (Python) - sangria (Scala) - graphql-go (Go/Golang) (btdubs, GraphQL is platform agnostic, yay)
  49. 49. The real reason why I'm here Not for the money nor fame, but...
  50. 50. Looking for more contributors! graphql-go https://github.com/graphql-go/graphql • 8 months year old baby • Still at its infancy, but growing fast • Very pleasant and chill community; constructive discussion always encouraged. • Actively looking for more contributors (Currently at 15)
  51. 51. Looking for more contributors! graphql-go https://github.com/graphql-go/graphql Ping me @sogko or @chris-ramon Or better yet, dive right in and just submit a PR! Very much encouraged
  52. 52. Thanks for listening Feel free to come up and say hi Slides will be up @ https://github.com/sogko/fossasia-2016-graphql-demo

×