The ability to reply to discussions is limited to PRO members. Want to join in the discussion? Click here to subscribe now.

Write a GraphQL Schema in JavaScript

Write a GraphQL Schema in JavaScript

5:38
Writing out a GraphQL Schema in the common GraphQL Language can work for simple GraphQL Schemas, but as our application grows, or when we start using more complex types like interfaces or unions, we find that we can’t use a GraphQL Language file in the same way as before. In this video, we’ll learn how to translate a GraphQL Schema written in GraphQL into a GraphQL Schema written in JavaScript.
Watch this lesson now
Avatar
egghead.io

Writing out a GraphQL Schema in the common GraphQL Language can work for simple GraphQL Schemas, but as our application grows, or when we start using more complex types like interfaces or unions, we find that we can’t use a GraphQL Language file in the same way as before. In this video, we’ll learn how to translate a GraphQL Schema written in GraphQL into a GraphQL Schema written in JavaScript.

Avatar
p4bloch

Could you please elaborate a bit on why using JS to describe your schema is better than using GraphQL Language directly? Interfaces and Unions can also be defined using the QL. Thanks!

Avatar
Josh Black

That's a great question, and I think the answer is that it's not necessarily better. It most likely depends on your use-case, whether or not you're starting a product/service from scratch or not, and how much control you need in resolvers.

I think a key constraint of GraphQL JS is that the buildSchema utility will not let you define proper resolvers for Union/Interface types that you define in the GraphQL Language. There are definitely ways around this limitation, and Apollo is doing a great job of demonstrating that. In Apollo-related projects they actually have you define your schema in the GraphQL Language, and then you define the resolvers separately, much like you described above.

I think this approach is awesome, and can make things incredibly simple to get up and running so if that's what you want to do definitely go for it. From another perspective, if you're creating a GraphQL Schema and you want to implement a middleware-esque pattern on resolvers then you might want more fine-grained control of your schema. You might also want to leverage existing JS-tools that you have, such as codemods, in order to maintain your codebase and bring it along with you as your product/service/company grows.

At a high level, I think that covers why you might want to use one or the other. I think they're both great strategies, and one can make whichever approach they choose work for their use case. Hope that helps!

In reply to p4bloch
Avatar
p4bloch

Thanks for such a detailed response, you surely cleared out some doubts I had. I indeed used Apollo's graphql-tools's makeExecutableSchema function. I believe graphql-tools as a project itself is intended to be used without having to use the rest of Apollo server's middlewares so maybe it is useful as a mere replacement of buildSchema as well.

I definitely were not aware of buildSchema's limitations, thanks for pointing that out.

I understand that in a complex application you might want to have the schema be more malleable than just strings, but I wonder how far you can actually get without it. Definitely the GraphQL JS limitations are a quick deal breaker (maybe because of its reference implementation nature?), but Apollo seems to be doing a much better job on making GraphQL production ready tools for Javascript.

Ultimately I would expect not having to worry about how the schema is defined (and use the much clearer and generic GraphQL notation) but instead having the resolvers layer to be able to handle any complexity that may arise beyond that schema.

Thanks for the course Josh, a very valuable GraphQL resource :)

In reply to Josh Black
Avatar
Josh Black

Ultimately I would expect not having to worry about how the schema is defined (and use the much clearer and generic GraphQL notation) but instead having the resolvers layer to be able to handle any complexity that may arise beyond that schema.

Totally understand this, and am so thankful for Apollo for building out the tools to allow this 😄

If you're curious, should definitely try out Elixir or Scala's GraphQL implementations just to see their perspective on this stuff as well!

Also, thank you so much for watching! I'm so glad it was helpful!

In reply to p4bloch
HEY, QUICK QUESTION!
Joel's Head
Why are we asking?