I've come to believe that the "right" way to do things now is alternating smart / dumb layers. If you have two smart layers adjacent to each other (and GraphQL

I've come to believe that the "right" way to do things now is alternating smart / dumb layers. If you have two smart layers adjacent to each other (and GraphQL is a smart layer) then the interconnection between the two and the conflicting abstractions of data becomes an issue. By having something dumb (REST endpoints) between the business layer and the complexity of the front end, it is possible to have reasonable abstractions writing to the REST endpoints and an abstraction of the payloads that the endpoints provide into what is needed in the front end application. It seems that GraphQL works best when the backend has minimal business logic and the thing that is calling GraphQL likewise has minimal logic -- and all the logic is contained in the GraphQL query itself. But if you're finding complexity in getting things into GraphQL and manage permissions and mutations... or you've got the complexity of the front end where the data model the front end needs to work with doesn't align with the GraphQL model ... then you've got complex solutions abutting each other and those spots is where the pain will be found.