Software engineering is always a series of trade-offs. You have to give up something to get something else. The unfortunate reality is that we don't always have a full picture of what the impacts are on our system when we start. You've mentioned many principles here, so it makes sense to summarize the idea behind it.
Don't Repeat Yourself (DRY)
Bottom line is that if you need to change they way an application behaves, you should know the one place you need to go and fix it there. That's the general idea at least. If you've ever maintained legacy code, you'll find all kinds of duplication which means you need to fix things in multiple places.
There's a limit to where DRY is useful. Sometimes you have to repeat yourself for real reasons that may be out of your control, or dictated by another pattern that addresses a different problem.
Command/Query Responsibility Separation (CQRS)
This is something that can be overused, but it is necessary in some situations. Let's take the idea of blog hosting software. In this situation, the number of reads will vastly outnumber the updates (ideally, at least). By separating the responsibility of finding and reading blog entries from creating them or managing them, you can scale those responsibilities separately.
It's also common for some updates to be very focused. For example, external systems updating status, etc. The command responsibility does not have to look exactly like the query response. It does increase complexity, so make sure the complexity is worth it.
GraphQL
GraphQL is a tool to map data form disparate sources and massage it into the size and shape the downstream system asked for. GraphQL is it's own language. The queries and responses vaguely resemble JSON, but they wouldn't be valid JSON objects. As such there will always be a translation issue there.
The killer feature of GraphQL is that it allows you to minimize the chattiness with your client over the WAN, while you can federate to different services inside your system boundaries where bandwidth is much more open.
When things don't line up
It's common for the response object from a rest service not to map directly to the schema for GraphQL. The truth is that they have different languages, so you can't share common code. Additionally, your REST service might be implemented in another language from the GraphQL layer.
Every time you transition between languages, you lose the opportunity to reuse objects. Adding support for a new field does require changes to every step in the chain that represents that object.
For small systems with limited needs to scale, you can argue that the complexity you gained from this process is overkill. You'd also probably be right. However, for large systems with a lot of traffic, that complexity is not only warranted, it is needed.
Think about it this way, with a heterogeneous microservices architecture where nothing is shared between services, you gain some modularity and freedom you wouldn't have otherwise. That allows the team that has to support the new field to ramp up and implement it correctly before the rest of your system is ready to consume that new field. As each system now starts making use of it, you have the opportunity to fix integration problems before making it public through GraphQL.
Bottom Line
Always re-evaluate what you are doing as you progress.
- What are my pain points, and is there anything I can do about them?
- Is the general approach good, necessary, or correct for your application?
- Are there things I can do to minimize the pain without sacrificing the good?
Even if you feel like you went down the wrong path entirely, it always helps to understand how you got to where you are. Those choices you took need to inform your new choices, particularly the pain introduced by those choices.
Sometimes there just aren't any elegant answers. At least, not yet. It takes some time looking at the problems you are trying to solve and playing the "what if?" game to start to figure out ways of taming the beast you've created. That's OK. Software development is also a team endeavor. Someone on your team who is familiar with your domain may have a breakthrough idea to fix it.
