A lot of large organizations have a settled shape: Java on the server, JavaScript in the browser, and a front-end team somewhere in between, wondering how much of the middle it is allowed to own. I have spent most of my career on the front-end side of that shape, and I have come to a fairly specific view of where Node.js fits in it.
The job: own the layer closest to the browser
I think Node.js has one clear job in a Java organization, which is to own everything from the browser back to the first service boundary. That includes three things.
Server rendering. Modern front-end frameworks render on the server by default, and they render in JavaScript, so the process doing the rendering is a Node process. There is no reasonable way to render a React or Angular page from a Java service, and nobody should try.
Build tooling. Bundling, type checking, linting, testing, the whole pipeline that turns a front-end codebase into something a browser can run is a Node toolchain. It already runs in every front-end engineer's editor. Running it in the pipeline is the same thing.
The layer that shapes services for pages. A page typically needs data from several Java services, in a shape none of them returns. Somewhere that shaping has to happen. I think it belongs in a thin Node layer the front-end team owns, often called a backend for frontend, because the people who know what the page needs are the people who built the page, and they should not have to open a ticket against a Java team to change a field.
Where it earns its place
The argument for this layer is about ownership, not technology. When the front-end team owns the layer that feeds its pages, a change to a page is one team's work from start to finish. When it does not, every page change becomes a negotiation between two teams with two backlogs, and the front end spends its time waiting.
The second argument is that the layer is small. It aggregates, it reshapes, it caches a little, it handles the session. It holds no business rules. A thin layer with no business rules is something a front-end team can own well, in a language it already knows, with the same test and build tools it uses for everything else.
Where I would not take it
I would not use Node to rewrite the Java services, and I would be suspicious of a front-end team that wanted to. The services hold the business logic, the data access, the integrations, and years of knowledge about how the business actually works. Java is good at that job. The organization has the people and operations for it. A front-end team that reimplements a service in Node has taken on a job it is not staffed for, in exchange for avoiding a conversation.
I would also keep business rules out of the Node layer even when it is tempting. The moment a rule lives in the layer between the browser and the services, there are two places the rule can be, and eventually it is in both, differently.
The line
So the line I draw is this: Node.js owns rendering, tooling, and the shaping of services into pages. Java owns the services. The front-end team owns its side completely, and the boundary between the two is an interface both teams agree on and neither crosses.
I think teams on both sides are happier with that line than without it. The front end stops waiting. The Java teams stop fielding requests to add a field for one page. And the organization gets a front-end team that can ship on its own, which is what it wanted when it hired one.
Photo source: https://photos.robertstowe.com/wieliczka-salt-mine