Search

SearchSearch

Dec 13, 2025, 3 min read

Nitro

Nitro is a Javascript server engine, the goal is to deploy any JavaScript server anywhere you want.

We have the following improvements comparing to Nuxt 2:

Standalone Server

Nitro produces a standalone server dist that is independent of node_modules.

The server in Nuxt 2 is not standalone and requires part of Nuxt core to be involved by running nuxt start (with the nuxt-start or nuxt distributions) or custom programmatic usage, which is fragile and prone to breakage and not suitable for serverless and service-worker environments.

Nuxt 3 generates this dist when running nuxt build into a .output directory.

The output contains runtime code to run your Nuxt server in any environment (including experimental browser service workers!) and serve your static files, making it a true hybrid framework for the JAMstack. In addition, Nuxt implements a native storage layer, supporting multi-source drivers and local assets.

Better server routing

Nuxt 2

You would use server middleware to do API routing

// server-middleware/test.ts
export default function (req, res) {
  res.end(JSON.stringify({ hello: 'world' }))
}

To register this middleware:

// nuxt.config
export default {
  serverMiddleware: {
   '/api/test': './server-middleware/test'
  }
}

Now if we call http://localhost:3000/api/test we get the response:

{
  "hello": "world"
}

As you can see it’s plain simple node.js middleware, supports typescript and it had a basic router system using prefixes. But it has some limitations. For example, lack of dynamic path support in the route, no alias and transform support, and files are not bundled and are loaded in the runtime and we have to deploy the entire source code to the production to make it work.

Nuxt 3

To create a server route in Nuxt 3:

// server/api/hello.ts
export default () => ({ nuxt: "is easy!" })
 
// http://localhost:3000/api/hello
{
  "nuxt": "is easy!"
}

Also, it has a first-class integration with the runtime application and works out of the box:

// app.vue
<template>
  <div> {{ data }} </div>
<template>
 
<script setup>
  const { data } = await useFetch('/api/hello')
</script>

Better API Calls

Nuxt 2

When you try to fetch something from the server side in your nuxt 2 application some strange things happen.

In this example, we are loading a product page in a webshop. In order to Server side render this endpoint we have to fetch the product’s data, from the same API that is living on the same server. Maybe the only upside is that we have a shared server and there is no need to set up another server for the APIs.

But there are more downsides:

  • The base URL has to be manually configured and is a nightmare.
  • SSR API calls roundtrip in real-world apps to bring huge latency, making nuxt 2 apps slower than expected.
  • There is no built-in HTTP client.
Nuxt 3

In opposite to Nuxt 2 where we had to make a round-trip, here we have direct API calls with 0 latency, baseURL is automatically handled, and also fetch is improved with unjs/ohmyfetch.

Reference

Nitro - Create web servers that run anywhere. GitHub - unjs/nitro: Create, build and deploy universal web servers. The open engine powering Nuxt and open to everyone. Full Stack Development With Nuxt 3 and Nitro — Vue Amsterdam Conference 2022 — Ninth Talk | by Mohsen | Medium

Backlinks