`+server.js` with `renderPage()` instead of Universal Deploy

[brillout]

Description

See:

• Support custom server entry #3221 (comment)
• Support custom server entry #3221 (comment)

[rtritto]

Is the renderPage already achieved with the server vike plugin?

Example:

// server/index.ts
import vike from '@vikejs/hono'
import { Hono } from 'hono'

const app = new Hono()

vike(app)

export default app

If yes, the user can prefer the manual implementation of the renderPage (e.g. vercel/output/functions/index.func/index.js) or the server vike plugin (zero config approach).

Vike should also fully support the server vike plugin, that's why the user should be able to import the server app.

Example:
api/ssr.js

import app from '../dist/server/index.mjs'
export const GET = app.fetch
export const POST = app.fetch

What are the differences between the renderPage and the server vike plugin?

[brillout]

That isn't the approach we have in mind. What we have in mind is this:

• Via Universal Deploy (UD) => seamless integration (zero config, albeit slightly less flexible)
• Via renderPage() => full flexibility (manual integration with both the server and the deployment provider => the user has to write the integration himself)

The idea here is that 95% of use cases are covered via UD. For those few 5% who need more flexibility they use renderPage() but then they have to fully integrate the server and the deployment themselves.

The primary goal of manual integrations is to enable unprecedented flexibility. Making manual integrations more zero-config isn't the goal. If there are quick-wins to make manual integrations easier, why not — but not at the cost of increasing the complexity of the API (the frankenstein API issue I mentioned earlier). Anyways, let's first focus on enabling both path: the zero-config UD path, and the manual renderPage() integration path. Later, we can see if there are opportunities to make manual integrations easier.

[rtritto]

What about?

From #3221 (comment)

// +config.ts
export default {
  server: {
    // Custom integration via renderPage() (disables UD)
    custom: true
  }
}

The server entrypoint will be in the +server, the renderPage is already handled by @vikejs/hono (of course as alternative the user can do a manual implementation of renderPage instead of using @vikejs/hono).

// +server.ts
import vike from '@vikejs/hono'
import { Hono } from 'hono'

const app = new Hono()

vike(app)

export default app

Note: with +config.server.custom=true, the exports of +server must be respected in the dist/server/index.mjs (e.g. the +server also has export const MY_SETTING = 'MY_SETTING' that will be in dist/server/index.mjs)

[brillout]

renderPage() is more flexible than @vikejs/hono, so let's focus on renderPage() first.

Later, we can see if there are opportunities to make manual integrations easier.

The only goal of @vikejs/hono here would be easier integration, so let's focus on it later.

[brillout]

Note: with +config.server.custom=true, the exports of +server must be respected in the dist/server/index.mjs (e.g. the +server also has export const MY_SETTING = 'MY_SETTING' that will be in dist/server/index.mjs)

I agree with that. When custom: true then +server is the entry point (no wrapping whatsoever). It's important and I 100% agree here because custom: true is about giving max control to users.

[rtritto]

@brillout so the steps of this feature on Vike's side should be:

1. disable UD
2. support exports in +server
3. build dist/server/entry.mjs and inject it (import 'virtual:vike:global-entry:server') in dist/server/index.mjs

The user have to choose:

• manual config → use renderPage in api/ssr.js (see api/ssr.ts in the example repository)
• zero config → use the vike server middleware (e.g @vikejs/hono) in the +server and in api/ssr.js import the server app from dist/server/index.mjs

Am I right?

[brillout]

The only goal of +server when used with custom: true is to avoid the need for ts-node or Vavite.

[rtritto]

The only goal of +server when used with custom: true is to avoid the need for ts-node or Vavite.

Are you regarding to the point 3? With custom: true, vike will build dist/server/entry.mjs.

[rtritto]

@brillout so the steps of this feature on Vike's side should be:

1. disable UD

2. support exports in `+server`

3. build `dist/server/entry.mjs` and inject it (`import 'virtual:vike:global-entry:server'`) in `dist/server/index.mjs`

The user have to choose:

* manual config → use `renderPage` in `api/ssr.js` (see [api/ssr.ts](https://github.com/mrdsx/vike-with-vercel/blob/3c5a20f33eef2aef26f3288491e2157e2504d457/api/ssr.ts) in the example repository)

* zero config → use the vike server wrapper (e.g `@vikejs/hono`) in the `+server` and in `api/ssr.js` import the server app from `dist/server/index.mjs`

Am I right?

@magne4000 WDYT?

[rtritto]

@brillout @magne4000 with UD disabled (

vike/packages/vike/src/node/vite/index.ts

Line 80 in 8a45c43

...pluginUniversalDeploy(vikeConfig),

as ...serverPlus.custom !== true && pluginUniversalDeploy()), how can we build all page routes (pages folder) of vike?