Hey, I recommend checking out type-graphql and especially Nexus to work with GraphQL on server-side. If you want to go serious about GraphQL I also recommend reading Production-ready GraphQL. I've been working with gql for 4 years now but this book really deepened how I think about modelling my schemas, queries and mutations.

All the best on your learning journey!

Thank you! In fact I have been using type-graphql for this project.

I'll make a note to check out Nexus. Some other contenders to go into my tech stack were Hasura, Prisma and Postgraphile, but I wanted something a little bit closer to the vanilla GraphQL experience...

Agree with you. The more vanilla GraphQL you go in the beginning, the more you'll be able to choose abstraction you want on top of that.

If I had to give you just one tip to design your schema: favor simple queries and mutations that do just one thing instead of trying to generalize your use-cases. For example if you want your client to be able to retrieve your Products by id and by name, instead of going for `product(id: String, name: String)` go for `productById(id: String!)` and `productByName(name: String!)` You'll end up with more fields on Query but the Product type stays the same, the arguments are clearer (just one that is required) and you'll get simpler resolvers. To generalize: forget about REST best practices, think about you queries and mutations as functions and write them with the according best practices you would apply to functions.

Funny thing I noticed about gql is front-end developers are generally more comfortable than back-end ones geting the grasp of it as its DNA is really client-focused.

Sorry for the long reply :)

Indeed, at my company I've been working with GraphQL for a while now (about a year and then something) as a frontend developer, and our main way of communication with the backend was writing out a GraphQL file as a draft of how we imagine the API should turn out.

It's nice!