Do you know how to migrate frontend to .NET 10?

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 10.

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 10. Here are a couple of the many options available.

Option 1: Keep hosting frontend integrated with .NET 10

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 10).

✅ 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 Web Apps and use Azure Front Door to route requests to frontend on frontend routes and backend routes to the .NET 10 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 10

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

✅ Figure: Good example - 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 front-end applications in a .NET 10 environment.