graphql-js is the reference implementation of GraphQL, so it's not any random library.
* Though Ent’s creators emphatically claim it is not an ORM, that phrase does give you a rough but directionally-accurate idea of what it 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.
But if you're fetching a lot more data than you need for a typical UI, you might run into bottlenecks.
I'm still surprised it had that much overhead though, as I generally think of node as being relatively competitive with Java outside of heavy computation.
One issue I see a lot of (which happens to be part of the problem in this case) is people overfetching data on their list UI (e.g. search results) so that the detail page data is already in the client side store. But this is usually a premature optimisation and ends up causing more problems than it solves.
If you click on that you can get performance flame graphs / tables, memory profiling, and there's also a REPL for the process, as well as a list of loaded source files so you can set breakpoints through there if you like, as well as modify the files on the fly if you need something more for debugging.
It can be very useful, and works pretty much the same as the normal web devtools.
For example reference implementations of JSRs have very very rarely been usable/used in production.
I always expect the reference library to be optimized for correctness, formal proofing, brevity, simplicity and clarity, not (compilation nor execution) speed.