This means Rails and Angular are doing the same job - the main difference is where data keeping and rendering is done.
You can certainly make distinctions between those data stores, but they have enough in common it's perfectly reasonable to say they're doing many of the same things.
Now, Angular is considerably more horrible than Rails and tries to solve some additional front end problems badly, and its use is a likely indicator that the organization or individual that have decided to employ it aren't capable of making wise technical decisions, so I'd say it's also reasonable to make distinctions between the two on a number of levels. But there's considerable overlap in the kinds of problems they attempt to solve.
Think about these questions: is Rails really "behind" everything involved in a typical web application request/response cycle? Or is there something else behind it? In what situations is Rails not a client? For the situations where it isn't... how common is that setup, and which situations could Angular not cover?
(There's a few, but I suspect they're vanishingly rare.)
You may not have been doing this long enough to remember, but there was a time when "front-end" meant something different than it does now, reasonably so, and there's still some circles where people use it to invoke the layer of an application that generates HTML in back of an HTTP server because of what it's in front of.
> Equating Rails data store backend to Angular's service backend is a poor analogy.
In both cases, you have a given runtime opening up a socket connection through which some protocol exchange negotiates a request-response sequence to a server which provides some representation of application data. What, specifically, is the "poor analogy"?
Sure, everybody understands that the runtime in question is different and execution takes place in different environments. And like I said in my earlier comment, you can make distinctions between types of data stores (though given how common JSON responses are these days, most database developers seem to be working really hard to minimize those distinctions). You can make (some) distinctions between the demands of a multi-request environment and a browser's (likely) single user environment. It doesn't change the fact that there's a reasonable level of consideration at which Angular and Rails are doing the same thing: mapping view actions to controllers, running control code to update/retrieve model state including hitting data sources over the network, and updating the view. An analog doesn't have to be perfectly isomorphic in order to be useful or true.
Now if you really want enlightenment, ask yourself what problems the application of those patterns is meant to solve, and how effective Rails and Angular are at solving them. Also, what parts of the system are "in front" of the browser?
Or don't, I guess, and insist that labels like front-end and back-end represent disparate iron clad categories of platonic computing ideals with an insuperable gulf betwixt.
Does that mean I'm trying to put a stake in the ground on the canonical definitions of front-end vs backend? Hell no, it's totally relative, I'm only commenting within the context of Angular vs Rails so don't read too much into it.
Even today not everybody uses SPAs. Lots of big old school websites generated dynamically on server. Many Django and Rails projects built that way. Also lots of legacy Java stuff and PHP websites (all Wordpress and Drupal sites out there for example, and there are millions).
I don't see how there's considerable overlap here?