Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Replacing REST with GraphQL

Replacing REST with GraphQL

Gamechanger for both front- and backend

Cdc67badcd6322c88bd92d4dbb391ff9?s=128

Johannes Nagl

October 23, 2018
Tweet

More Decks by Johannes Nagl

Other Decks in Technology

Transcript

  1. Replacing REST with GraphQL Gamechanger for both front- and backend

    Die Socialisten / Swat.io, @jollife CTO, #proudDadOfAGirl, Life Long Learner
  2. Swat.io Social Media Management for Teams — 5 Developers, 7

    servers, 2 TB of database — PHP7.2, PostgreSQL, ElasticSearch, Laravel, CakePHP, Queues, Queues, Queues — Lots of high volume customers — 5 Mio API outgoing requests/day — 0.5 Mio incoming API requests/day — Only constant: Change
  3. Skills "We <3 to take full advantage of our abilities

    and talents, as well as further developing them together." Action "We don't default to blindly following the rules. We encourage everyone to give feedback and show initiative at any time."
  4. Rest APIs — Pros: — Client <> Server architecture —

    Stateless — Cons: — Every REST API looks differently — Client can't define the response structure1 — Documentation separated from code — Deprecations not possible 1 Sparse fieldsets might be supported - see Facebook Graph API
  5. Rest API v1.0 GET /users POST /users GET /users/:id GET

    /users/:id/todos
  6. Rest API v1.1 GET /users POST /users GET /users/:id GET

    /users/:id/todos GET /users_with_todos
  7. Rest API v1.2 GET /users POST /users GET /users/:id GET

    /users/:id/todos GET /users_with_todos GET /todos_with_users
  8. Facebook @ Scale — Facebook has to support ~ 20

    Different App Versions at same time. — All are using different fields / endpoints from their APIs.
  9. Facebook @ Scale — Facebook has to support ~ 20

    Different App Versions at same time. — All are using different fields / endpoints from their APIs. What the hell?
  10. Introducing GraphQL A query language for your API

  11. “GraphQL is a query language for APIs […]. GraphQL provides

    a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more ….” — https://graphql.org/
  12. GraphQL APIs — Pros: — Client <> Server architecture —

    Stateless — All GraphQL APIs work the same — Consumer defines what fields/relations should be queried and how the response should look like — Combine whatever data you would like — Documentation/Deprecations are part of your schema
  13. Rest in practice — Backend is adding new fields to

    existing endpoints — Existing implementations need to be checked — Backend is adding new endpoints — Frontend needs to wait for new endpoints — Frontend receives unneccessary data GraphQL in practice — Backend defines the schema once — Frontend is asking for all required fields without backend devs adding new endpoints
  14. Key terminology — Define your graph as a Schema —

    Receive Data through Queries — Write Data with Mutations — Learn about your schema with Introspection There's more, of course! — Have a look yourselves! https://graphql.org/learn/ — Fields, Arguments, Aliases, Fragments, Variables, Directives, Subscriptions, …
  15. GraphQL Schema Definition Language Example: type BlogPost { title: String!

    author: User body: String } type User { id: Id! firstName: String lastName: String }
  16. GraphQL Query Example 1 Request: POST /graphql { users {

    id first_name } } Response: { "data": { "users": [{ "id": "7631", "first_name": "Johannes" }] } }
  17. GraphQL Query Example 2 Request: POST /graphql { users {

    id first_name last_name } } Response: { "data": { "users": [{ "id": "7631", "first_name": "Johannes", "last_name": "Nagl" }] } }
  18. GraphQL Query Example 3 Demo time! ! — GraphiQL Explorer

  19. GraphQL Query Real Life Example In one request, we're fetching

    — current client — all channels — all users — all permissions of these users — current client member — permissions for all channels — client list — current User — all groups the user owns — last 10 notifications Frontend can, at any time, add even more fields …
  20. GraphQL Mutation Example 1 Request: POST /graphql mutation { clientUpdate(id:159,

    name:"Testing") { id name } } Response: { "data": { "clientUpdate": { "id": "159", "name": "Testing" } }
  21. GraphQL Benefits — Type Safety — Documentation — Deprecations

  22. GraphQL Type Safety: Request: ! mutation newClient { clientCreate(group_id: 7,

    name:"New Client Name") { id name } } Response: ! { "data": { "clientCreate": { "id": "3720", "name": "New Client Name" } } }
  23. GraphQL Type Safety: mutation newClient { clientCreate(group_id: asdf) }

  24. GraphQL Documentation: name' => [ 'type' => Type::nonNull(Type::string()), 'description' =>

    "The name of this channel, usually as provided by the external network. …" ],
  25. GraphQL Deprecations: 'client_id' => [ 'type' => Type::nonNull(Type::id()), 'description' =>

    'The ID of the client this channel belongs to.', 'deprecationReason' => 'Use `channel.client` instead.', ],
  26. I can haz bugs in the frontend?

  27. No

  28. Swat.io Frontend Build Process What's new? — Our new SPA

    is different. It's not using JavaScript — We use TypeScript now! — You named it! TypeScript uses … Types! — Even better: It uses the GraphQL typings! — The best: The typings are generated automatically!
  29. Old Swat.io Frontend Build Process So, that's the deal: 1.

    A developer implements something 2. Code is reviewed, tested locally and then deployed 3. Developers tend to forget impact in other repos 4. Customers find out in production: 5. Customer talks to Support talks to Developer talks to Developer: Ah, I forgot to change X! 6. Bugfix Time ⏰
  30. New Swat.io Frontend Build Process So, here's the deal: 1.

    A developer implements something 2. Afterwards, the build process is triggered 3. The build process downloads the latest GraphQL schema 4. It uses the generated typings for type checking the whole code base 5. There is no 5. step !
  31. Swat.io Frontend Build Process If the build is fine: 1.

    Instant profit ! If the build fails: 1. Meaningful error messages 2. We fix the bugs before hitting production
  32. Demo Time

  33. Tooling / Links — GraphiQL: https://github.com/graphql/graphiql (A graphical interactive in-browser

    GraphQL IDE) — GraphQL VS Code extension: https://github.com/ prisma/vscode-graphql (autocompletion, go-to definition, syntax highlighting) — GraphQL PHPStorm plugin: https:// plugins.jetbrains.com/plugin/8097-js-graphql (auto-completion, go-to definition, syntax highlighting)
  34. Links — https://nicolasdular.com/blog/2018/05/06/rest-in-peace- welcome-to-graphql/ — https://facebook.github.io/relay/ (Facebook Javascript Framework for

    React-Apps) — https://www.apollographql.com/ (Server, Client for JavaScript) — https://www.onegraph.com/ (Connect SalesForce, Stripe, GitHub, Intercom, Slack, Paypal … into your GraphQL Service) — https://github.com/Folkloreatelier/laravel-graphql (GraphQL Package for Laravel)
  35. Questions? Answers!

  36. Questions? Answers! Of course, we're looking for new team members!