Dotnet on TECHFOR by Suriya Sonphu

Building Full Stack Web Applications: Vue.js + Tailwind CSS + ASP.NET Core 9 Minimal API with Modular Monolith Architecture

Fri, 08 Aug 2025 00:00:00 +0000

Introduction: What is Full Stack Development?

Full Stack Development refers to the development of both the frontend (client-side) and backend (server-side) portions of a web application. A full stack developer is someone who can work on both the user interface that users interact with and the server logic that powers the application behind the scenes.

Key Components of Full Stack Development:

Frontend (Client-side): What users see and interact with
- User Interface (UI)
- User Experience (UX)
- Client-side logic and interactions
Backend (Server-side): The engine that powers the application
- Server logic and APIs
- Database management
- Authentication and security
- Business logic
Database: Where data is stored and managed
DevOps: Deployment and infrastructure management

In this tutorial, we’ll build a complete full stack application using modern technologies: Vue.js for the frontend, Tailwind CSS for styling, and ASP.NET Core 9 Minimal API for the backend, all organized using Modular Monolith architecture.

What is Vue.js?

Vue.js is a progressive JavaScript framework for building user interfaces and single-page applications (SPAs). Created by Evan You in 2014, Vue.js has become one of the most popular frontend frameworks alongside React and Angular.

Key Features of Vue.js:

Progressive Framework: You can adopt Vue.js incrementally - use it for just one part of your page or build entire applications
Reactive Data Binding: Automatic UI updates when data changes
Component-Based Architecture: Build encapsulated components that manage their own state
Virtual DOM: Efficient rendering for optimal performance
Easy Learning Curve: Simple syntax that’s easy for beginners to understand

Vue.js Advantages:

Small bundle size: Fast loading times
Excellent documentation: Comprehensive and beginner-friendly
Great ecosystem: Rich set of tools and libraries
TypeScript support: Full TypeScript integration
Composition API: Modern way to organize component logic

Example Vue.js Component:

<template>
 <div class="user-profile">
 <h2>{{ user.name }}</h2>
 <p>{{ user.email }}</p>
 <button @click="updateProfile">Update Profile</button>
 </div>
</template>

<script setup>
import { ref, reactive } from 'vue'

const user = reactive({
 name: 'John Doe',
 email: 'john@example.com'
})

const updateProfile = () => {
 // Update user profile logic
 console.log('Profile updated!')
}
</script>

Reference: Vue.js Official Documentation

What is Tailwind CSS?

Tailwind CSS is a utility-first CSS framework that provides low-level utility classes to build custom designs directly in your markup. Instead of writing custom CSS, you compose designs by combining small, single-purpose utility classes.

Key Features of Tailwind CSS:

Utility-First: Pre-built classes for common CSS properties
Responsive Design: Built-in responsive design utilities
Customizable: Highly configurable design system
Performance: Remove unused CSS automatically
Developer Experience: Excellent IDE support and debugging tools

Tailwind CSS Advantages:

Rapid Development: Build interfaces quickly without writing custom CSS
Consistent Design: Built-in design system ensures consistency
Mobile-First: Responsive design by default
Small Bundle Size: Only includes the CSS you actually use
No Context Switching: Style components without leaving your HTML

Example Tailwind CSS Usage:

<!-- Traditional CSS approach -->
<div class="card">
 <h2 class="card-title">Hello World</h2>
 <p class="card-description">This is a description</p>
 <button class="btn btn-primary">Click me</button>
</div>

<!-- Tailwind CSS approach -->
<div class="bg-white p-6 rounded-lg shadow-md">
 <h2 class="text-2xl font-bold text-gray-900 mb-2">Hello World</h2>
 <p class="text-gray-600 mb-4">This is a description</p>
 <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
 Click me
 </button>
</div>

Common Tailwind CSS Classes:

Layout: flex, grid, container, mx-auto
Spacing: p-4 (padding), m-2 (margin), space-y-4
Typography: text-xl, font-bold, text-center
Colors: bg-blue-500, text-red-600, border-gray-300
Responsive: sm:text-lg, md:grid-cols-2, lg:px-8

Reference: Tailwind CSS Official Documentation

What is ASP.NET Core 9 Minimal API?

ASP.NET Core Minimal API is a streamlined approach to building HTTP APIs with ASP.NET Core. Introduced in .NET 6 and enhanced in subsequent versions including .NET 9, Minimal APIs allow you to create APIs with minimal ceremony and boilerplate code.

Key Features of Minimal API:

Reduced Boilerplate: Less code to write compared to traditional controllers
Performance: High performance with minimal overhead
Simple Syntax: Easy to understand and write
Built-in Features: Automatic model binding, validation, and OpenAPI support
Hosting: Integrated with ASP.NET Core hosting model

