Development·

Integrating an ASP.NET Core API with a Nuxt Front End: A Step-by-Step Guide

When ASP.NET Core Met Nuxt

In this article, I will walk you through the process of integrating an ASP.NET Core API with a Nuxt.js front end to have a stack that provides a nice developer experience to build web applications.

To make things easier to reproduce, we will create everything from scratch. I will do everything on the command line so that regardless of the IDE you are using (Rider, vscode, Visual Studio, etc) you will be able to understand what’s going on and follow along.

Let’s start by initializing a git repository in a new folder with a gitignore file for .NET:

mkdir AspnetWithNuxt
git init
dotnet new gitignore

We can create an empty .NET solution using the new slnx format to have a much cleaner and simple solution file:

dotnet new sln -n AspnetWithNuxt--format slnx

Then we can use the ASPNET Core Web API template to create the API:

dotnet new webapi -o WebApi
dotnet sln AspnetWithNuxt.slnx add WebApi\WebApi.csproj

The generated ASP.NET Core API only contains one route weatherforecast that returns a list of random weather forecasts like these:

[
  {
    "date": "2025-02-24",
    "temperatureC": 40,
    "summary": "Cool",
    "temperatureF": 103
  },
  {
    "date": "2025-02-25",
    "temperatureC": 14,
    "summary": "Balmy",
    "temperatureF": 57
  }
]

We can now initialize the Nuxt project using the template “Nuxt 3 with v4 compat”. I will be using pnpm as my package manager, because it’s performant and nice to use (check this blog article series here if you want to learn more about pnpm).

pnpx nuxi init WebApp -t v4-compat --packageManager pnpm --gitInit false
💡
I could have used the default template or another starter template but this one will make my app compatible with Nuxt 4 when it is released.

The generated project just contains an App.vue that uses the built-in NuxtWelcome component. Let’s replace it with a new component WeatherForecasts that will make a call to the API and render the weather forecasts:

<template>
  <WeatherForecasts/>
</template>

To initialize the WeatherForecasts component, we can use the nuxi CLI (using nuxt would also work by the way now that the project is initialized).

pnpm nuxi add component WeatherForecasts

The content of the component will be quite simple, the idea is to display data retrieved from the API.

<script setup lang="ts">
interface WeatherForecast {
  date: string;
  temperatureC: number;
  temperatureF: number;
  summary: string;
}
const { data: weatherForecasts } = await useFetch<WeatherForecast[]>('/api/weatherforecast');
</script>
<template>
  <div>
    <div v-if="weatherForecasts">
      <table>
        <thead>
          <tr>
            <th>Date</th>
            <th>Summary</th>
            <th>T (°C)</th>
            <th>T (°F)</th>
          </tr>
        </thead>
        <tbody>
          <tr v-for="item in weatherForecasts" :key="item.date">
            <td>{{ item.date }}</td>
            <td>{{ item.summary }}</td>
            <td>{{ item.temperatureC }}</td>
            <td>{{ item.temperatureF }}</td>
          </tr>
        </tbody>
      </table>
    </div>
  </div>
</template>

In the code, you can notice that the request is made to /api/weatherforecast and not to the URL of the WebApi. Indeed, we want to proxy the requests targeting /api/** to the back end for several reasons:

  • Eliminate the need to configure specific CORS rules in the WebApito prevent CORS errors due to different origins between the WebApp and the WebApi
  • Avoid specifying the complete URL of the WebApi each time we make a request in a component
  • Adopt a similar mechanism to the one that will be used when the application is deployed in the cloud (we will probably also proxy the traffic to the API but it will be directly configured in the infrastructure)

As it is very well explained in this video from Alexander Lichter, there are multiple strategies to do that, but using Vite proxy or Nuxt/Nitro devProxy will only work on the client side and not when using Server Side Rendering. As Nuxt is a Vue framework that supports SSR by default, it would be a shame not to have the proxy work with SSR. So the solution is to configure the route rules in the Nuxt configuration file:

export default defineNuxtConfig({
  compatibilityDate: '2024-11-01',
  devtools: { enabled: true },
  future: {
    compatibilityVersion: 4
  },
  $development: {
    routeRules: {
      '/api/**': {
        proxy: 'http://localhost:5096/**',
      }
    },
  },
})

By placing this configuration in $development, I ensure it only applies to the development environment (locally, in my case). This is because I will likely handle request routing in my infrastructure configuration when my application is deployed in the cloud.

To finish, we can launch the front end and the back end:

// Launch the Nuxt application front end
pnpm --dir WebApp dev
// Launch the ASP.NET Core API
dotnet run --project WebApi\WebApi.csproj

Here are the weather forecasts retrieved from the API and displayed in the Front:

A table showing dates with weather summaries and temperatures in Celsius and Fahrenheit.

Nothing fancy, but I hope this gives you a good understanding of how we can integrate an ASP.NET Core API with a Nuxt front end. Not everything is perfect, we have the URL of the API hardcoded in the Nuxt configuration, and we have to launch the API and the front end separately. In an upcoming article, we will explore how to use .NET Aspire to improve the developer experience.

You can find the complete source code used for this article in this GitHub repository.


The opinions expressed herein are my own and do not represent those of my employer or any other third-party views in any way.

Copyright © 2025 Alexandre Nédélec. All rights reserved.