4 ms·

it's just a hit to the db. Graphql works the same way if i'm not mistaken. and if its the case that you don't want the comments at all, then in the conditiona

it's just a hit to the db. Graphql works the same way if i'm not mistaken. and if its the case that you don't want the comments at all, then in the conditionals write your sql statements if you want comments select * from resource where id=some resource id if you don't select without comments from resource where id=some resource id there's no need to get into specifics, the point is graphql is not bringing anything novel. everything it claims to do can be implemented in RESt if you're willing to implement it.

n_e 6y ago
I’m talking about the GraphQL or OAS schema. With a REST API, the “resource” type will always have an optional “comments” field, whatever the value of arg is. With a GraphQL API you’ll have the right type depending on your query.
- adamscybot 6y ago
  Yep. OpenAPI spec is not rich enough to represent relations like this so its rubbish for FE dev to use to generate models/api client. In general, the tooling/spec has thousands of open bugs, isnt going anywhere, moves very slowly and is missing fundamental features. https://github.com/OAI/OpenAPI-Specification/issues/1998 https://github.com/OAI/OpenAPI-Specification/issues/1998 heres the ticket where it will inevitably be ignored and die. But even if it was supported in the spec, the open source generators wont support it anyways. Said generators also uses "logic less" templates to generate something that very much needs logic. As a FE dev, I love nothing more than to fork a an archaic Java based generator to get the client gen working...not.
- simiones 6y ago
  If you truly care about that, the truly REST solution would be to define separate MediaTypes and use Accepts headers to specify which MediaType is desired. So if you wanted comments you would send a request with a header like "Accept: application/resource_with_comments", and you'd send a Header like "Accept: application/resource_without_comments". The thing is, few people want this level of control in practice. This would generally lead to a huge proliferation of types for very little practical benefit. Much simpler to have a set of well-defined types with optional fields than to define a new type for each combination of fields used today.

n_e 6y ago

I’m talking about the GraphQL or OAS schema. With a REST API, the “resource” type will always have an optional “comments” field, whatever the value of arg is. With a GraphQL API you’ll have the right type depending on your query.

adamscybot 6y ago
Yep. OpenAPI spec is not rich enough to represent relations like this so its rubbish for FE dev to use to generate models/api client. In general, the tooling/spec has thousands of open bugs, isnt going anywhere, moves very slowly and is missing fundamental features. https://github.com/OAI/OpenAPI-Specification/issues/1998 https://github.com/OAI/OpenAPI-Specification/issues/1998 heres the ticket where it will inevitably be ignored and die. But even if it was supported in the spec, the open source generators wont support it anyways. Said generators also uses "logic less" templates to generate something that very much needs logic. As a FE dev, I love nothing more than to fork a an archaic Java based generator to get the client gen working...not.
simiones 6y ago
If you truly care about that, the truly REST solution would be to define separate MediaTypes and use Accepts headers to specify which MediaType is desired. So if you wanted comments you would send a request with a header like "Accept: application/resource_with_comments", and you'd send a Header like "Accept: application/resource_without_comments". The thing is, few people want this level of control in practice. This would generally lead to a huge proliferation of types for very little practical benefit. Much simpler to have a set of well-defined types with optional fields than to define a new type for each combination of fields used today.