Minimal API Advantages:

Fast Development: Quickly create APIs with minimal setup
Microservices Friendly: Perfect for small, focused services
Cloud Native: Optimized for containerized environments
Modern C# Features: Leverages latest C# language features
Integration: Works seamlessly with other .NET libraries

Example Minimal API:

using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container
builder.Services.AddDbContext<AppDbContext>(options =>
 options.UseSqlite("DataSource=app.db"));

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline
if (app.Environment.IsDevelopment())
{
 app.UseSwagger();
 app.UseSwaggerUI();
}

app.UseHttpsRedirection();

// Define API endpoints
app.MapGet("/api/products", async (AppDbContext db) =>
 await db.Products.ToListAsync())
 .WithName("GetProducts")
 .WithOpenApi();

app.MapGet("/api/products/{id}", async (int id, AppDbContext db) =>
 await db.Products.FindAsync(id) is Product product
 ? Results.Ok(product)
 : Results.NotFound())
 .WithName("GetProduct")
 .WithOpenApi();

app.MapPost("/api/products", async (Product product, AppDbContext db) =>
{
 db.Products.Add(product);
 await db.SaveChangesAsync();
 return Results.Created($"/api/products/{product.Id}", product);
})
.WithName("CreateProduct")
.WithOpenApi();

app.Run();

// Models
public class Product
{
 public int Id { get; set; }
 public string Name { get; set; } = string.Empty;
 public decimal Price { get; set; }
 public string Description { get; set; } = string.Empty;
}

public class AppDbContext : DbContext
{
 public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }
 public DbSet<Product> Products { get; set; }
}

Reference: ASP.NET Core Minimal APIs Documentation

Example Project: E-commerce Product Catalog

Let’s build a simple e-commerce product catalog that demonstrates how all these technologies work together in a modular monolith architecture.

Project Structure:

ECommerceApp/
├── frontend/ # Vue.js + Tailwind CSS
│ ├── src/
│ │ ├── components/
│ │ ├── views/
│ │ ├── services/
│ │ └── main.js
│ ├── index.html
│ └── package.json
├── backend/ # ASP.NET Core 9 Minimal API
│ ├── Modules/
│ │ ├── Products/
│ │ ├── Orders/
│ │ └── Users/
│ ├── Shared/
│ │ ├── Database/
│ │ └── Infrastructure/
│ ├── Program.cs
│ └── ECommerceApp.csproj
└── README.md

Frontend Implementation (Vue.js + Tailwind):

ProductList.vue:

<template>
 <div class="container mx-auto px-4 py-8">
 <h1 class="text-3xl font-bold text-gray-900 mb-8">Product Catalog</h1>

 <div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
 <div
 v-for="product in products"
 :key="product.id"
 class="bg-white rounded-lg shadow-md overflow-hidden hover:shadow-lg transition-shadow"
 >
 <div class="p-6">
 <h3 class="text-xl font-semibold text-gray-900 mb-2">
 {{ product.name }}
 </h3>
 <p class="text-gray-600 mb-4">{{ product.description }}</p>
 <div class="flex justify-between items-center">
 <span class="text-2xl font-bold text-blue-600">
 ${{ product.price }}
 </span>
 <button
 @click="addToCart(product)"
 class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
 >
 Add to Cart
 </button>
 </div>
 </div>
 </div>
 </div>
 </div>
</template>

<script setup>
import { ref, onMounted } from 'vue'
import { productService } from '../services/productService'

const products = ref([])

const fetchProducts = async () => {
 try {
 const response = await productService.getAll()
 products.value = response.data
 } catch (error) {
 console.error('Error fetching products:', error)
 }
}

const addToCart = (product) => {
 // Add to cart logic
 console.log('Added to cart:', product)
}

onMounted(() => {
 fetchProducts()
})
</script>

Product Service:

// services/productService.js
import axios from 'axios'

const API_BASE_URL = 'https://localhost:7070/api'

export const productService = {
 async getAll() {
 return await axios.get(`${API_BASE_URL}/products`)
 },

 async getById(id) {
 return await axios.get(`${API_BASE_URL}/products/${id}`)
 },

 async create(product) {
 return await axios.post(`${API_BASE_URL}/products`, product)
 }
}

Backend Implementation (ASP.NET Core 9 Minimal API):

Program.cs:

using Microsoft.EntityFrameworkCore;
using ECommerceApp.Modules.Products;
using ECommerceApp.Modules.Orders;
using ECommerceApp.Shared.Database;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container
builder.Services.AddDbContext<AppDbContext>(options =>
 options.UseSqlite(builder.Configuration.GetConnectionString("DefaultConnection")));

