Do you know how to migrate frontend to .NET 8?
In the case where the legacy .NET Framework application is hosting the frontend, it is recommended to also think about the hosting method of the frontend in .NET 8.
This issue is best considered before or during the migration so the team will not spend time implementing something that will be removed shortly in the future.
Depending on the scenario and the situation of the projects, there are many options available to host the frontend with .NET 8. Here are a couple of the many options available.
Option 1: Keep hosting frontend integrated with .NET 8
No changes to the flow, keep hosting the frontend the same way as before (e.g. bundling the frontend build artifacts as a static resource in .NET 8).
✅ Pros:
- Simple setup with no need for additional infrastructure
- Familiar workflow if migrating from .NET Framework
❌ Cons:
- Frontend and backend must be built and deployed together
- Less flexibility for future scalability and updates
Option 2: Host frontend on its own
This option fully separates the frontend from the backend. This requires serving the frontend on a separate hostname or using a gateway service to redirect API with frontend routes. e.g. Hosting frontend in Azure Static WebApp and use Azure Frontdoor to route requests to frontend on frontend routes and backend routes to the .NET 8 application.
✅ Pros:
- Future-proof hosting that allows for independent frontend updates
- Supports preview environments for testing
- Faster build times due to separate frontend and backend builds
- Direct CDN integration (e.g. with Azure Front Door), improving performance
❌ Cons:
- More complex deployment story
- Higher infrastructure cost
- Requires extra configuration and management effort
Option 3: Host frontend externally, serve it together with .NET 8
Hosting your frontend application in a separate storage (e.g. in Azure Blob Storage) is the mixed transitionary approach where the frontend artifacts are hosted separately from the backend, and the backend will pass these artifacts to the frontend without statically embedding the resource in the backend. This option still allows a clean separation of concerns, allowing for independent scaling and deployment of the frontend and backend, while also sitting in a transition where we have the option to host the frontend standalone, similar to Option 2 setup.
✅ Pros:
- Faster build times due to separate frontend and backend builds
- Similar serving setup as before
❌ Cons:
- Slightly more complex deployment story
- Requires extra configuration and management effort
- Increased ingress network load to the backend
Option 2 is typically preferred for future-proofing, but Option 3 can also be recommended for its balance of cost, build efficiency, and future flexibility. Remember to weigh these factors in the context of your project's specific needs and constraints.
Figure: Good example - Deciding on frontend hosting, considering its scalability and cost benefits
Best Practices
- Cost-Effectiveness: Evaluate the cost against benefits for each option. If budget is tight, Option 1 is less costly while Option 3 offers a good balance
- Development Workflow: Consider the impact on your development workflow. Option 2 and Option 3 promote a more decoupled architecture, which could be beneficial for teams
- Performance: Assess how each option affects the performance of your application. Decoupling the frontend can offer performance benefits through CDN caching
- Future-Proofing: Think long-term. Option 2 and Option 3 provide more flexibility for future changes and scalability
By carefully assessing your needs and understanding the trade-offs of each option, you can make an informed decision on how to serve your Angular applications in a .NET 8 environment.
