You really don't want to build yourself into a corner when making a GraphQL schema, it's a hassle to change and it will hurt you at some point. Creating the schema is an opportunity to bring everyone on the team together. Management, backend, and frontend can come together and figure out what it needs.
To learn how to design your own GraphQL schemas check out Nik's egghead.io course Designing GraphQL Schemas!
Taylor Bell: Hey, Nik, thanks for joining me today.
Nik Graf: Hey, happy to be here.
Taylor Bell: Yeah, so I wanted to talk to you a bit about your new course about designing graph QL schemas. So why is it important to learn a good way to design a schema?
Nik Graf: Well, I can tell you from my past experiences, I made some really big mistakes with some clients, customers, and my own stuff that I shipped and simply because you want to build a schema that stands the test of time. So basically, when you work on it, you don't want to build yourself into a corner where it's hard to get out because you made a decision, and you didn't think it through and then suddenly there's a requirement that comes in, you're like, "Oh, no, this is really bad for what we currently have. I wish we did that in the past."
Nik Graf: And there's a couple of patterns and lessons learned that are basically in every domain. They work for every domain, you can apply them and it will simply save you from that hassle and yeah, I've been there and I felt the need like this is... I've seen it so many times, people hire me for React development or helping them move GraphQL and then I see eight, well what you have is exactly, it's problematic. It will hurt you in a couple months or years and yeah, it's a pattern. You know when you see the same problem three times, it's worth it to make the course.
Taylor Bell: I think I like that kind of rule of thumb. So, when somebody goes to take your course, what's the journey that you take them on throughout this course?
Nik Graf: We start very simple with just basic naming conventions and then it's a little bit of mix and match. We'd be talking about what happens if you're in a situation where things went wrong and how you can get out of it. It requires multiple deploys and some time, time is really the key to do migrations without affecting end users. But the first part is very focused on queries and namings and then connections especially. So how to do pagination, how to do a cursor-based pagination, why cursor's important and then we'd go more into mutations and these are especially hard I think and to be honest, like yeah, there's even more, but I couldn't fit it all in. But yeah, I think this covers a lot of what's really, really important and yeah, I track it all the time. For me, it was read now with 99 hours of work only for the course, getting more the materials, the workshop and so on and it's all squeezed into 56 minutes or so, something like that.
Taylor Bell: That's pretty amazing that it can compress that far and still be, still retain all of the value and so it's interesting, something you said about there being more that you wanted to include. What are those next steps that someone should take after they work through this course?
Nik Graf: So I think what I haven't touched too much on is how to design as a team a schema. So what, for example, what I do usually when I come into a consulting kick and we talk about new part, a new feature, designing a new part of the schema, often it was... If you look at the... It's very natural that one person creates the schema, doesn't talk to anybody, this is the new schema, now use it and you're done. But the thing is it's in, GraphQL is the intersection point. It's a contract between the backend and one or multiple clients and it's such an opportunity when you design it because when you get at the point where you design it, when you get simply everyone into the room and you just talk about what are the actually needs and do you base it on the use cases, on the screenshots, on the wire frames and so on.
Nik Graf: You can really, you can have a great contract that's better for everyone and this is what I usually try to do with everyone is like, "Okay everyone should have a base knowledge about GraphQL," otherwise it doesn't work really well, but then take the time, get together in the room, maybe someone can come with the proposal, but then just look for the use cases and every client and everyone from backend can have their opinion and then you can find the best trade offs and make the best decisions hopefully and yeah, it really is... Designing together, especially when so many people are affected, this helps them and then just mark it out. Everybody can use it already while the backend is pulling out the rest and the clients already can consume it if it's marked service and yeah, maybe I can talk more about this in the future.
Taylor Bell: Cool. Well thanks so much for joining me today and congrats on putting in all of this time and then making a wonderful final product.
Nik Graf: Thank you. Thank you much.