// Add CORS
builder.Services.AddCors(options =>
{
 options.AddPolicy("AllowFrontend", policy =>
 {
 policy.WithOrigins("http://localhost:3000")
 .AllowAnyHeader()
 .AllowAnyMethod();
 });
});

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

// Register module services
builder.Services.AddProductModule();
builder.Services.AddOrderModule();

var app = builder.Build();

// Configure the HTTP request pipeline
if (app.Environment.IsDevelopment())
{
 app.UseSwagger();
 app.UseSwaggerUI();
}

app.UseHttpsRedirection();
app.UseCors("AllowFrontend");

// Map module endpoints
app.MapProductEndpoints();
app.MapOrderEndpoints();

app.Run();

Product Module:

// Modules/Products/ProductModule.cs
using Microsoft.EntityFrameworkCore;
using ECommerceApp.Shared.Database;

namespace ECommerceApp.Modules.Products;

public static class ProductModule
{
 public static IServiceCollection AddProductModule(this IServiceCollection services)
 {
 services.AddScoped<IProductService, ProductService>();
 return services;
 }

 public static WebApplication MapProductEndpoints(this WebApplication app)
 {
 var group = app.MapGroup("/api/products").WithTags("Products");

 group.MapGet("/", GetProducts);
 group.MapGet("/{id}", GetProduct);
 group.MapPost("/", CreateProduct);
 group.MapPut("/{id}", UpdateProduct);
 group.MapDelete("/{id}", DeleteProduct);

 return app;
 }

 private static async Task<IResult> GetProducts(IProductService productService)
 {
 var products = await productService.GetAllAsync();
 return Results.Ok(products);
 }

 private static async Task<IResult> GetProduct(int id, IProductService productService)
 {
 var product = await productService.GetByIdAsync(id);
 return product != null ? Results.Ok(product) : Results.NotFound();
 }

 private static async Task<IResult> CreateProduct(Product product, IProductService productService)
 {
 var createdProduct = await productService.CreateAsync(product);
 return Results.Created($"/api/products/{createdProduct.Id}", createdProduct);
 }

 private static async Task<IResult> UpdateProduct(int id, Product product, IProductService productService)
 {
 if (id != product.Id) return Results.BadRequest();

 var updatedProduct = await productService.UpdateAsync(product);
 return updatedProduct != null ? Results.Ok(updatedProduct) : Results.NotFound();
 }

 private static async Task<IResult> DeleteProduct(int id, IProductService productService)
 {
 var success = await productService.DeleteAsync(id);
 return success ? Results.NoContent() : Results.NotFound();
 }
}

Why is Modular Monolith Important?

Modular Monolith combines the benefits of both monolithic and microservices architectures, making it an excellent choice for many applications, especially when starting a new project.

Benefits of Modular Monolith:

Simplicity: Single deployment unit, easier to develop and debug
Performance: No network latency between modules
Consistency: Single database transactions across modules
Development Speed: Faster development with shared code and libraries
Easy Refactoring: Can be split into microservices later if needed

Key Principles:

Clear Module Boundaries: Each module has well-defined responsibilities
Loose Coupling: Modules communicate through well-defined interfaces
High Cohesion: Related functionality stays together within a module
Shared Infrastructure: Common concerns like logging, configuration, database

When to Use Modular Monolith:

Starting a new project: Begin with monolith, split later if needed
Small to medium teams: Easier coordination and development
Uncertain domain boundaries: Learn the domain before splitting
Performance requirements: Lower latency than distributed systems
Consistency requirements: Need ACID transactions across modules

Example Module Structure:

// Modules/Products/
├── ProductModule.cs # Module configuration and endpoints
├── Models/
│ ├── Product.cs # Product entity
│ └── ProductDto.cs # Data transfer objects
├── Services/
│ ├── IProductService.cs # Service interface
│ └── ProductService.cs # Service implementation
└── Data/
 └── ProductRepository.cs # Data access layer

// Modules/Orders/
├── OrderModule.cs
├── Models/
├── Services/
└── Data/

// Shared/
├── Database/
│ └── AppDbContext.cs # Shared database context
├── Infrastructure/
│ ├── Logging/
│ └── Configuration/
└── Common/
 └── BaseEntity.cs # Shared base classes

Migration Path to Microservices:

If your application grows and you need to split into microservices, the modular structure makes this transition easier:

Identify Module Boundaries: Modules become service boundaries
Extract Database: Give each service its own database
Add Communication Layer: Replace direct calls with HTTP/messaging
Deploy Independently: Each service gets its own deployment pipeline

