Nuxt.js: Fastify Custom Server

[nahtnam]

What problem does this feature solve?

It would be nice to have a custom server for https://www.fastify.io. It's really fast and pretty popular.

What does the proposed changes look like?

There would be one more option in the nuxt cli to choose fastify as the server option.

_{This feature request is available on Nuxt community (#c8600)}

[pi0]

Nuxt.js uses the most minimal and low-level possible implementation, connect. You can always compose the middleware stack with your own favorite server. BTW we _may_ consider doing this for Nuxt3 because of native async/await support. Thanks for the issue.

[emansayed913]

@ 1s

[pi0]

(Comment by @sh )

We're running different services in our stack that all can share common middlewares (session, csrf) thanks to nuxt's connect compatibility.

We're also using nuxt as middleware in our express server. This allows us to have automatic request tracing through GCP Stackdriver Trace Agent for Node.js which is a massive help for debugging and measuring issues in production. As it stands there is no fastify tracing plugin available, migrating to fastify (without the option of still using connect) would be a massive drawback for us.

I'm not sure how much of a gain fastify (besides having a bit more req/s in benchmarks compared to connect/connect-router) really would be as it breaks the compatibility with the proven connect/express ecosystem.

I'd vote for support of both frameworks (connect+fastify) or stay with connect if this change introduces too much complexity.

[sh]

Thanks for copying this over @pi0 🎉

I'd also like to add the fact that the benchmarks are running against a simple middleware responding with "hello world".

I simply can't imagine a scenario where connect would become a performance bottleneck for nuxt. Running a separate app without nuxt to serve api / graphql requests is the way to go.

Most of the time SSR requests for simple pages are served < 100ms by nuxt.

The slowest requests are pages with several components that require data to be prefetched via asyncData / vue-apollo. Our graphql endpoint responds < 200ms however ~600ms are spent populating data/ rendering and sending the response to the client.

nuxt served through connect is stable and super fast, improvements in other places will probably yield much higher performance gains

[nahtnam]

Fair enough, I figured that a Fastify implementation wouldn't be that complex considering it supports express/koa middleware

[sh]

Having support for both via dynamic import (as suggested by @clarkdo in #5066) would be great.

Not sure how much work is required to ensure both versions are well tested and how the distribution via nuxt-start / @nuxt/server would work.

Maybe @nuxt/server-core, @nuxt/server-connect and @nuxt/server-fastify?

[pi0]

Tradeoff about package install size:

• Connect:
• Fastify:

Also cold startup time should be measured

[aldarund]

Is there any real benefit for using fastify? I really doubt it will bring any perf increase in real part. Well, even on hello world i dont think there would be meaningful difference.
Is there any other reason to use fastify than speed?
As i remember cold startup on fastify was higher.

[nahtnam]

Hmm, so looking here: https://github.com/fastify/benchmarks#benchmarks Connect is within 7% of fastify in terms of benchmarks.

Why not leave connect as the default but add fastify as an option in the cli when bootstrapping a new program?

[sh]

Considering the package install size and cold startup time I'd prefer to just have connect.

It should be possible to use nuxt as middleware for fastify by following the custom-server example and replacing express with fastify.

[manniL]

@sh this approach will be deprecated soon. Use serverMiddleware or a standalone server instead.

[sh]

@manniL is there an example/docs for standalone server if this approach becomes deprecated?

[manniL]

@sh you can use any standalone API you want with Nuxt by calling it with axios during asyncData or whatever. We don't provide guides for standalone APIs as that's far out of the scope.

For serverMiddleware, probably. But that's only recommended for smaller projects.

PS: Read more about my personal take on that if you want :)

[sh]

@manniL sorry for not being clear, we're happily running a standalone api process besides our frontend

I figured the custom server example was simply to provide an example of running nuxt as a middleware inside express/fastify/others.
Now I'm wondering if using nuxt programmatically is going to be deprecated? :)

[manniL]

Now I'm wondering if using nuxt programmatically is going to be deprecated? :)

It will be.

[pbastowski]

@manniL
Hi, I just read that using Nuxt programmatically, that is as an express sever middleware, will be deprecated in the future. What will replace it for the case that I describe below?

I actually use this feature in situations where there is an existing express based server with whatever frontend and I want to migrate that frontend to Vue. In that case, I add Nuxt as the last middleware and then let it render certain routes that I wish to refactor to Vue, while the remainder of the app continues to be unaffected.

Please note that I am not able to replace the whole app's express backend with a Nuxt server, because it may have custom authentication and authorisation code and refactoring such would be ill-advised.