3 ms·

What would you do if someone wanted: - some fields of the resource - some fields of the comments - some fields of the user that made the comments

• simiones 6y ago
  It depends on performance requirements. Either ask them to retrieve the entire objects, or expose a new endpoint to retrieve the filtered list in an optimal way. API consumers definitely aren't the ones who should be thinking about something like joining behavior, since GraphQL doesn't give nearly enough control to achieve performant joining. Basic filtering can also be easily achieved with ad-hoc methods, such as query params. No need for a full-blown GraphQL language server in front of all your services.
  • mikewhy 6y ago
    No need for it, from your perspective, sure. It totally solves a lot of shortcomings your API is forcing on its consumers though.
    • simiones 6y ago
      In general, my consumers don't want to learn my API. If they find shortcomings, they don't want to work around them by learning to query my bad models, they will call and complain that my model is bad and that I have to fix it in the next version or they'll look elsewhere. At least, this has been our experience with B2B software sales. Of course, YMMV depending on market etc.