Conclusion

Building full stack applications with Vue.js, Tailwind CSS, and ASP.NET Core 9 Minimal API using Modular Monolith architecture provides:

Modern Development Experience: Latest technologies and best practices
Rapid Development: Quick iteration and deployment
Scalable Architecture: Can grow from monolith to microservices
Great Developer Experience: Excellent tooling and documentation
Performance: Fast and efficient applications

This approach is perfect for beginners starting their coding journey because it provides:

Clear separation of concerns
Modern development practices
Scalable architecture
Excellent learning resources

Start with this stack, learn the fundamentals, and gradually expand your knowledge as your applications grow in complexity.

References

Modular Monolith: Architecture that combines the benefits of Monolith and Microservices

Sun, 27 Jul 2025 00:00:00 +0000

What is Modular Monolith and Why It’s an Interesting Alternative

Modular Monolith is a software architecture that combines the benefits of Monolith and Microservices by organizing code into modules with clear bounded contexts while maintaining single deployment unit.

Problems with Traditional Monolith

Traditional Monolith often suffers from:

Tightly Coupled Code: All parts are tightly bound, making changes difficult
Single Point of Failure: If one part fails, the entire system fails
Technology Lock-in: Must use the same technology stack throughout
Difficult to Scale: Cannot scale specific parts independently

Problems with Microservices

While Microservices solve many monolith problems, they introduce additional complexity:

Distributed System Complexity: Complexity of distributed systems
Network Latency: Delays from network communication
Data Consistency: Data consistency challenges
Operational Overhead: Requires strong DevOps teams
Development Complexity: Complexity in development and debugging

Modular Monolith: A Balanced Solution

Modular Monolith offers a balanced approach:

✅ Benefits:

Modularity: Clear module separation by business domain
Loose Coupling: Modules communicate through defined interfaces
Single Deployment: Easy to deploy and maintain
Easier Testing: Easier to test than distributed systems
Gradual Migration: Can be extracted to microservices in the future

⚠️ Considerations:

Technology Constraint: Still limited by primary technology
Shared Database: May have data coupling issues
Resource Scaling: Cannot scale individual modules separately

Architecture of Modular Monolith E-commerce Application

I created a Modular Monolith E-commerce Application using C# and ASP.NET Core to demonstrate the application of these principles in real system development.

🏗️ Architecture Overview

ECommerceApp/
├── src/
│ ├── ECommerceApp/ # Main Web API Application
│ │ ├── Controllers/ # API Controllers
│ │ ├── Program.cs # Application entry point
│ │ └── ECommerceApp.csproj
│ ├── ECommerceApp.Shared/ # Shared Kernel
│ │ ├── Events/ # Domain Events
│ │ ├── Kernel/ # Base entities, interfaces
│ │ └── ECommerceApp.Shared.csproj
│ └── Modules/
│ ├── Orders/ # Orders Module
│ │ ├── Application/ # Use cases, commands, queries
│ │ ├── Domain/ # Domain entities, events
│ │ ├── Infrastructure/ # Data access, repositories
│ │ ├── OrdersModule.cs # Module registration
│ │ └── ECommerceApp.Modules.Orders.csproj
│ ├── Products/ # Products Module
│ │ ├── Application/
│ │ ├── Domain/
│ │ ├── Infrastructure/
│ │ ├── ProductsModule.cs
│ │ └── ECommerceApp.Modules.Products.csproj
│ └── Customers/ # Customers Module
│ ├── Domain/
│ ├── Infrastructure/
│ ├── CustomersModule.cs
│ └── ECommerceApp.Modules.Customers.csproj

🎯 Key Principles of Modular Monolith

1. Modules Each module represents a distinct business capability such as Orders, Products, Customers

2. Encapsulation Modules hide internal details and expose only necessary functionality through interfaces

3. Shared Kernel Common functionality such as base entities, common utilities, domain events

4. Communication Modules communicate through interfaces or domain events, avoiding direct dependencies

5. Single Deployment All modules are deployed together as a single unit

Getting Started

Prerequisites

.NET 8.0 SDK
Visual Studio Code or Visual Studio

Quick Start

1. Clone Repository:

git clone https://github.com/suriyasonp/modular-monolith-ecommerce.git
cd modular-monolith-ecommerce

2. Run Application:

# Method 1: Using script (Recommended)
./run.sh

# Method 2: Manual run
dotnet build
dotnet run --project src/ECommerceApp/ECommerceApp.csproj

3. Access API:

