It is server-based and topologically similar to a caching strategy.
A purist might disagree, but an argument can be made that it is perfectly fine to use any sort of caching strategy (e.g. etherscan) subject to a few conditions.
Users should be able to verify results independently, if they want to. This implies transparency. The cache should emit transaction hashes, addresses, etc. that users will need if they want to verify query results. If there will be service or API that emits facts about the blockchain, it should take care that all of its claims are auditable.
From a user perspective, it shouldn't make any difference which valid copy of the cache is used. If the app backend is operating without reintroduction of centralized privilege then it should be theoretically possible for a user to stand up their own local cache and use that, if they want to. The app design should allow that, so take care to avoid subconsciously reintroducing dependency.
In my opinion, an app developer will want to take care to accommodate alternative deployment scenarios if they wish to claim that the potential for application decentralization isn't compromised by their implementation decisions. If the app is said to be decentralized, then prove there are no centralized dependencies at the application level.
In my opinion, one can use something like Graph as a backing data layer and still enable decentralization, provided there is a clear path to using the system without reliance on the offered server(s). It may be advantageous to create a business model that incentivizes third parties to stand up nodes and compete. In this way, the original app architect can demonstrate that the system doesn't depend on business continuity. Food for thought.
If there's going to be a server, a user can consider if that server is a necessity or a convenience.
Hope it helps.
