OP is using Apollo Server, which is by far the most common server implementation for GraphQL. It may well be there are issues specific to Apollo, but it's definitely worth getting to the bottom of based on how widely used Apollo is.
There is nothing in the posts that identifies NodeJS as the culprit, and based on the info I'd be very surprised if it was. It seems most likely that the type validation is what is taking so much time. But then again, strong types are one of the main benefits of GraphQL. If anything, I've found Node to be one of the easiest and most "natural" server languages for GraphQL, and I have implemented GraphQL servers in Node, Java and Python.
I would be extremely (but prepared to be) surprised if Phoenix + Hasura were faster in terms of latency than Phoenix + Absinthe, since one has to enter and exit two vms and the other doesn't, unless you're suggesting the frontend issue graphql results directly to the hasura backend, bypassing phoenix.
The last comment specifically shows that there is one big part of degradation that depends on the usage of promises. This is either a platform or library problem, but surely not a GraphQL problem at all.
There is nothing in the posts that identifies NodeJS as the culprit, and based on the info I'd be very surprised if it was. It seems most likely that the type validation is what is taking so much time. But then again, strong types are one of the main benefits of GraphQL. If anything, I've found Node to be one of the easiest and most "natural" server languages for GraphQL, and I have implemented GraphQL servers in Node, Java and Python.