GraphQL is an amazing specification, no doubt about that. I loved it when it first came into my knowledge but as I started learning it, well, I started to hate it and I still do at some extent because I am still learning it. So much boilerplate code to even starting the graphQL server.
You essentially created something that behaves in a very similar way to GraphQL (single endpoint, commands), that has no known pattern applied and disadvantages over the well known and established technologies that already solved most of the problems. Bad idea.
Well you have your opinion.
According to me, setting up a graphql server for small applications is a waste of time and graphql is not for everyone. In my opinion, graphql is most useful for public facing apis, not internal. Internal apis dont need to have a structure because the teams can share a common documentation for that.
And as I said, graphql is very powerful and if you feel like you need everything that graphql provides, go ahead and use that. But if you are looking for a simpler solution, its here.
Appreciate you sharing your thoughts.