Multi target builds

[pi0]

Normally each nitro build is against one specific deployment preset and consistent with the development environment.

Sometimes it is desired that the same codebase be splitted across different deployments. For example, deploying some middleware and API handlers to the edge and the rest to a normal Node.js/AWS hosting.

In this mode, nitro should only clean up the build directory once and make a shared context for presets to extend config instead of overriding when needed.

This feature shall be combined with API route filters to only generate preset relevant routes. (#1159)

[Hebilicious]

An elegant way to handle this would be to use routeRules and a target property:

We could also accept a function to make it easier to discover the supported target, maybe something like this ?

export default defineNitroConfig({
  routeRules: {
    '/api/edge.get.ts': { target: t => t.vercel.edge   },
    '/api/serverless.get.ts': { target: t => t.vercel.serverless  }
  }
})

I wonder if that could be extended to support multi-provider builds?

[pi0]

I love the idea to allow extending handler meta with route rules for multi-target support 👍🏼

Only note that route rules shall not accept functions. They are plain objects. A nitro hook can be used for such dynamic behavior support.

[Hebilicious]

I love the idea to allow extending handler meta with route rules for multi-target support 👍🏼

Only note that route rules shall not accept functions. They are plain objects. A nitro hook can be used for such dynamic behavior support.

Got it. Maybe we could have something like import { buildTarget } from "nitro" so we could provide pre-made build targets to end users, buildTarget.vercel.edge for example.

[pi0]

Types should do it! (Also we should warn anyway for any unsupported target being redirected to the default/main target).

[cosbgn]

Would it be possible to have multiple providers something like:

export default defineNitroConfig({
  routeRules: {
    '/api/edge.get.ts': { target: t => t.vercel.edge   },
    '/api/long-processing.get.ts': { target: t => t.netlify.background_function  }
  }
})

When deployed on github, both vercel & netlify would pick it up and build only the functions relevant to them? so my-app.vercel.app/long-processing would be a 404 but my-app.netlify.app/long-processing would work

[Hebilicious]

Would it be possible to have multiple providers something like:

export default defineNitroConfig({
  routeRules: {
    '/api/edge.get.ts': { target: t => t.vercel.edge   },
    '/api/long-processing.get.ts': { target: t => t.netlify.background_function  }
  }
})

When deployed on github, both vercel & netlify would pick it up and build only the functions relevant to them? so my-app.vercel.app/long-processing would be a 404 but my-app.netlify.app/long-processing would work

Multi provider builds are interesting, but that would probably mean we would need to support a subset of nitro options within routeRules/target (preset etc)

[chrisjansky]

Any updates on this please?

It would be an amazing feature to be able to somehow specify both netlify serverless and edge functions for specific functions 🙏

[brhx]

Is there still appetite for this in Nitro itself?

[pi0]

It is on track, hopefully when we adopt vite env API in v3.

[andrewdoro]

Coming back to this for a different case, in Vercel, you can deploy multiple functions for the same runtime.

The current approach was bundling everything in one bundle, which can cause some limitations in terms of size. (vercel has some limits). Also, I know they added Fluid Compute to help with cold starts, but I don't fully trust that.

There was a blog about splitting a single serverless function endpoint and what the impact was for cold start. https://discord.com/channels/719702312431386674/1356739237021483229/1424750366838358068