angular-node-java: one Angular front end over two interchangeable backends

The idea: one front end, two backends

The Angular 22 Fullstack Starter is described in one line as an Angular 22 starter application with Node.js and Spring Boot backends, and the stack table lists three projects.

The front end is Angular 22 in a directory called frontend-angular. The first back end is Node.js with TypeScript, in backend-node. The second is Java with Spring Boot, in backend-springboot.

Why two backends in one starter is the interesting question. The topic list gives the clue, with express and springboot both among the tags, alongside api-rest, ssr, pwa, typescript and docker. The pattern is a learning and demonstration setup: the same front end is wired to a JavaScript back end and to a Java back end, so a developer can see how the API contract looks from both sides, or port a service between the two without changing the UI.

The project has a live demo at angular.ganatan.com, linked from the README with an animated capture of it, and the repository is under the ganatan organisation, whose site also hosts step by step tutorials in French and English.

The repository itself is minimal at the top level, with a README, a .gitignore and the three project directories, and the primary language is listed as HTML, which reflects that the bulk of the tracked source is the Angular application.

The architecture and the directory layout

The README draws the architecture as a text diagram, and it is worth looking at because it states the relationship between the three projects in one screen.

frontend-angular
        |
        +-- backend-node
        |
        +-- backend-springboot

The front end sits above, and both back ends hang off it as alternatives. That matches the configuration model, where the front end has one setting that decides whether it talks to a backend API or uses mock data, and the Node back end has an environment variable that decides whether it serves mock data or a real database.

The project structure section lists the same three directories, and that is the whole repository layout.

frontend-angular/
backend-node/
backend-springboot/

So there is no shared library package, no monorepo tooling and no common configuration module across the three. Each is a standalone project with its own toolchain, the Angular one with npm and the Spring Boot one with Maven. That is a deliberate simplicity, and it also means the two back ends are coupled only by the shape of the HTTP API they expose.

That coupling is worth spelling out, because it is the contract you inherit if you adopt this. The front end talks to whatever is at the configured base URL, and both back ends are expected to answer the same routes. If you change one, you change the other.

Running the front end

The quick start is a clone, a move into the front end directory, an install and a start.

git clone https://github.com/ganatan/angular-node-java.git

cd frontend-angular

npm install

npm start

The application is then served on port 4200, which is the Angular development server default, and the README shows that URL as plain text after the commands.

The front end scripts section lists the rest of the workflow. Installation is npm install followed by npm outdated, which is a slightly unusual pairing but a sensible one for a starter, since it tells you immediately whether your dependency tree is current.

Development is npm start, production is npm run build, and there are separate scripts for the linter, for the tests and for coverage.

npm run lint

npm run test

npm run coverage

The presence of lint, test and coverage scripts is the signal about how the project expects to be used. This is a template with the tooling of a real application wired up, even if the data in it is sample data.

Mock data by default, and the switch that changes it

The configuration model is the heart of the starter, and it is deliberately small.

On the front end, the file is the environment file in the Angular source tree, and the example contents are two settings.

useDatabase: false,
backend: 'http://localhost:3000',

The first value decides between mock data and the backend API. With it false, the front end serves data from its own mock layer, so the application runs with no back end at all. With it true, it calls the API at the address in the second value.

That address, port 3000, is the Node back end. The Spring Boot back end runs on port 8080, so pointing the front end at the Java service means changing one line in the environment file.

The Node back end has the mirror image arrangement, configured through a .env file at its root.

PORT=3000
DB_CLIENT=mock

The first variable is the port. The second selects the data source, with mock meaning mock data, and pg meaning PostgreSQL or mysql meaning MySQL.

So there are two independent switches, which is what makes the four combinations possible: mock front end over mock back end, real front end over mock back end, mock front end over a real database, and the full stack. A tutorial that teaches API development can move through those combinations one at a time, and that is almost certainly the intent.

The two back ends and their toolchains

The Node back end is installed and run with npm, like the front end.

cd backend-node

npm install

npm start

It is then reachable on port 3000, and it has a production build script, npm run build, in the same way the Angular project does.

The Spring Boot back end uses Maven and runs on port 8080.

cd backend-springboot

mvn spring-boot:run

mvn clean package

The difference in toolchain is the point of the whole exercise. The Java side has no npm scripts at all in the README, because Maven owns the lifecycle, and the two commands are the ones you would expect from a Spring Boot project.

What the README does not tell you is as informative as what it does. There is no database schema, no migration tool, no authentication, no Docker Compose file and no deployment configuration. The Docker tag in the topic list suggests the project or its tutorials cover containers, but this README does not show it.

So the honest description is that this is a front end wired to two functioning but skeletal back ends, with the wiring and the configuration switches being the deliverable.

The sample API and what it exposes

The available APIs section is a short list of read only endpoints, and the shape of the data is what the demo shows.

GET /continents
GET /countries
GET /cities
GET /persons
GET /professions

Five GET routes covering a geography hierarchy, a list of people and a list of professions. There are no POST routes and no parameters shown, so the API is a fixed set of collection endpoints rather than a resource API with identifiers.

That is a deliberate simplification for a starter. It gives the front end something real to render, with enough relationships between the collections to show a table with joined data, and it gives a learner a backend that answers instantly with no setup.

It also sets the boundary. If you take this template for a real application, you inherit a five-route mock API and have to build the resource model, the persistence layer and the error handling yourself.

The tutorial site is where that work is presumably described. The README links the French and English tutorial indexes on ganatan.com, and the English one is listed under a separate heading, so the project is part of a larger body of training material rather than a standalone repository.

Maintenance, licensing and what to check

The maintenance picture is thin but not negative. The last push was on 2026-06-26, so the project is being touched, and the repository has no GitHub releases, which for a starter template is unremarkable since there is nothing to version beyond the code itself.

The licence is the open question. The repository listing does not classify it, and the README does not mention a licence file at the top level, unlike most projects of this kind. The top level contains the README, a .gitignore and the three project directories, so if a licence file exists it would be inside one of the projects. That is worth checking before you build on the template, and it is the kind of detail that costs a company an afternoon of legal review if it is missed.

The version numbers are the other thing to check. The front end is Angular 22 and the topic list also carries an angular20 tag, which suggests the template has moved forward across Angular major versions and that the upgrade path is something the maintainer handles rather than something you inherit.

Four checks before you adopt it. Confirm the licence. Confirm the sample API covers the shape of data your application needs, since there are only five collection endpoints to learn from. Confirm the database client you want to use is one the Node back end accepts, since the configuration names mock, pg and mysql and nothing else. And confirm that the tutorial material is in a language your team reads, because the primary tutorials are French and the English set is a separate index.

Editorial conclusion

angular-node-java is a useful starting point for a team that wants to see a front end talking to a real API before it commits to a backend stack, because both backends implement the same endpoints and the switch is one configuration value, so you can compare the two without rewriting anything. It is the wrong choice for a production starting point, since the sample data is mock and the licence is not stated, and the wrong choice if you need authentication, migrations or deployment configuration, none of which the project documents. Verify first that the endpoints your UI needs exist in the sample API, that the database client you intend to use is one of the ones the configuration accepts, and that the licence situation is acceptable before you build on the template.

Frequently asked questions

Official sources

1. ganatan/angular-node-java on GitHub
2. Issues
3. README