This question will be closed soon because it is not a programming question, and the answer is that it depends.

I've considered using Nest.js (which can incorporate either Fastify or Express) but is this needed?

No, to use Fastify you don't need Nest.js.

Is this generally a bad decision?

Do you know Nest.js? If the answer is yes: go for it if you like it. If the answer is no, you will need to learn Nest first, and then you need to learn Fastify if you want to use its features.

Is using Fastify or Express by themselves considered bad practice?

No, I have tons apps in prod in pure Fastify way. The covid APP backend of many nations was in pure Fastify: https://github.com/covidgreen/covid-green-backend-api

Of course, you must know that:

• More layers and frameworks
• = more things to know
• = more things that can go wrong
• = less control of what you can do

Would an overlying framework like Nest.js provide considerably more than either of these alone?

First, I don't like Nest.js because:

• it pins the fastify dependency so you can get fixes until nest will release a new version
• nobody is using fastify+nestjs in a good way because there are tons of unanswered questions on SO
• if you need help, you can't ask to the fastify team. They tell you to ask to the nest team: https://github.com/fastify/help/issues/883

The only pro I see on using Nest.js is that it forces you and your team to write the same code structure and you can't go off those rails.

Meanwhile using pure fastify you can do what you want and your codebase could become a mess (I wrote a book about it, check my profile).

UPDATE - 17.03.2020

We are now running benchmarks for every new PR. One of the latest benchmarks can be found here: https://github.com/nestjs/nest/runs/11029354661

               Req/sec  Trans/sec
Nest-Express    15370   3.17MB  
Nest-Fastify    30001   4.38MB  
Express         17208   3.53MB  
Fastify         33578   4.87MB      

That means Nest + FastifyAdapter is now almost 2 times faster than express.

UPDATE - 22.09.2018

Benchmarks directory has been added to the repository: https://github.com/nestjs/nest/blob/master/benchmarks/all_output.txt (you can run benchmarks on your machine as well).

UPDATE - 24.06.2018

Nest v5.0.0 supports fastify. Fastify + Nest integration is even more performant than plain(!) express.

The following list shows what Nest is doing in comparison to plain express route handler:

• it surrounds your route handler body with try..catch blocks
• it makes every route handler async
• it creates a global express router
• it creates a separated router for each controller
• it binds error-handling middleware
• it binds body-parser middleware (both json and extended urlencoded)

All of the mentioned things reflect a real-world example (probably 99.9% express apps have to do this as well, it's unavoidable). It means that if you want to compare Express and Nest performance, you should at least cover above points. The comparison with the example below:

app.get('/', (req, res, next) => res.status(200).send('Hello world'));

Is unfair in this case, because it's not enough. When I cover these points, this is what I received (express 4.16.2):

Running 10s test @ http://localhost:3000
1024 connections

Stat         Avg    Stdev   Max
Latency (ms) 225.67 109.97  762
Req/Sec      4560   1034.78 5335
Bytes/Sec    990 kB 226 kB  1.18 MB

46k requests in 10s, 9.8 MB read

Additionally, Nest has to:

• recognize whether a result is a Promise/Observable/plain value
• based on the result type, use send() or json() (+1 condition)
• add 3 conditions (if statements) to check pipes, interceptors and guards

There's an output for Nest (4.5.8):

Running 10s test @ http://localhost:3000
1024 connections

Stat         Avg    Stdev   Max
Latency (ms) 297.79 55.5    593
Req/Sec      3433.2 367.84  3649
Bytes/Sec    740 kB 81.9 kB 819 kB

34k requests in 10s, 7.41 MB read

This implies that Nest performance is around 79% express (-21%). This is due to the reasons set out above, and moreover, because Nest is compatible with Node 6.11.x which means that it can't use async/await under the hood - it has to use generators.

Which conclusion is to be drawn based on those stats? None, because we aren't used to creating applications that only returns plain strings without any asynchronous stuff. The comparisons with Hello world means nothing, it's only a titbit :)

PS. I used autocannon library https://github.com/mcollina/autocannon

autocannon -c 1024 -t30 http://localhost:3000