Paving a New Path for GraphQL Schemas

GraphQL Conf Asia 2019

Transcript

1. Paving a New Path for GraphQL Schemas @tgriesser
2. “Fast, Reliable testing for anything that runs in a browser” Free, Open Source
3. ❤
4. ❤ A Brief Timeline
5. 2015: graphql-js
8. Later 2015 graph.ql 2015: graphql-js
9. Original “SDL First” Library: Released November 2015
12. "
13. Later 2015 - 2016: graph.ql graphql-tools 2015: graphql-js
14. 2015: graphql-js Later 2015 - 2016: graph.ql graphql-tools 2017: Graphene (Python)
16. – Me, when beginning to use Graphene “Oh no, this library doesn’t develop the SDL first”
17. …a few months pass
18. – Me, after spending a few more months in Graphene “Hey, this is actually pretty nice… scales really well to multiple teams”
19. Stats from Generated SDL: 307 object types 129 input types 89 enum types 10 interfaces 5 custom scalars 1 union type 0 custom directives 2542 output fields 581 input fields 717 enum members 35 deprecations ~ 18 developers contributing to the same schema
20. GitHub Public API SDL: 326 object types 90 input types 70 enum types 25 interfaces 8 custom scalars 20 union types 0 custom directives 2085 output fields 307 input fields 299 enum members 6 deprecations https://github.com/octokit/graphql-schema
21. 2015: graphql-js Later 2015 - 2016: graph.ql graphql-tools 2017: Graphene (Python) 2018: GraphQL Ruby
23. 2015: graphql-js Later 2015 - 2016: graph.ql graphql-tools 2017: Graphene (Python) 2018: GraphQL Ruby Also 2018: graphql-tools + graphql-code-generator
24. – Marc-Andre Giroux during Q&A after at GraphQL NYC “…I’m not sure - SDL first seems to be unique to the JavaScript community”
25. – Again, still just quoting my own thoughts here… “The JavaScript ecosystem is really missing out”
26. Figuratively speaking, when you pave the way for someone, you make it easier for them to do something
27. A better experience building code-first schemas in JavaScript & TypeScript
28. Why not SDL first?
29. GraphQL Nexus Why not SDL first?
30. Related Tooling in the Ecosystem GraphQL Nexus Why not SDL first?
31. Why not SDL first? Related Tooling in the Ecosystem GraphQL Nexus How SDL is Still Incredibly Useful
32. Why not SDL first?
33. Code Duplication
35. “Double Declaration Problem”
36. Implemented 16 times in GitHub’s Public API… Adding a new field with SDL first would mean finding all 16 locations and adding the new field
37. Code Duplication Documentation / Type Ordering
38. Code Duplication Documentation / Type Ordering Building For Larger Teams
39. Code Duplication Documentation / Type Ordering Building For Larger Teams Tooling Complexity
40. Code Duplication Documentation / Type Ordering Building For Larger Teams Tooling Complexity Microservices??
42. https://nexus.js.org
43. Code First
44. Code First Declarative
47. Code First Declarative Type-Safe
48. Code First Declarative Type-Safe JavaScript Friendly
49. Code First Declarative Type-Safe JavaScript Friendly Opinionated
50. Code First Declarative Type-Safe JavaScript Friendly Opinionated** **but only slightly, configurable, and hopefully not too controversial
51. What makes it different??
52. Development Feedback Loop
53. “makeSchema”
 Generates Types
54. “makeSchema”
 Generates Types Generated types are 
 Inferred by
 TypeScript Outputs SDL Schema Artifact Creates GraphQL schema Outputs TypeScript Types Imported type “registry” wired up
55. “makeSchema”
 Generates Types Generated types are 
 Inferred by
 TypeScript Changes to
 Schema, Restart 
 the Server IDE Auto-Completion & Type Checking Optional for JS development
56. “makeSchema”
 Generates Types Generated types are 
 Inferred by
 TypeScript Changes to
 Schema, Restart 
 the Server Regenerates SDL & Types files
57. Type-Safety
61. Type Factories
64. Opinions: Nullability
65. – GraphQL Documentation “... in a GraphQL type system, every field is nullable by default. This is because there are many things which can go awry in a networked service backed by databases and other services. A database could go down, an asynchronous action could fail, an exception could be thrown. Beyond simply system failures, authorization can often be granular, where individual fields within a request can have different authorization rules.”
66. Exceptional States Should be Exceptional: “null” to indicate network failure should be declared & documented
67. – GraphQL Documentation “... in a GraphQL type system, every field is nullable by default. This is because there are many things which can go awry in a networked service backed by databases and other services. A database could go down, an asynchronous action could fail, an exception could be thrown. Beyond simply system failures, authorization can often be granular, where individual fields within a request can have different authorization rules.”
68. email: String! email: "N/A" email: ""
70. Configurable, schema level or type level
71. Opinions: Authorize
73. The SDL Converter
75. Paste your SDL endpoint Thanks @swcarlosrj
76. nexus-prisma
78. Allows user to “override / configure” default Prisma types Allows you to “eject” from the Prisma DB conventions Just a thin wrapper over Nexus generated layer Similar approach could be used elsewhere, dynamic - similar to Gatsby’s approach
79. The Bad Parts Rough Edges
80. “makeSchema”
 Generates Types Generated types are 
 Inferred by
 TypeScript Changes to
 Code, Restarts
 the Server Requires Some Configuration ?? Chicken / Egg Problem TypeScript errors are sometimes cryptic Dynamic Types & Jump To Code
81. Other Code-First Tooling
85. What’s Next?
86. Middleware Pipeline Progammatic Directives Better interop with SDL snippets “Missing field” generation hooks Input Args/Type Validation ???
88. SDL is Still Incredibly Useful
89. Prototyping New Features
91. Users don’t see our code, they just want a good experience on the web
92. Pick whichever tools help you solve problems
93. Thanks! https://nexus.js.org @tgriesser