Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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!




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: