Skip to content
This repository was archived by the owner on Mar 16, 2020. It is now read-only.

deck.mdx

Latest commit

 

History

History
334 lines (274 loc) · 6 KB

deck.mdx

File metadata and controls

334 lines (274 loc) · 6 KB

import { Head, Appear, Notes } from "mdx-deck"; import { Split } from 'mdx-deck/layouts' import {Img} from './components/image.js'

export { default as theme } from './theme'

<title>GraphQL is awesome!</title>

What can GraphQL do for app developers

Who am I

Saša Pul

  • fullstack dev @Freska
  • not an IOS, or mac developer
  • startred using GraphQL roughly 6 months ago
  • my first public talk
- fullstack means I do JS, and it spans both FE and BE
- did a react native app with a few Objective-c classes
- NOT a gql expert, just think it's awesome and love to talk about it
- first talk - go easy on me :) 
-

What is GraphQL?

- who has heard of it
- who has used it?
- used it as a consumer or created an API

Strongly typed query language for your API

And a server-side runtime for executing queries...

...by using a type system you define for your data.

- strongly typed: if type validation fails, request fails

More efficient alternative to REST

  • Created (2012.) and opensourced by Facebook (2015.)
  • Enables declarative data fetching
  • Exposes a single endpoint
  • Not limited to frontend/react
- first used for FB native mobile app
- spec, and graphqlJS by FB
- announced by FB on react conf, so there was a confusion about it and it was not often mentioned in context of mobile apps

Implementations

  • Client
    • C#, Clojurescript, Go, Java (Android), JavaScript, Swift/Objective-C, Python...
  • Server
    • C#, Clojure, Elixir, Erlang, Go, Groovy, Java, JavaScript, PHP, Python, Scala, Ruby...
- https://graphql.org/users/
- sure to spot some familiar logos

Advantages over REST

  • more efficient data fetching
  • no need for versioning
  • composing APIs
  • powerful analytics
- versioning:
  - no need to adjust API with every product requirement or design change
  - if new data is needed, simply add it to the schema, and those who need it will use it
- composing: use several different resources, or even combine multiple graphql APIs
  - exapmle: use your backend API alongside contentful (or whatever CMS) API
- analytics:
  - able to track what data is requested by clients
  - evolve and deprecate

export default Split

<Img src={require("file-loader!./mock.png")}/>

users/[id]/
users/[id]/posts/
posts/[id]/
users/[id]/
users/[id]/
users/[id]/
- no overfetching / underfetching
- overfetching: downloading unnecessary data
- underfetching: not getting enough data, need to make subsequent requests
- depending on the backend api, data loader or a specific db query will batch all user requests

export default Split

<Img src={require("file-loader!./mock.png")}/>

{
  query($id: Number) {
    users(id: $id) {
      friendsCount
      likes
      commentsCount
      photo
      posts {
        content
        likes {
          users {
            name
            friendsCount
          }
        }
      }
    } 
  }
}

How does it work

Core elements

  • schema
    • the 'contract'
    • defined by SDL
    • strict types
  • resolver functions
    • each defined type needs a corresponding resolver function

Simple exapmle

export default Split

# schema

type Person {
  name: String!
  age: Int!
  hairColor: String
  shoeSize: Int
  posts: [Post!]!
}

type Post {
  title: String!
  author: Person!
  version: Float
  location: String
  likes: [Like]!
}

type Like {
  date: string
  by: Person!
}
# query

query {
  getPerson(personId: 99) {
    name
    age
    posts {
      title
      author
      likes{
        by {
          name
        }
      }
    }
  }
}
// resolver

async function getPerson(parent, args, context) {

  const person = await context.model.getPerson(args.personId);
  const posts = await contexe.model.getPostsById(person.postIds)
    .map(post => getLikesFromPost);  
  
  return {
    name,
    age,
    shoeSize,
    hairColor,
    posts,
  };
}

Some buzzwords

  • query, mutation, subscription
  • schema stitching
  • data loader
  • query fragments
  • schema introspection
- query, mut., sub. 
  - root types
  - define entry point
  - query is mandatory, mutation is not
  - parallel to get, post-put-patch-delete
  - sub opens a live channel

- stitching
  - include a remote schema and use it as your own
  - f.ex provide contentful or any other CMS (composing)
- loader
  - depending on implementation and resource type, batch requests
- fragments
  - named part of query that repeats
- introspection
  - https://graphql.github.io/swapi-graphql

- authorization
  - gql just a spec
  - http server underneeth
  - possible (and tempting) to do in resolvers
  - better in middleware, or resource
  - concept of resource: api or db handler

Summary

  • less requests
  • smaller data transfers
  • better ux

=== happy user

Summary

  • clearly defined, typed schema
  • easy upgrades
  • independent FE / BE
  • great analytics

=== happy developer

Resources

  • graphql.org/learn
  • howtographql.com
  • apollographql.com/docs/ios/

Questions?

Thank you

The End

- thnx to Steven for having me here
- thank you all for listening
- hope I've inspired some of you to try it out