3 ms·

I admit I never seen a use case that justify the complexity of usage. Let's say you have a native app and a web app. I don't see these 2 changing that much in t

I admit I never seen a use case that justify the complexity of usage. Let's say you have a native app and a web app. I don't see these 2 changing that much in terms of data so a an API middlelayer is just simpler. At work we have a use case like: well we create the data layer that you can query the way you want and the field you want with many clients involved. So like an API where you can make composable queries. To me that sounds like an API with query parameters, do we really need to use GraphQL? Let's see!

Kamq 4y ago
> I admit I never seen a use case that justify the complexity of usage. Let's say you have a native app and a web app. I don't see these 2 changing that much in terms of data so a an API middlelayer is just simpler. It has some benefits when you have multiple different products that need different "pieces" of the data, rather than 2 different clients for the same product. I never quite understood how much hype it got, but it provides some nice benefits in an internal corporate environment, especially when data within said environment has an "owner" and accessing it from a new place requires an entire process.
- InvOfSmallC 4y ago
  Yeah the project where we are going to use it consumers will do different products with the same data. So I’m curious to see how this will we actually implemented. (We also have Kafka topics where you can consume all the sources in your storage but that gives other problems so I’m not completely negative on giving a single point where you can aggregate data)
nrb 4y ago
> To me that sounds like an API with query parameters, do we really need to use GraphQL? Do you care about the API being discoverable and the schema being well described? Being able to see the relationships between the data? The type-safety that comes from the tooling? The ability to expose the field once on an entity that allows consumers to use it in any variety of queries?
- InvOfSmallC 4y ago
  I may have not done all my home works on the matter but how’s that different from exposing an OpenAPI that your client can consume and generate all needed classes etc… on top of that?

Kamq 4y ago

> I admit I never seen a use case that justify the complexity of usage. Let's say you have a native app and a web app. I don't see these 2 changing that much in terms of data so a an API middlelayer is just simpler. It has some benefits when you have multiple different products that need different "pieces" of the data, rather than 2 different clients for the same product. I never quite understood how much hype it got, but it provides some nice benefits in an internal corporate environment, especially when data within said environment has an "owner" and accessing it from a new place requires an entire process.

InvOfSmallC 4y ago
Yeah the project where we are going to use it consumers will do different products with the same data. So I’m curious to see how this will we actually implemented. (We also have Kafka topics where you can consume all the sources in your storage but that gives other problems so I’m not completely negative on giving a single point where you can aggregate data)

nrb 4y ago

> To me that sounds like an API with query parameters, do we really need to use GraphQL? Do you care about the API being discoverable and the schema being well described? Being able to see the relationships between the data? The type-safety that comes from the tooling? The ability to expose the field once on an entity that allows consumers to use it in any variety of queries?

InvOfSmallC 4y ago
I may have not done all my home works on the matter but how’s that different from exposing an OpenAPI that your client can consume and generate all needed classes etc… on top of that?