[Feature] Add option to bundle the directory of server routes

[rtritto]

Routes files (eg /server/api directory)

├── server
│   ├── index.ts         // entrypoint of server
│   ├── api              // directory for routes
│   │   ├── user
│   │   │   └── [id].ts  // GET /user/:id

should be bundled (during build script) in dist directory (eg /dist/server/api directory) as

├── dist
│   └── server
│        ├── index.ts          // entrypoint of server
│        ├── api               // directory for routes
│        │   ├── user
│        │   │   └── [id].mjs  // GET /user/:id

Solution (draft):

// vite.config.ts
import vikeNode from 'vike-node/plugin'

export default {
  // ...
  plugins: [
    vikeNode({
      entry: 'server/index.ts',
      apiDir: 'server/api'
    })
  ]
}

OR/AND (preferred) use /server/api as standard/default directory

// vite.config.ts
import vikeNode from 'vike-node/plugin'

export default {
  // ...
  plugins: [
    vikeNode({
      entry: 'server/index.ts'
    })
    // OR
    // vikeNode('server/index.ts')
  ]
}

[rtritto]

This feature is needed for production.
Should the priority be increased?

FYI @magne4000

[rtritto]

The documentation API Routes can also be updated with some references of bundle and the (recommend) usage of vike-node as tool:

To create API routes, we recommend to simply use your server (such as Express.js or Hono) to create new HTTP GET/POST endpoints.

FYI @brillout @nitedani

[rtritto]

The feature maybe can be added in vike-node/src/plugin/plugins/standalonePlugin.ts, something like in the findRollupBundleEntries function.

[brillout]

AFAICT API routes have a subpar DX compared to RPC, which is why I believe it's best for the Vike team to focus on Telefunc instead of focusing on API routes.

If you insist on using API routes, you can achieve it by implementing a new Vite plugin vite-plugin-api-routes (similarly to how telefunc/vite works). As we mentioned at https://vike.dev/api-routes we believe it's best to decouple data connection tools from Vike, that's why I'm reluctant to pursue your PR.

We'll start mentioning vike-node in Vike's docs and integrating it to Bati once it's out of beta.

[rtritto]

Thanks, for the answer, now it's clearer.

In Vike's docs, it would be appropriate to add a comparison table for differences (DX, bundle size, dependencies size, performance etc) of API routes vs RPC inside Vike?

[brillout]

Although I agree it would be nice, it isn't a priority right now (there are a lot of more important things to do IMO).

[brillout]

Thank you for understanding @rtritto.

[markomitranic]

AFAICT API routes have a subpar DX compared to RPC, which is why I believe...

I'd just like to point out that the transport nature of API routes is very different to RPC, which makes a significant tradeoff. One cannot utilize HTTP cache strategies with RPC, which is a major problem for most public websites, such as e-commerce websites. Another example is RPC's cookie immutability in websocket-based RPC clients, which makes us have to find workarounds such as reconnecting to the server whenever a cookie change is needed. All in all, a lot to consider outside of DX.

My goal isn't to change your mind - just to point out that a framework that skips on the de-facto king of client-server communication - HTTP JSON APIs - presents itself as a big red flag.

@brillout
Being opinionated and choosing your battles is good. So just add a docs callout/link or entry with an explanation on how to do vite/express HTTP APIs in a way that suits the Vike philosophy, and you're good! :)

[brillout]

FYI it's actually on the radar to allow telefunctions to control caching.

In the meantime, https://vike.dev/api-routes (I just improved it vikejs/vike@7da0ed8) mentions using Express.js and Hono routes.