15 ms·

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 Ha

• selfish-duck 6y ago
  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 :)
  • brainlessdev 6y ago
    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!