Thanks a lot for the feedback. db-view definitely have a few things in common with GraphQL. Most notably that the client tells the server, what parts it likes to receive and that all of them are returned in a single response. GraphQL is great, if you have a segregation between frontend and backend teams. It offers the frontend team a kind of self-service, since they now have a query language, similar (but less powerful) like a backend developer has SQL for the database. But providing an API with a query language like GraphQL is a significant effort.
If you are the developer who programs both, the frontend and the backend, you don’t need this kind of client-side query language, you can simply write your queries on the server-side. There are less options for an attacker to mess with your API. For example GraphQL APIs often uses a query hash to only allow predefined queries, since it is difficult to fully ensure that the API user does not traverse the graph to nodes which he is not allowed to read. Last but not least the whole GraphQL package weighs a lot, not only in terms of code / lib size, it also takes a while to learn all its details (its type system, the syntax of the query language etc.). The db-view approach doesn’t really require a dedicated lib, since you need so less code, every required part is included in the small example app: https://github.com/maxweber/todomvc-db-view
While GraphQL uses mutations to cause side-effects on the server, db-view has its command concept. Unique to db-view is that it even moves the creation of commands to the read part (or the “pure” / side-effect-free part, if you think of it from a functional programming perspective). If an user should not be allowed to delete a todo item, you just do not include the corresponding (encrypted) command in the response. Normally your “mutations” API endpoint intertwines the side-effect and the validation. Since it either performs the side-effect or response with a validation error. With db-view for example you provide the text for a new todo item in the db-view request and receive either a command or a validation error in the response. But performing the side-effect that is described by the command is a separate step.