Full Stack Application using Angular and Asp.NET Core

Soumyadip Majumder

For creating modern web app or enterprise application, if I choose Angular for frontend and Asp.NET Core for backend, for keeping microservices approach should I keep it different .sln folder (working in Visual Studio Community Edition)?

What is the best procedure for microservices approach to create a full-stack application using Angular and Asp.NET Core?

2 Replies

Know the answer? Post it — somebody with the same question will find it here.

Abhishek Yadav10mo ago

Accepted answer

YES — if you're following real microservices architecture , each microservice should be independently built, deployed, and scaled .
This means:

Recommended structure

/src
   /service-auth
       AuthService.sln
       AuthService.API/
       AuthService.Domain/
       AuthService.Infrastructure/

   /service-booking
       BookingService.sln
       BookingService.API/
       BookingService.Domain/
       BookingService.Infrastructure/

   /service-payments
       PaymentService.sln
       PaymentService.API/
       PaymentService.Domain/
       PaymentService.Infrastructure/

/frontend
   /client-app
       Angular project here

Each microservice gets:

Its own solution (.sln)
Its own database (if needed)
Its own CI/CD pipeline
Its own versioning
Independent deployment

This is the correct microservices way.

Mominul Islam10mo ago
If you're going for a real microservices architecture, yes — keep each service in its own solution (.sln).
Microservices aren’t just “separate projects”… they are separate deployable units, with independent lifecycle, scaling, and CI/CD pipelines.
For a full-stack Angular + ASP.NET Core microservices app, the cleanest setup is:
- Angular in its own repo (standalone SPA).
- Each ASP.NET Core microservice in a separate solution + separate repo.
- API Gateway (e.g., YARP / Ocelot) in its own solution.
- Shared contracts via NuGet package (not shared project).
- Communication via REST/gRPC/MessageBus (RabbitMQ/Kafka).
- Database per service (no shared DB).
This structure keeps services loosely coupled, fully autonomous, and deployable independently — which is the whole point of microservices.
In Visual Studio (even Community Edition), this approach works perfectly.
Trying to put all services under one .sln usually pushes you back into a monolith.
0