Great example, I contract in FE space and GraphQL is very often brought up - 100% in project context where it didn't really make sense and most of the time I go

Great example, I contract in FE space and GraphQL is very often brought up - 100% in project context where it didn't really make sense and most of the time I got the feeling they will bring it up to have it on the CV or out of FOMO. I personally see good use in GraphQL for 2 usecases: - Aggregator over existing (!) microservices backend arch that has REST (plus maybe gRPC) in place, to allow FE people to move fast with their UI. In no way should new services be written in GraphQL, BE should still use REST (+gRPC) - Prototyping/Fast clickdummy implementation; ideally a Snapshopt of an existing DB is used, and graphQL adapter for 1:1 entity mapping to allow 1-2 FE devs to quickly toss together a new FE (this should under no circumstances be used for anything even close to production) Cases where it has been pitched to me where I see no increased value: - BE team is too slow/lazy/defensive for new features (just have a GraphQL adapter and 1:1 map db entities to GraphQL entities -> please don't do that) - having "typed" queries (you should just use typescript to strictly type your REST DTOs instead and optionally use a VM mapping)