Open davidmeirlevy opened 2 years ago
Hi @davidmeirlevy! Isn't that something that you define in your Fastify instance?
For instance, if you look at the React.js starter:
import Fastify from 'fastify'
import FastifyVite from 'fastify-vite'
import FastifyDXReact from 'fastify-dx-react'
const server = Fastify()
server.decorate('db', {
todoList: [
'Do laundry',
'Respond to emails',
'Write report',
]
})
server.put('/api/todo/items', (req, reply) => {
server.db.todoList.push(req.body.item)
reply.send({ ok: true })
})
server.delete('/api/todo/items', (req, reply) => {
server.db.todoList.splice(req.body.index, 1)
reply.send({ ok: true })
})
await server.register(FastifyVite, {
root: import.meta.url,
renderer: FastifyDXReact,
})
await server.vite.ready()
await server.listen(3000)
You're free to set a port at the Fastify level:
await server.listen(process.env?.PORT ?? 3000)
is that what you were referring to?
Yep. @galvez changed it. On the previous version (aka fastify-vite), the server instance wasn't managed by the app itself but from the library.
I then exposed the port and ip from my server file, and the package used them: https://github.com/greenpress/greenpress/blob/dev/apps/front-ssr/server.js
I need to change fastify-vite to dx, but unfortunately it will take me a week or two.
@micheleriva We also have a prototype for a CLI (the dx
CLI) that automates setting up a vanilla server. I'll revisit it once I've wrapped work on the actual framework adapters, which allow for the standalone usage of Fastify DX. The dx
CLI will just help avoiding some of the boilerplate. This issue talks about the CLI configuration, not the individual Fastify DX framework adapters (fastify-vite renderer adapters).
Renamed this issue and added cli
label.
Just a follow up on this issue — I've been working on getting fastify-cli
as part of the starter templates. I have an experimental new CLI in the works, but that'll take time and I don't want to rush it. So it makes sense to get it going with fastify-cli
for the time being, which addresses this issue. I'll close when it gets done.
The fallback for the default port should first fallback to process.env.PORT || 3000, and not directly to 3000.