Thanks for the great comment. I often see GraphQL get a bad rap in comments on this site but most of the time it seems to come from a misunderstanding of how to use it.
How you model the data at rest does not need to match the GraphQL specification. The GraphQL specification should be similar to your REST entities but they have traversable edges to other entities.
Of course, you are building something that is much more powerful. If you intend every possible GraphQL operation to perform perfectly, it'll take more development effort. Though if you optimize for only the most likely cases, the effort is not much greater.
Generally speaking, it's not more difficult than creating a REST API controller. Rather than mapping your service code to a controller, you map it to a (GraphQL) resolver. It feels extremely similar.
I've found GraphQL to greatly improve the developer experience when building web apps. As a front-end developer you can easily get a full view of the data and relationships. Tools like GraphiQL make exploring APIs a pleasure. And regardless of what you need to present to the user on screen, you can quickly build a request that perfectly matches the data you need. There is also the nice addition of strict typing and there are libraries that automatically generate TypeScript types for you from the schema and/or your operations.
Let me look into what effort it would take to clean up the code and put it on Github. I'd be happy if it helped others starting a project. It heavily utilizes ReSwift and SnapKit, two libraries I wanted to gain some more experience with.