Swagger UI: http://localhost:5000/swagger/index.html
API Base URL: http://localhost:5000/api
Sample Products: Data will be automatically seeded on startup

Testing the Application

Quick Test Script:

./test-api.sh

Key API Endpoints

Products API

GET /api/products - Get all products
GET /api/products/{id} - Get product by ID
POST /api/products - Create new product
PUT /api/products/{id}/price - Update product price
PUT /api/products/{id}/stock - Update product stock

Customers API

GET /api/customers - Get all customers
GET /api/customers/{id} - Get customer by ID
POST /api/customers - Create new customer

Orders API

GET /api/orders - Get all orders
GET /api/orders/{id} - Get order by ID
GET /api/orders/customer/{customerId} - Get orders by customer
POST /api/orders - Create new order
POST /api/orders/{id}/confirm - Confirm order
POST /api/orders/{id}/ship - Ship order
POST /api/orders/{id}/deliver - Deliver order

Benefits and Drawbacks of Modular Monolith

✅ Benefits

1. Deployment Simplicity

Deploy as single unit, reducing infrastructure complexity
No need to worry about service discovery or load balancing
Easy rollbacks

2. Performance

No network latency between modules
Communication is in-process calls
Cross-module transactions are straightforward

3. Development and Debugging

Easier to debug than distributed systems
Better IDE support
Simpler end-to-end testing

4. Operational Costs

Lower infrastructure requirements
No need for large DevOps teams
Simpler monitoring and logging

5. Future Flexibility

Can be extracted to microservices when necessary
Well-designed modules are easily extractable

⚠️ Drawbacks

1. Technology Constraints

Must use the same primary technology
Difficult to use different tech stacks

2. Scaling

Cannot scale individual modules separately
Resource utilization may not be optimal

3. Database Coupling

Shared database may create coupling issues
Schema migrations need careful consideration

4. Team Independence

Teams still need to coordinate deployments
Shared codebase may be problematic for large teams

When to Use Modular Monolith

🎯 Suitable for

1. Small to Medium Teams (2-20 people)

Limited resources for infrastructure complexity
Need high development velocity

2. New Applications

Uncertain about domain boundaries
Need rapid prototyping and iteration

3. Unclear Requirements

Business requirements change frequently
Need flexibility for adjustments

4. Limited DevOps Capability

Team not ready for distributed systems
Infrastructure automation not mature

🚫 Not Suitable for

1. Large Organizations with Many Teams

Teams need high independence
Different release cycles

2. Very Different Requirements

Different scalability requirements per module
Need different technologies

3. High Compliance and Security Constraints

Need isolation between components
Strict regulatory requirements

Migration Path Planning

Phase 1: Start with Modular Monolith

Traditional Monolith → Modular Monolith

Activities:

Identify domain boundaries
Create modules by business capabilities
Implement interfaces for inter-module communication
Add domain events infrastructure

Phase 2: Improve Module Independence

Tightly Coupled Modules → Loosely Coupled Modules

Activities:

Separate databases per module
Use event-driven communication
Implement distributed tracing
Add per-module monitoring

Phase 3: Selective Microservices Extraction

Modular Monolith → Hybrid Architecture

Activities:

Identify modules suitable for extraction
Extract modules with different scaling needs
Implement API gateways
Setup service mesh

Conclusion

Modular Monolith is a suitable architecture for many types of organizations, especially teams that want the benefits of modularity but are not ready for the complexity of microservices.

🔑 Key Takeaways

1. Start Simple

Use Modular Monolith as starting point
Focus on domain modeling and clean boundaries
Improve gradually

2. Design for Change

Use interfaces for inter-module communication
Implement domain events infrastructure
Prepare monitoring and observability

3. Plan Migration Path

Identify modules that may need extraction in the future
Design data access patterns that support separation
Build culture of modular thinking

4. Focus on Business Value

Don’t let technical complexity overshadow business goals
Use architecture appropriate for team and context
Remember: Architecture is means, not end

🚀 Next Steps

Study the Code: Visit the repository to understand implementation details
Try Running: Execute ./test-api.sh to see all functionality
Add Features: Try creating new modules following established patterns
Apply to Production: Adapt for production environment

Modular Monolith is not a silver bullet, but it’s an effective tool for building maintainable, scalable, and evolvable systems in the long term.

References

Modular Monolith E-commerce Repository - Implementation Example
Domain-Driven Design - Eric Evans
Modular Monoliths - Kamil Grzybek
Building Microservices - Sam Newman
Clean Architecture - Robert C. Martin
ASP.NET Core Documentation - Microsoft Docs
Monolith vs Microservices vs Modular Monoliths - Monolith vs Microservices vs Modular Monoliths