Quick summary: How I built a production-grade full-stack app with ultra-fast startup and superior memory efficiency (20.72MiB backend + 2.625MiB frontend = ~23MiB total at startup) using Quarkus Native Image - 58% better than Spring Boot Native!
🚀 The Problem: Slow Java Application Startup
Traditional Java applications are notorious for their slow startup times. A typical Java application can take 3-5 seconds to start, which becomes a significant bottleneck in:
- Microservices architectures where you need rapid scaling
- Serverless environments where cold starts matter
- Development workflows where you restart frequently
- Cloud deployments where startup time affects user experience
💡 The Solution: Quarkus + GraalVM Native Image
Enter Quarkus - the Supersonic Subatomic Java framework designed for cloud-native applications, combined with GraalVM Native Image - a technology that compiles Java applications ahead-of-time into native executables. The results are astonishing:
- Startup time: ~47ms vs ~3-5 seconds
- Memory footprint: 20.72MiB backend at startup (58% less than Spring Boot Native's 50MiB!)
- Frontend efficiency: 2.625MiB with nginx at startup (vs 15.89 MiB with Node.js Alpine + http-server)
- Total application: ~23MiB at startup (excluding database)
- Instant scaling: Perfect for cloud-native applications
- Developer experience: Hot reload in development, optimized for production
🏗️ Project Architecture
I built a complete user management system with the following stack:
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Angular 20+ │ │ Quarkus 3 │ │ MariaDB │
│ Frontend │◄──►│ Native Image │◄──►│ Database │
│ (Port 4200) │ │ (Port 8080) │ │ (Port 3306) │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Technology Stack:
- Backend: Quarkus 3.15.1 + Java 21 + GraalVM Native Image
- Frontend: Angular 20.3.0 + TypeScript + Server-Side Rendering
- Database: MariaDB with Hibernate ORM Panache
- Containerization: Docker + Docker Compose
- API Documentation: OpenAPI 3.0 / Swagger UI
🔧 Implementation Deep Dive
1. Backend Setup with Native Image Support
Quarkus makes native compilation incredibly straightforward. I configured the Maven project with native support:
<properties>
<quarkus.platform.version>3.15.1</quarkus.platform.version>
<maven.compiler.release>21</maven.compiler.release>
</properties>
<profiles>
<profile>
<id>native</id>
<properties>
<quarkus.native.enabled>true</quarkus.native.enabled>
<quarkus.native.container-build>true</quarkus.native.container-build>
<quarkus.container-image.build>true</quarkus.container-image.build>
</properties>
</profile>
</profiles>
2. User Entity with Panache
Quarkus Panache makes data access incredibly simple. No need for repositories - the entity itself provides all CRUD operations:
@Entity
public class User extends PanacheEntity {
@Column(nullable = false)
public String name;
@Column(nullable = false, unique = true)
public String email;
}
That's it! No getters, setters, or repository interface needed. Panache provides all the methods like User.listAll(), User.findById(), user.persist(), etc.
3. REST API Resource (JAX-RS)
The REST API uses JAX-RS with Quarkus's RESTEasy Reactive for optimal performance:
@Path("/api/users")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class UserResource {
@GET
public List<User> all() {
return User.listAll();
}
@GET
@Path("/{id}")
public User byId(@PathParam("id") Long id) {
User u = User.findById(id);
if (u == null) throw new NotFoundException();
return u;
}
@POST
@Transactional
public User create(User dto) {
if (User.find("email", dto.email).firstResult() != null) {
throw new BadRequestException("User with email already exists");
}
dto.persist();
return dto;
}
@PUT
@Path("/{id}")
@Transactional
public User update(@PathParam("id") Long id, User dto) {
User u = User.findById(id);
if (u == null) throw new NotFoundException();
u.name = dto.name;
u.email = dto.email;
return u;
}
@DELETE
@Path("/{id}")
@Transactional
public void delete(@PathParam("id") Long id) {
if (!User.deleteById(id)) throw new NotFoundException();
}
}
4. Angular Frontend with Modern Architecture
I used Angular 20's standalone components for a modern, lightweight approach:
@Component({
selector: 'app-root',
standalone: true,
imports: [UserListComponent],
templateUrl: './app.html',
styleUrl: './app.css'
})
export class App {
title = 'User Management Application';
}
5. Service Layer for API Communication
@Injectable({
providedIn: 'root'
})
export class UserService {
private apiUrl = 'http://localhost:8080/api/users';
constructor(private http: HttpClient) { }
getAllUsers(): Observable<User[]> {
return this.http.get<User[]>(this.apiUrl);
}
createUser(user: UserRequest): Observable<User> {
return this.http.post<User>(this.apiUrl, user);
}
// Additional CRUD operations...
}
📊 Performance Results
The performance improvements were dramatic, and when compared to Spring Boot Native, Quarkus shows even better resource efficiency:
Performance Comparison (Native Images):
-
Startup Time:
- Traditional JVM: 3.2 seconds
- Spring Boot Native: ~50ms
- Quarkus Native: ~47ms
- Quarkus Advantage: Comparable startup, but simpler configuration
-
Memory Usage (Backend):
- Traditional JVM: 245 MB
- Spring Boot Native: 50 MiB (at startup)
- Quarkus Native: 20.72 MiB (at startup), 28 MiB (under load)
- Quarkus Advantage: 58% less at startup, 44% less under load compared to Spring Boot Native!
-
First Request:
- Traditional JVM: 4.1 seconds
- Native Images: ~89ms
- Improvement: 97.8% faster
-
Cold Start:
- Traditional JVM: 5.2 seconds
- Native Images: ~67ms
- Improvement: 98.7% faster
🐳 Real Docker Performance Metrics
Here are the actual production Docker stats from our running Quarkus Native full-stack application:
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
5facbc5751f3 quarkus-app 0.00% 20.72MiB / 64MiB 32.37% 4.79kB / 5.31kB 0B / 0B 13
4ba659835ac3 quarkus-frontend 0.00% 2.625MiB / 7.604GiB 0.03% 746B / 0B 0B / 0B 2
c1beedaca839 quarkus-mariadb 1.51% 131.4MiB / 7.604GiB 1.69% 6.88kB / 4kB 0B / 0B 10
Key Observations - Why Quarkus Excels:
Backend Performance (quarkus-app):
- Memory Usage at startup: 20.72 MiB - 58% better than Spring Boot Native (which uses 50 MiB)!
- Memory Usage under load (when creating a user): 28 MiB - Still 44% better than Spring Boot Native!
- CPU Usage: 0.00% - virtually idle, extremely low resource consumption
- Memory Efficiency: Uses only 32.37% of allocated 64MB limit at startup, ~44% under load (leaving plenty of headroom)
- Process Count: Just 13 processes - minimal overhead
- Network I/O: Minimal network activity (4.79kB/5.31kB)
Frontend Performance (nginx):
- Memory Usage at startup: 2.625 MiB - This is the power of serving Angular with nginx
- CPU Usage: 0.00% - virtually idle
- Process Count: Just 2 processes - ultra-lightweight
- Compare this to a Node.js server (Alpine with http-server) which uses 15.89 MiB for serving the same Angular app - that's 6x more memory!
Full Stack Total:
- Backend (Quarkus): 20.72 MiB
- Frontend (nginx): 2.625 MiB
- Total Application: ~23 MiB (excluding database)
- vs Spring Boot Native: ~50 MiB backend alone
This real-world data confirms that Quarkus Native Image not only matches Spring Boot Native performance but actually uses 58% less memory at startup and 44% less under load - making it the superior choice for resource-constrained environments and cloud-native deployments.
Memory Growth Analysis:
- Startup: 20.72 MiB (idle state)
- Under load (creating users): 28 MiB (active processing)
- Memory increase: Only ~7.3 MiB increase during active operations
- Still below Spring Boot: Even under load, Quarkus uses 22 MiB less than Spring Boot Native's baseline
🐳 Docker Deployment
I containerized the entire application for easy deployment:
services:
mariadb:
image: mariadb:12
environment:
MYSQL_DATABASE: userdb
MYSQL_USER: appuser
MYSQL_PASSWORD: apppassword
ports:
- "3306:3306"
app:
image: quarkus-native-users:latest
depends_on:
mariadb:
condition: service_healthy
environment:
QUARKUS_DATASOURCE_JDBC_URL: jdbc:mariadb://mariadb:3306/userdb
QUARKUS_DATASOURCE_USERNAME: appuser
QUARKUS_DATASOURCE_PASSWORD: apppassword
ports:
- "8080:8080"
frontend:
build:
context: ./front
dockerfile: Dockerfile
ports:
- "4200:80"
depends_on:
- app
environment:
- API_URL=http://app:8080
🚀 Building and Running
Backend (Native Image)
Quarkus makes building native images straightforward:
# Development mode with hot reload
cd quarkus
./mvnw quarkus:dev
# Build native executable
./mvnw clean package -Pnative -Dquarkus.native.container-build=true
# Build native Docker image directly
./mvnw clean package -Pnative -Dquarkus.native.container-build=true -Dquarkus.container-image.build=true -Dquarkus.container-image.name=quarkus-native-users -Dquarkus.container-image.tag=latest
Run Full Stack with Docker Compose
# First, build the native Docker image
cd quarkus
./mvnw -Pnative -Dquarkus.native.container-build=true -Dquarkus.container-image.build=true -Dquarkus.container-image.name=quarkus-native-users -Dquarkus.container-image.tag=latest clean package
# Then start all services
cd ..
docker-compose up -d
Frontend
cd front
npm install
npm start
💡 Pro Tip: Use nginx instead of Node.js for production frontend serving
For production deployments, use nginx to serve your Angular build instead of running a Node.js server. Even when using Node.js with Alpine base image and http-server (the smallest Node.js option), nginx is significantly more efficient:
# front/Dockerfile
# Build stage
FROM node:20-alpine AS build
WORKDIR /app
# Install dependencies
COPY package*.json ./
RUN npm ci
# Build application
COPY . .
RUN npm run build
# Production stage
FROM nginx:alpine
# Copy Angular build and nginx config
COPY --from=build /app/dist/user-management/browser /usr/share/nginx/html
COPY nginx.conf /etc/nginx/nginx.conf
# Handle Angular's CSR (Client-Side Rendering) build output
# Angular generates index.csr.html for CSR builds, but nginx expects index.html
RUN if [ -f /usr/share/nginx/html/index.csr.html ]; then \
cp /usr/share/nginx/html/index.csr.html /usr/share/nginx/html/index.html; \
fi
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
Nginx.conf:
# front/nginx.conf
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
sendfile on;
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml text/javascript;
server {
listen 80;
server_name localhost;
root /usr/share/nginx/html;
index index.html;
# Proxy API requests to backend
location /api/ {
proxy_pass http://app:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
# Angular routing - serve index.html for all routes
location / {
try_files $uri $uri/ /index.html;
}
# Cache static assets
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
}
}
Benefits of nginx (Proven with Real Data):
We built both versions to compare (Node.js uses Alpine base image with http-server for fair comparison):
| Metric | nginx | Node.js (Alpine + http-server) | Advantage |
|---|---|---|---|
| Image Size | 53.2 MB | 141 MB | 62% smaller |
| Memory Usage | 2.625 MiB | 15.89 MiB | 83% less memory |
| CPU Usage | 0.00% | 0.00% | Comparable |
| Process Count | 2 processes | 20+ processes | Minimal overhead |
Key Benefits:
- Smaller image size: 53.2 MB vs 141 MB for Node.js (Alpine + http-server) - Even with Alpine base, nginx is 62% smaller!
- Tiny memory footprint: Only 2.625 MiB (vs 15.89 MiB for Node.js Alpine - 6x less!)
- Ultra-low CPU: 0.00% usage - virtually idle
- Better performance: Optimized for serving static files
- Production-ready: Built for high-traffic scenarios
- Process efficiency: Just 2 processes vs 20+ for Node.js
This gives you a fully containerized full-stack application with:
- Backend: Quarkus Native Image (port 8080)
- Database: MariaDB (port 3306)
- Frontend: Angular served by nginx (port 4200)
🔍 Key Learnings and Challenges
1. Native Image Compilation with Quarkus
- Simplified Configuration: Quarkus handles most native image configuration automatically
- Panache Simplification: Active Record pattern eliminates boilerplate code
- Build Time: Native compilation takes 5-10 minutes but produces optimal results
-
Hot Reload: Development mode (
quarkus:dev) provides instant feedback - Container Builds: Using container builds avoids local GraalVM installation
2. Quarkus-Specific Advantages
- Zero Configuration: Most things work out of the box
- Panache Magic: Active Record pattern reduces code significantly
- Reactive First: RESTEasy Reactive provides excellent performance
- Build-time Optimizations: Quarkus optimizes at build time, not runtime
- Dev Mode: Hot reload works perfectly with native compilation support
3. Docker Optimization Discoveries
- Multi-stage builds essential for production-ready images
- nginx vs Node.js (Alpine + http-server): 53.2MB vs 141MB image size difference (62% smaller)
- Alpine Linux base images for minimal footprint
- Health checks crucial for container orchestration
- Environment variables for configuration management
4. Performance Insights
- Startup time: ~47ms for Quarkus native (vs 3-5 seconds traditional JVM)
- Memory usage: ~23 MiB total footprint at startup (vs 200MB+ traditional)
- Container overhead: Docker adds minimal overhead with native images
- Database connection: MariaDB connection pooling optimized automatically by Quarkus
5. Best Practices Discovered
- Start with Quarkus from the beginning - it's designed for native
- Use Panache for simpler data access patterns
- Leverage Quarkus dev mode for rapid development
- Test native compilation early in the development cycle
- Use container builds to avoid GraalVM installation complexity
🎯 Real-World Applications
This architecture is perfect for:
- Microservices: Ultra-fast scaling and deployment
- Serverless: Minimal cold start penalties
- Edge Computing: Low resource requirements
- Cloud-Native: Optimized for containerized environments
- IoT Applications: Minimal memory footprint
- Kubernetes: Perfect for container orchestration
🔮 Future Enhancements
- Caching Layer: Add Redis for improved performance
- Security: Implement JWT authentication with Quarkus Security
- Monitoring: Add metrics with SmallRye Metrics
- Testing: Comprehensive test coverage with Quarkus Test
- CI/CD: Automated deployment pipelines
- GraphQL: Add GraphQL support with Quarkus GraphQL
📚 Resources and Code
The complete source code is available on GitHub:
https://github.com/issam1991/quarkus-native-angular-sample
Key Dependencies:
- Quarkus 3.15.1
- Angular 20.3.0
- GraalVM Native Image
- MariaDB Driver
- Docker & Docker Compose
🎉 Conclusion
Building this application taught me that native compilation isn't just a performance optimization—it's a paradigm shift. The combination of Quarkus Native Image and Angular creates a powerful, modern full-stack solution that's:
- ⚡ Lightning fast startup times (~47ms, matching Spring Boot Native)
- 💾 Superior memory efficiency: 20.72 MiB backend at startup, 28 MiB under load (58% and 44% less than Spring Boot Native's 50 MiB!)
- 🌐 Ultra-lightweight frontend: 2.625 MiB with nginx (vs 15.89 MiB with Node.js Alpine + http-server - 6x less!)
- 📦 Complete stack footprint: ~23 MiB at startup, ~31 MiB under load (excluding database)
- 🐳 Cloud-ready for modern deployments
- 🔧 Developer friendly with familiar technologies and excellent dev experience
Why Choose Quarkus Over Spring Boot Native?
The real-world Docker stats tell the story clearly:
| Metric | Spring Boot Native | Quarkus Native | Advantage |
|---|---|---|---|
| Backend Memory (startup) | 50 MiB | 20.72 MiB | 58% less |
| Backend Memory (under load) | 50 MiB+ | 28 MiB | 44% less |
| Frontend (nginx) | ~15-100 MiB (Node.js) | 2.625 MiB | 95-97% less |
| Total App Memory (startup) | ~70-150 MiB | ~23 MiB | 77-85% less |
| Total App Memory (under load) | ~100-150 MiB | ~31 MiB | 69-79% less |
| Configuration | More complex | Simpler (zero-config) | Developer friendly |
| Code Simplification | Standard JPA | Panache (Active Record) | Less boilerplate |
Quarkus's philosophy of "developer joy" combined with superior resource efficiency makes it the perfect choice for modern Java applications. The framework is specifically designed for cloud-native, containerized environments, and the performance numbers prove it.
The future of Java applications is native, and Quarkus not only makes getting there easier—it makes it more efficient.
📖 What's Next?
If you found this article helpful, consider:
- Starring the repository on GitHub
- Trying the application yourself
- Contributing improvements or features
- Sharing with your development team
Happy coding! 🚀
This article was originally published on ForTek Advisor blog
Follow me on GitHub and connect with ForTek Advisor for more technical content and project updates.
#Quarkus #Angular #NativeImage #GraalVM #Java #TypeScript #FullStack #WebDevelopment #Performance #Microservices #CloudNative
Top comments (0)