GraphQL Taiwan Meetup 003

1. 2018 重點整理理

2. •JavaScript Full Stack Developer
•參參與開源社群與專案約 4 年年
•GraphQL Taiwan 共同發起⼈人
•Yoctol System Developer Lead
C. T. Lin

6. •Building a Stable Base
•RFC Process (For example, Subscription Spec)
•GraphQL Working Group (1-2 month)
Opening

7. graphql/graphql-wg

8. •Type System Definition Language (SDL)
•GraphQL Subscriptions
•Error Paths
June 2018 Spec Release

9. Type System Definition Language
(SDL)

10. Subscriptions

11. Error Paths

13. A lot of software engineering
history is encountering some
horrific pain and then
overreacting to it.
- Nick Schrock

14. Microservices are not bad.
There are a tool, not a goal

15. The problem happens when you
attempt to decouple that which is
actually coupled

16. The worst of both worlds:
A distributed monolith

17. Your affection for GraphQL?
Your subconscious telling you that
it wants the good parts of the
monolith back.

20. https://bit.ly/graphql-design-tutorial

21. 1. Always start with a high-level view of the objects and
their relationships before you deal with specific fields.
2. Never expose implementation details in your API
design.
3. Design your API around the business domain, not the
implementation, user-interface, or legacy APIs.
4. It's easier to add fields than to remove them.
5. Major business-object types should always implement
Node.

22. 6. Group closely-related fields together into subobjects.
7. Always check whether list fields should be paginated or
not.
8. Always use object references instead of ID fields.
9. Choose field names based on what makes sense, not
based on the implementation or what the field is called
in legacy APIs.
10.Use custom scalar types when you're exposing
something with specific semantic value.

23. 11. Use enums for fields which can only take a specific set of values.
12.The API should provide business logic, not just data. Complex
calculations should be done on the server, in one place, not on
the client, in many places.
13.Provide the raw data too, even when there's business logic
around it.
14.Write separate mutations for separate logical actions on a
resource.
15.Mutating relationships is really complicated and not easily
summarized into a snappy rule.

24. 16.When writing separate mutations for relationships, consider
whether it would be useful for the mutations to operate on multiple
elements at once.
17. Prefix mutation names with the object they are mutating for
alphabetical grouping (e.g. use orderCancel instead
of cancelOrder).
18.Only make input fields required if they're actually semantically
required for the mutation to proceed.
19.Use weaker types for inputs (e.g. String instead of Email) when
the format is unambiguous and client-side validation is complex.
This lets the server run all non-trivial validations at once and return
the errors in a single place in a single format, simplifying the client.

25. 20.Use stronger types for inputs (e.g. DateTime instead of String)
when the format may be ambiguous and client-side validation is
simple. This provides clarity and encourages clients to use stricter
input controls (e.g. a date-picker widget instead of a free-text
field).
21. Structure mutation inputs to reduce duplication, even if this
requires relaxing requiredness constraints on certain fields.
22.Mutations should provide user/business-level errors via
a userErrors field on the mutation payload. The top-level query
errors entry is reserved for client and server-level errors.
23.Most payload fields for a mutation should be nullable, unless there
is really a value to return in every possible error case.

28. •GitHub Repo - https://github.com/prismagraphql/
vscode-graphql
•VSCode Marketplace - https://
marketplace.visualstudio.com/
items?itemName=Prisma.vscode-graphql
•Blog Post - https://www.prisma.io/blog/vscode-
thieghu7shoo/
Links

32. 投影片來來⾃自
http://graphql-eu-apollo.surge.sh

37. GraphQL Playground

40. •Further resources - https://github.com/peggyrayzis/future-
of-gql-servers#further-resources
•What's new? - https://www.apollographql.com/docs/
apollo-server/v2/whats-new.html#2-0
•Migrating to v2.0 - https://www.apollographql.com/docs/
apollo-server/v2/migration-two-dot.html
•Full Stack Error Handling with GraphQL and Apollo -
https://dev-blog.apollodata.com/full-stack-error-handling-
with-graphql-apollo-5c12da407210
•https://www.apollographql.com/docs/apollo-server/v2/
features/data-sources.html
Links

41. •Github Issue (Adonis, Micro, Restify, Koa) - https://
github.com/apollographql/apollo-server/issues/1088
Apollo Server 2:
Integrations

43. CI Checks

46. •Run JavaScript on Cloudflare with Workers - https://
blog.cloudflare.com/cloudflare-workers-unleashed/
•Early Access - http://apollographql.com/edge
Links

52. •GraphQL + Live Queries: 2 Years in Production (Stephen
Wan) - https://github.com/samsarahq/thunder
•GraphQL + Apollo + Vue = Magic - https://apollo-vue-
love.now.sh/
Resource Links

53. Thanks for Your Listening