I began researching graph databases and have hit a wall, hopefully someone can bring up a point I have not considered.
I wanted to build my application using GraphQL as it's simple to use and I love it's flexibility. It works well with microservice architecture and while it has it's pitfalls I prefer it over REST. For the database, I assumed a graph database would be a naturally good fit. As a client might traverse several entities/nodes it would be far easier to use a graph database, which is built with traversals as the key motivator. It's highly flexible and efficient.
Unfortunately, my issue is that while graphql with a graph db would work well for a monolith app, it wouldn't work well with Microservices (MS) unless I'm missing something.
For MS you want to restrict your database access per service, either via schema, tables or entire db. This allows separation of concerns and follows best coding practices, isolating business logic. This essentially limits very quickly the traversals across entities which in turn limits the optimisations offered by a graph database. For example, a request to read or write across multiple domains could be done in a graph database in one query easily. For write, I have no issue separating as there's often a considerable amount of business logic for each domain. However for a read, it's often just a permission check. The entire point of using a graph database is to map data that's graph-related, but by separating concerns you get very small graphs that at least for my app, would be near useless. The power is lost.
The separation of concerns is far more important than speed, however I would like to know whether a CQRS adoption would bring back the power of the graph. By providing MS architecture for writes, but one single endpoint for reads, the gains are kept. By this I mean not even the services themselves do reads - everything uses the one endpoint (ideally replicated behind a load balancer). I am wondering what the pitfalls here would be with regards a) deployments: would there be breaking changes across the read & write? I'm thinking it's possible but unlikely if reads are exclusive to the single endpoint b) development experience - would this end up being a pain?
Is there something I have not yet considered, or are graph databases more suited for second-tier ops where they are loaded with data to answer specific questions but not the first-level data store?