[exogen]

Sorry what class hierarchy are we talking about here? This seems like an extremely contrived application of SOLID.

(1) In what sense is my client making GraphQL queries depending on or tied to the available schema fields it does not query? Where's the coupling?

(2) I have a REST API that doesn't use PUT, PATCH, or DELETE. So I guess every REST API is not SOLID either, because it's using a general-purpose transport with features I'm not using?

(3) Does anyone care? I'm trying to make the best end-user and development experiences. GraphQL allows that. It's an improvement.

SOLID is some principals for one type of software (object oriented). Not the principles for all types of software.

[KirinDave]

You're trying to support a popular DSL and paying extra performance, engineering and architectural costs.

Why not move the wonderful experience client side and use service workers?

People talk a lot about one-query turnaround time, but for websites this is not nearly the same concern or gain that it is for, say, a mobile API. I'm a bit out of the mobile game this year, but AFAICT they aren't rushing to embrace gql.

[exogen]

Please, tell me more about how you’ve profiled both the performance of my apps and my development productivity! Amazing of you to provide this for me.

Meanwhile, NYTimes:

> “Facebook developed it to provide a data source that can evolve without breaking existing code and to favor speed on low-powered and low-quality mobile devices.”

[1] https://open.nytimes.com/react-relay-and-graphql-under-the-h...

[KirinDave]

> Please, tell me more about how you’ve profiled both the performance of my apps and my development productivity! Amazing of you to provide this for me.

Of course I haven't, but you haven't even begun to address the architectural concerns I've raised. You keep dismissing them without direct comment, then demanding I go further and further into the specifics of your unique use case to be allowed even a high level opinion.

I'm not telling you what to do. But I keep waiting for someone to tell me one good reason why I want to go back to a monolithic API dispatch. Please, tell me. Why should _I_ do this? Why don't you also worry about the architectural regression in your API here?

> Facebook

Facebook has haskell developers who actually have tools to write performant GraphQL servers. One of my big debates is if I want to finalize & make public some of my work to efficiently dispatch graphQL queries.

Haxl makes this entirely possible and other people have done proofs of concept as well. If I see an amazing benefit to finding time in my schedule to do this work, I will.

Of course, most folks won't use it. But we would, and that might be enough. But my other alternative is to do the exact same kind of work in the browser under service-workers. I don't really have many arguments against this other than "well you end up making the same # of queries as before so there's only minimal full query improvement."

But if i can combine a client-side gql dispatcher with http/2 push work (which inherently using query caching), it seems better. Again, lots of work in an ecosystem I'm not terribly fond of, but I can do it.

So please consider telling me what the actual benefits are and stop appealing to "developer experience" (I don't dispute this, I just can't make a decision based on it exclusively) and "faster queries" (because I think you lose at least as much performance as you gain and your API becomes a lot less predictable).