Being able to have a standards based API with subscription capabilities would really help the Mikrotik Community.
https://graphql.org/blog/subscriptions-in-graphql-and-relay/
For instance, besides the normal menu system lookups, we can have subscriptions for interface counters and config changes.
This would really help out us network/software developers trying to integrate mikrotik into our ecosystem.
Thanks!
Oh god, please, no.
The power of ROS is consistency and API brings very clear error boundaries. GQL would destroy that model making the API actually very hard to use in a long run. Additionally deprecation of GQL is very tricky. However, the biggest hurtle is complexity and performance of the server: there are multiple implementation in majority of the relevant languages and all of them I’ve ever seen lack in multiple areas.
Don’t get me wrong: I would love to tinker with GQL and ROS, but it’s simply not a great fit. To provide some context I’m saying this from a position of a lead developer of a large medical platform extensively utilizing GQL. After couple of years I’m 100% sure the GQL was the best and the worst choice we made 
Nice wish - but won’t ever happen IMHO. We can be lucky - very very lucky- should v7 ever reach stable-status. So I guess the API has not the highest priority. And I am 100% sure that Mikrotik would not see any benefit of a GQL API anyway ^^