I'll have to give this a read. Many of these technologies (GraphQL) seem like layers on top of layers. Really, I just want a page with 3 fields specific to tha

I'll have to give this a read. Many of these technologies (GraphQL) seem like layers on top of layers. Really, I just want a page with 3 fields specific to that page. They may come from 3 different tables. GraphQL's original solution to this was to batch the request to 3 different resources, but the underlying problem was still there. Of course, you can make ad-hoc GraphQL equivalents to a random REST ad-hoc /api/get-info-for-my-profile-page/. The problem becomes especially noticeable when you want to update nested resources. Say, a profile's subscription status. Instead, in "MVC" world, I would just bump up the subscription status to be a first class field on that view. So no profile->subscription->status. Just "subscription_status". Hope that makes sense. So far, I've reverted to using Django Forms (across tables) and breaking them down to JSON to use them in a SPA. My endpoints are still very much domain specific, but I can use XHR/fetch to make the page interactive.