So let’s agree client side and client are not the same thing here. Middleware is NOT on the client side, as it can’t be for security reasons. As you stated, your CTO wants to add plugins / adapters (actually on the database level), for analytics and custom algos, which will be great. So no point in hashing that out.
All I ask for is the same features as neo4j and postgres. Nothing more. We are 80-90% almost there. My arguments have mainly been about security, then queries. Your CTO wants to add things like unique IDs and other constraints on the Database level up, which I think is amazing. I don’t think we are arguing there either.
So this is only partly true. You bet your butt I have read all of them. The problem here is the fundamental misunderstanding of GraphQL. DQL (even as GraphQL+) was already very similar to GraphQL, but it isn’t GraphQL. People wanted it to be GraphQL because it almost was. With GraphQl comes standardizations that people know, and MOST IMPORTANTLY, security. I think both devs here and users have been ignorant of the usefulness of GraphQL. We both agree it is just not flexible enough to be a query language. In fact, GraphQL is NOT a query language. It is an API. The specs simply do not support the kind of queries we want in DQL. It was created by Facebook to replace multiple REST API points so you code less. They MUST be secure, and in fact, ARE middleware.
So, let’s agree we need to have our GraphQL API middleware layer more secure. Some of the security like constraints and keys can be written on the database level up. In order for us to use the GraphQL API Dgraph already has, it needs to be more flexible as well, or we should get rid of it. It needs better queries and standardized mutations (nested filters, deep mutations, etc). I think we both agree it will never replace DQL, nor do we want it to.
J