That's basically it, except in most shops, the controller is this middle ground. It's on the back end, but the back end engineers can't really do the job on their own, so the front end developers end up writing the controllers, calling out to services that are written by the people who are actively implementing the business logic. In most cases, there are really four layers rather than three, and the two groups handle two layers each.
Moving to a service oriented architecture where the two groups communicate by REST seems like it would work just as well in most situations, and this was the point.
That's part of what I was wondering about. In the classic MVC sense, we're turned the Controller into a distributed system with a footprint both on client and server.
It's closer to a MCVMV or model, controller, view-model, view. Which is close to a MVVM pattern but adds a controller in. In my view the model is back-end, controller is mostly backend (processes the api requests and return the model data or the correct data value to the client), View-Model (grabs data via the model api and loads it into a model class on the client, this model class may or may not be the same structure as the server model, usually mapped to an/multiple api end point(s)), and View is the actual client side presentation.
That's how I tend to think of the pattern, it's not really MVC anymore it's a new pattern that is evolving out of MVC.
Moving to a service oriented architecture where the two groups communicate by REST seems like it would work just as well in most situations, and this was the point.