Regarding GraphQL, I think the reason is at least partially that there aren't too many applications that actually benefit from the all-dynamic approach of it. It's neat and useful in certain applications, but I wouldn't use it everywhere. The tooling isn't quite there yet also in my opinion, but the friction will probably go away with time.
It's a data access language where data sources are a far secondary concern for the tooling, and it looks like the tooling does not care about access control at all.
The standard looks great, and with some time some useful tools will probably arrive. But not right now.
I agree that the dynamic querying aspect of it isn’t useful in most apps but the way graphql simplifies your API (and maybe your state management) compared to REST is by itself, I think, worth it. Tooling seems to be ramping up quickly but I agree, isn’t there yet.
Yeah, I assume the low usage of GraphQL in this survey coordinates/correlates with the low usage/knowledge about Apollo in this survey. Apollo seems the most invested in ramping up strong tools for GraphQL, so of course developers aren't likely to be using GraphQL if they haven't yet heard about/explored Apollo's efforts.
For instance, apollo-link-rest would be a strong way to bootstrap into GraphQL for shops with heavy REST investments.
That said, Apollo aren't yet doing themselves favors with nearly every part of their tooling still showing a "Caution: Active Development" warning. That keeps them right on that cusp of "Should I use this in production?" worry for enterprise, and slows adoption probably more than they intend.
