Not sure why you are getting downvoted. The person actually states that they don't know how to debug, "honestly, I'm not 100% sure the best way to debug from here." They are just looking at Datadog stats and not finding the root cause. They could do some basic JS debugging of the open source library to figure out the issue. Blaming Apollo would be a stretch (which may not even be the issue since they haven't done any debugging), but the protocol of graphql is way too far.

> Not sure why you are getting downvoted.

I don't know why anyone downvotes as they do, but the previous post is an irrelevant argument about semantics, so in my opinion it deserves to be downvoted.

Actually, now that I think of it, it's a little worse than that. The OP is being criticized for not understanding how to debug or improve the performance of their dependency while actively engaged in figuring out how to debug and improve the performance of their dependency. (People respond with questions, OP provides substantive answers, there's a back-and-forth and OP forms an idea it's related to a deeply nested schema, and so on.)

> The OP is being criticized for not understanding how to debug or improve the performance of their dependency…

Nothing I said is a critique of Ben Awad, the Twitter OP. I assume we've all used dependencies that we don't completely understand, no?

To rephrase my point: The dark side of semi-opaque dependencies like ORMs, application frameworks, etc. is that when the magic doesn't work, one may not be able to easily determine where to start in order to address issues.

EDIT: Removed unnecessary paragaph to simplify response.

The person who wrote the “creative” title here on HN for the Twitter url they submitted is not the same person having the issue with performance and posting for help on Twitter.

Ben Awad is pretty knowledgable in graphql. He is one of the most solid youtube tutorial guys on it.

Having youtube tutorials on something does not make you an expert on the subject. He appears to not have the skills to do basic JS debugging. It's great to ask for help, everyone needs help at some point. The issue I see is starting with "The dark side of GraphQL". If you haven't found the actual issue, how do you even know what the cause is? Just because your SQL query is fast doesn't mean there is some inherent problem in GraphQL or Apollo. That argument doesn't follow. It could be user error.

I don't mean to sound like a blind witness fanboy, but I think teaching something effectively does require some mastery of the subject.

I also don't think it is hyperbolic say he doesn't have basic debugging skills. What qualifies as basic debugging skills? Like he isn't capable of using a debugger and introspecting code? He can't use a print statement and look at code? Debugging an E2E bottleneck is not trivial.

I have no doubt. The unfortunate bit is that his tweet uses "GraphQL" to refer to a specific implementation (Apollo Server) of GraphQL rather than GraphQL itself.

But Apollo Server is by far the most common implementation of GraphQL servers, and the OP's thesis based on the twitter thread is that type-checking and validation are responsible for the slowdown, and type-checking and validation are inherent to GraphQL.

It would be like posting "The dark side of SQL" for a slow MySQL query

But there are dark sides to using sql, often from the abstraction that sql provides.

Maybe the optimizer picks a poor plan and you can't figure out how to make it work better. Maybe the schema has redundancy you can't change or the indexes aren't suitable for that query. Maybe it's auto parameterizing constants and the query with the problem has a parameter causing different behavior than the original constant used in optimizing the query, or maybe your query with 1000 elements in an in list worked great in memsql or whatever but is slow unexpectedly in the database you ported your app to. There are downsides to everything.