| > 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). |