This is essentially a solved problem. You simply give all your fields a complexity value and then you limit the allowed complexity.
> - instead of delegating requests to optimized queries (db or services) you now collect all that data manually, in-memory, on the server with little to no insight into what the data is, and how to optimize its retrieval
Or you simply integrate tightly with an ORM or something and generate optimized queries from your GQL queries.
> - default types doesn't provide useful primitives like dates
Just not really an issue in practice, and really comes down to the underlying transport medium. JSON is limited. If you send a date over the string, it's either going to be a timestamp or a string. Your consumer will still need to know it's actually a date that needs to be deserialized. At least in GQL this is easy to do.
> - you now have to keep up with evolution of every single microservices you depend on
How is this a problem with GQL? Do you think that API versioning is in any way easier to when you have REST APIs? It's actually the opposite, because OpenAPI schemas suck and there is no great tooling that helps you stay on top of the changes. In contrast, there is excellent tooling for GQL that literally diff your new schema vs the old and tell you if any recent clients would be affected. You can do all this as part of your workflow(in CI etc) and act accordingly.