How would the Environment API fit in a project with an admin UI, SSR, and REST API?

[hdodov]

The new Environment API seems great, but I have a question — how would that work when you want to have a production server with middleware, for example, and other custom functionality?

Let's say that I want to build something similar to WordPress — an app that has the following responsibilities:

• Store stuff in a database
• Provide an admin UI for non-tech people
• Handle the actual rendering of pages in real time (SSR)
• Expose a REST API for external integration

For simplicity, let's say that all of the above happens on production on just on a single Node.js server. No Cloudflare workers and other cloud stuff. Just like WordPress — one PHP server and that's it.

How would Vite fit in such a project? Which parts would it be able to handle and which ones would I have to take care of myself?

1. Would Vite offer a server with extensible middleware to handle routing / redirects / REST API?
2. Would Vite be able to render pages in real time (SSR), e.g. with Vue/React/Preact/whatever?
3. Would Vite be able to handle the front-end bundle as well, e.g. for highly interactive stuff in the admin UI?
4. How would all of the above work in dev mode (with hot reloading) vs prod mode (with minification)?

In general, how would you build something like that with the new Vite?

I just trying to get my head around all that and figure out how the new stuff in Vite would work. I'm excited either way, though! Thank you!!

[sapphi-red]

If you are building an application that only runs on a single Node.js server, the Env API doesn't add much features. It has a more consistent design and the ability to run the build for Node and browser in a single vite build command, but I think that's it. The Env API is probably beneficial for users who want to run a bundle in non-Node.js runtime, or need to handle more than two bundles. In your case, you are fine with running it in a single Node.js server, so you can use APIs that existed before the Env API was introduced. If you are going to separate the server into multiple servers, for example, a REST API server and a SSR server, it is better to use the Env API.

Would Vite offer a server with extensible middleware to handle routing / redirects / REST API?

No, Vite only handles the bundling part.

Would Vite be able to render pages in real time (SSR), e.g. with Vue/React/Preact/whatever?

Yes, but you need to call the SSR APIs from the rendering frameworks and connect it to the client bundle on your own.

Would Vite be able to handle the front-end bundle as well, e.g. for highly interactive stuff in the admin UI?

Yes, Vite can still handle that.

How would all of the above work in dev mode (with hot reloading) vs prod mode (with minification)?

The dev setup will be something like the example in https://vite.dev/guide/api-environment-frameworks.html#default-runnabledevenvironment. The build setup will be something like the example in https://vite.dev/guide/api-environment-frameworks.html#environments-during-build.

[hdodov]

I think I get it. So I'd have a regular Express server (which would handle the REST API stuff) and just have Vite hook into it to build/hot-reload assets in dev mode and do SSR in prod mode? From what I gather, this is what essentially happens in this example.

By the way, could Vite be used without Express? Or with a different framework like it?

Thank you for taking the time to answer so thoroughly!!

[sapphi-red]

So I'd have a regular Express server (which would handle the REST API stuff) and just have Vite hook into it to build/hot-reload assets in dev mode and do SSR in prod mode?

Yes.

By the way, could Vite be used without Express? Or with a different framework like it?

It should be possible. Vite's middleware can be directly used by connect compatible frameworks.

[hdodov]

Hm, now that I think of it, it might be better to build on top of Nuxt, no? All of the Vite complexity in terms of bundling, hydration, etc. would be handled and maintained already.

If the main problem space I want to focus on is the management, routing, and rendering of content, then Nuxt seems like a better starting point? Similar to how Payload CMS essentially functions as a Next.js project that you build on top of. Except I'd be using Nuxt as the foundation here.

Anyway, that's up to me to experiment with and figure out. Thanks for the help again!

[sapphi-red]

Yeah, if you don't have any special requirements, I'll recommend using meta-frameworks such as Nuxt.