In certain scenarios—particularly with smaller applications—it can be beneficial to serve both the frontend and backend from a single service. Instead of deploying the frontend (e.g., an Angular application) and the backend (e.g., a REST API) on separate servers, a more efficient approach may be to consolidate them into a single, lightweight deployment. This strategy helps reduce infrastructure complexity and minimizes the application’s footprint.
Micronaut, with its fast startup time and minimal resource usage, pairs well with Angular for such use cases.
In this blog post, we’ll explore how to serve an Angular application directly from a Micronaut backend, creating a unified deployment that is simple, efficient, and well-suited for small to medium-sized projects.
Step 1: Setting Up the Micronaut app
Head over to Micronaut launch, just create a basic application
If we look into the dependency, its a basic minimal Micronaut app
plugins {
id("io.micronaut.application") version "4.5.4"
id("com.gradleup.shadow") version "8.3.7"
id("io.micronaut.aot") version "4.5.4"
}
version = "0.1"
group = "micronaut.angular"
repositories {
mavenCentral()
}
dependencies {
annotationProcessor("io.micronaut:micronaut-http-validation")
annotationProcessor("io.micronaut.serde:micronaut-serde-processor")
implementation("io.micronaut.serde:micronaut-serde-jackson")
compileOnly("io.micronaut:micronaut-http-client")
runtimeOnly("ch.qos.logback:logback-classic")
testImplementation("io.micronaut:micronaut-http-client")
}
application {
mainClass = "micronaut.angular.Application"
}
java {
sourceCompatibility = JavaVersion.toVersion("21")
targetCompatibility = JavaVersion.toVersion("21")
}
graalvmNative.toolchainDetection = false
micronaut {
runtime("netty")
testRuntime("junit5")
processing {
incremental(true)
annotations("micronaut.angular.*")
}
aot {
// Please review carefully the optimizations enabled below
// Check https://micronaut-projects.github.io/micronaut-aot/latest/guide/ for more details
optimizeServiceLoading = false
convertYamlToJava = false
precomputeOperations = true
cacheEnvironment = true
optimizeClassLoading = true
deduceEnvironment = true
optimizeNetty = true
replaceLogbackXml = true
}
}
tasks.named<io.micronaut.gradle.docker.NativeImageDockerfile>("dockerfileNative") {
jdkVersion = "21"
}
Now that our backend service is set up and ready, it's time to focus on the frontend. In this section, we'll set up an Angular application using the standard Angular CLI, which provides a streamlined and efficient way to scaffold and manage Angular projects.
Angular setup
- Install the Angular CLI
npm install -g @angular/cli
- Create a workspace and initial application
ng new ui
- We can select select any choice, however we will stick to SCSS.
We don't want SSR, our choice will be N
- The angular CLI will install few dependencies
- Once the dependencies are install, we can see the below project structure
cd new ui
- Run the application
ng serve --open
Enter the URL http://localhost:4200/ in the browser and we will the angular app is running
Development Workflow
During development, it's perfectly fine (and often preferable) to run Angular and Spring Boot as separate applications:
Angular CLI: Serves the frontend on http://localhost:4200 with hot-reload for fast development.
Micronaut: Runs the backend API on http://localhost:8080.
This separation allows for:
✔ Faster frontend iterations (thanks to Angular's live reload)
✔ Independent debugging of backend APIs
✔ Mock API responses during early development
The Production Challenge
In production, we typically want to serve both applications as a single unit for:
✔ Simplified deployment
✔ Reduced cross-origin issues (CORS)
✔ Better performance (serving static assets directly from the backend)
Configuring Angular to Deploy as Spring Boot Static Content for production
Understanding the Setup
By default, Angular builds to /dist/ui, but we need it to output directly to Spring Boot's static resources folder where it can be automatically served. Here's how to make this work seamlessly:
- Step 1: Modify Angular's Output Path
"architect": {
"build": {
"builder": "@angular-devkit/build-angular:application",
"options": {
"outputPath": "dist/ui",
},
}
}
Lets change the "outputPath": "dist/ui" to the Micronaut resource directory
"architect": {
"build": {
"builder": "@angular-devkit/build-angular:application",
"options": {
"outputPath": "../src/main/resources/static", // Changed from "dist/ui"
"index": "src/index.html",
// ... rest of your config
}
}
}
"outputPath": "../src/main/resources/static"
Since now the outputPath is pointing to the Micronaut resources, we can run angular CLI command to build the files, we must point to the root directory of the angular app in our case ui
- Step 2: Build and Verify
ng build --configuration production
We will see the below logs
ng build --configuration production
Initial chunk files | Names | Raw size | Estimated transfer size
main-3BERZHFR.js | main | 208.01 kB | 56.74 kB
polyfills-FFHMD2TL.js | polyfills | 34.52 kB | 11.28 kB
styles-5INURTSO.css | styles | 0 bytes | 0 bytes
| Initial total | 242.53 kB | 68.02 kB
Application bundle generation complete. [2.279 seconds]
Output location: /Users/san/project/Sample/AngularTest/src/main/resources/static
Notice the output location here Output location: /Users/san/project/Sample/AngularTest/src/main/resources/static. The files are been output the the Micronaut resources directory.
Run the Micronaut app, and head over to the browser http://localhost:8080 we will see there is no angular app.
If you have looked closely to the resources >> static directory
, there is browser directory is created by angular build command, and if we look into that directory we can see the index.html and .js file. For angular to work that needs to be on outside of the browser directory, because spring doesn't know anything about browser directory.
- Solution 1 - We can move those files outside of the browser Now, if we run our Micronaut app, and navigate to http://localhost:8080 we will see angular application
Well this works right, hmmmm not that effective
The problem with this solution is that we need to manually move the files, lets see how we can fix this.
Better Solution
"outputPath": {
"base": "../src/main/resources/static",
"browser": ""
},
"deleteOutputPath": false
Include browser ="" to generate file inside the static directory and don't delete other files by including "deleteOutputPath": false,. Now if we run the command ng build --configuration production we can see all the files are generated within static
Add a new component
ng g c Home // This will generate new Home Component
Include this component in the router section
import { Routes } from '@angular/router';
import {HomeComponent} from './home/home.component';
export const routes: Routes = [{ path: 'home', component: HomeComponent },];
For local development we can reply on ng server. The routing will work on http://localhost:4200/home
For Micronaut to include the router we need to build again
ng build --configuration production
If we navigate to http://localhost:8080/home we will face an issue as 404 not found
To fix this we have to do configuration SPA routing
@Controller("/")
public class SpaController {
@Inject
ResourceResolver res;
@Get("/{path:(?!.*\\.).*}")
@Produces(MediaType.TEXT_HTML)
public HttpResponse<?> refresh(@PathVariable String path) {
StreamedFile indexFile = new StreamedFile(res.getResource("classpath:public/index.html").get());
return HttpResponse.ok(indexFile);
}
}
Application.properties
micronaut.router.static-resources.default.enabled=true
micronaut.router.static-resources.default.mapping=/**
micronaut.router.static-resources.default.paths=classpath:public
Development vs Production Workflow
Now if we run the spring boot app and navigate to http://localhost:8080/home we will see our home component.
For development, configure Angular's proxy to avoid CORS issues:
// src/proxy.conf.json
{
"/api": {
"target": "http://localhost:8080",
"secure": false
}
}
Conclusion
The Best of Both Worlds
By configuring Angular to build directly into Micronaut static resources folder, we've created a powerful full-stack solution that:
✔ Simplifies Deployment - A single JAR contains both frontend and backend
✔ Improves Performance - Static assets are served efficiently by the embedded Tomcat server
✔ Maintains Flexibility - Keep separate dev servers during development while unifying for production
Top comments (0)