GraphQL & K8S11.02.2019 by Mathieu Devos

● What is GraphQL?

● Why GraphQL?

● Some examples

● Disadvantages

● GraphQL in Serverless?

● Code examples (finally)

● Extra teasers

● Kubernetes (K8s)

● Code inspection

Outline

● API Querying language that follows a graph● Abstract from the business layer

⇒ Not a magical solution, still gotta write DB queries & logic● One single endpoint● Few years old, invented by Facebook, open source● Not language specific

○ Schema Defined Language (SDL)○ Front-end & Back-end○ All major languages support it

● 3 Major keywords○ Query○ Mutation○ Subscription

WHAT IS GRAPHQL?

3.5€

● Solves many issues of REST● No more underfetching or overfetching● No need for one endpoint per function ● Don’t need to recreate your whole API for a new type of client● Clean, abstract look, schemas specifically● No need for API documentation!● Introspection● Subscriptions are awesome!

⇒ Subscribe to websocket about a certain event that can happen⇒ Tell what you want from that event⇒ Instant feedback, gaming, chat-applications, ...

WHY GRAPHQL?

● Schema

Query { getPeople: [Person] getPerson(name: String!): Person}

Person { name: String! age: Number! massiveString: String! children: [Person]}

EXAMPLES

● REST way to get the names & ages of a person’s children?

GET /persons?name=bob⇒ { name: bob, age: 40, massivestring: …, children: [ alice, charlie, john ] }

GET /persons?name=alice ⇒ …GET /persons?name=charlie ⇒ …GET /persons?name=john ⇒ ...

● GraphQL: POST /graphql?q=’{ getPerson(name: bob), children { name, age } }’

● Schema

Query { getBooks: [Book] getBook(id: ID!): Book}

Mutation { addBook(title: string!, ISBN: string): Book!}

Book { id: ID! title: String! ISBN: String! autoGeneratedSummary: String!}

EXAMPLES ● REST way to create 3 books and get their summary back?

3x POST /books?name⇒ { ...book fields } ⇒ receive ID, store internally

GET /books/ID1 ⇒ …GET /books/ID2 ⇒ …GET /books/ID3 ⇒ …

● GraphQL: POST /graphql?q=’mutation{ book1: addBook(...) { id, autoGeneratedSummary },book2: addBook(...) { id, autoGeneratedSummary },book3: addBook(...) { id, autoGeneratedSummary } }’

● Schema

Query { getBooks: [Book] getBook(id: ID!): Book}

Subscription { bookWatcher: Book}

Book { id: ID! title: String! ISBN: String! autoGeneratedSummary: String!}

EXAMPLES ● REST way to watch if a new books show up

xTimes get /books ⇒ receive ID, store internally

Compare internally

● GraphQL: POST /graphql?q=subscription{ bookWatcher { id, title, ISBN, autoGeneratedSummary } }’

DISADVANTAGES

● Doesn’t write business code for you● Nested queries / mutations are not possible (some things possible with

directives)● Security? Complexity?

{ getPersons { children { parents { children { parents … ^ oh no, we broke it! ^

● Works well for normal size N:M, Massive sized relations should be done 1 way

● A sensor pushing an object every second should not keep trackwhich objects it has pushed. Rather the object should containthe sensor which created it

● Mutations are a horrible word and just straight up CRUDCreate, Read, Update, Delete

● Security to be done on the business layer (same as other APIs)

Query { getPersons: [Person] getYoungest(people: [Person]): Person}

Person { name: string! age: number! parents: [Person] children: [Person]}

{ getPersons { name, age, Query:getYoungest(people: children) { name, age } } }

^ perhaps my new pet project … :D

● Apollo has a server for it!○ https://www.apollographql.com/docs/apollo-server/servers/lambda.html○ https://www.npmjs.com/package/apollo-server-lambda (beta)

● Comes with a major restriction⇒ Subscriptions are not available (lambdas only live for 5 minutes)

● Also a few advantages○ Less lambdas to warm! All the same endpoint○ No longer deciding in between which way to pack what○ Made 1 mistake in a common code ⇒ 1 fix, deploy to 1 lambda

(both advantage & disadvantage)● Have yet to play around with this

GRAPHQL IN SERVERLESS

● Schema stitching ○ Combine multiple API endpoints○ Add existing REST APIs to your API○ Combination of local resources and Internet attached

● GraphQL on top of REST API● Prisma

○ Full fledged framework (heavy), needs dedicated server○ It does everything, fast, automatic, database included○ Time to API ⇒ Minutes-Hours…

● GraphiQL ⇒ https://graphiql.bustle.com/ ⇒ { __schema { types { name, description } } }

EXTRA TEASERS

● Requirements○ Database service

■ StatefulSet ■ Service (expose port & loadbalance)

○ Backend service■ Deployment (a fun little local hack of docker & vm)■ Service (expose nodePort)

○ Namespace (?)■ In production yes, Minikube sadly ⇒ no

● YAML Files <3 - fighting with minikube● https://github.com/mathieudevos/graphql-k8s

KUBERNETES

Mathieu Devos

Intopalo Digital Oy

+358 45 787 48074

mathieu.devos@intopalo.com 🔐 cryptup.org/pub/mathieu.devos@intopalo.com

THANK YOU!