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.
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.
I started coding 10 years ago (damn I just figured that...) learning C at my engineering school for 2 years. Never had to use it ever since (mostly working front-end and webAPIs) but I'm still glad I studied it to learn the programming foundations.
I would probably choose Rust or Go today though.
Although you said there is not much literature around the subject, did you find anything? This has always been one of my favorite aspects of The Elder's Scrolls and, of course, Tolkien.
GraphQL (advanced). Already been using it for 4 years now (yes back when there was no tooling nor best practices) but I decided to go further in the schema design thinking and bought Production-Ready GraphQL to help with it.
Strongly recommend the book as it goes quite deep on the subject.
Also experimenting with my 4th home-brewed beer.
"Soft skill"-wise I spend time helping people with good (so I hope) advice and recommendations and a bit of interview mentoring to enter the software development industry.
Makes you learn a lot about yourself and how you can motivate and help people big time with only a tiny amount of your time and energy, just sharing stuff you know.
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 :)