Stateless — Cons: — Every REST API looks differently — Client can't deﬁne the response structure1 — Documentation separated from code — Deprecations not possible 1 Sparse ﬁeldsets might be supported - see Facebook Graph API
Stateless — All GraphQL APIs work the same — Consumer deﬁnes what ﬁelds/relations should be queried and how the response should look like — Combine whatever data you would like — Documentation/Deprecations are part of your schema
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 deﬁnes the schema once — Frontend is asking for all required ﬁelds without backend devs adding new endpoints
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, …
— 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 notiﬁcations Frontend can, at any time, add even more ﬁelds …
A developer implements something 2. Code is reviewed, tested locally and then deployed 3. Developers tend to forget impact in other repos 4. Customers ﬁnd out in production: 5. Customer talks to Support talks to Developer talks to Developer: Ah, I forgot to change X! 6. Bugﬁx Time ⏰
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 !