Paving a New Path for GraphQL Schemas

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

6. None
7. None

8. Later 2015 graph.ql 2015: graphql-js

9. Original “SDL First” Library: Released November 2015

10. None
11. None

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)
15. None

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
22. None

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

34. None

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??
41. None

42. https://nexus.js.org

43. Code First

44. Code First Declarative

45. None
46. None

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

58. None
59. None
60. None

61. Type Factories

62. None
63. None

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: ""

69. None

70. Configurable, schema level or type level

71. Opinions: Authorize

72. None

73. The SDL Converter

74. None

75. Paste your SDL endpoint Thanks @swcarlosrj

76. nexus-prisma

77. None

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

82. None
83. None
84. None

85. What’s Next?

86. Middleware Pipeline Progammatic Directives Better interop with SDL snippets “Missing

    field” generation hooks Input Args/Type Validation ???
87. None

88. SDL is Still Incredibly Useful

89. Prototyping New Features

90. None

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