Can Wasp server code be run without docker
Hi after executing "wasp build", i see server and client code getting build in .wasp/build directory.
Deployment of front end code is clar to me, but for server code it seems that it has to be implemented as a docker container. Can i build server code and run it as a normal node js process with pm2 without using docker.
I tried building it and then run from dist folder, but all i get is "hello world" on home page route.
3 Replies
Well Docker is here really just to help with deploying it, but yeah, you could certainly do it on your own.
The best way would be to check the generated Dockerfile and see which steps it does and replicate those by yourself.
So looking at it, most of the steps are just setting up the Dockerfile itself, or copying stuff to Docker container.
But steps that are important for you also are the following:
1.
npm install in the server dir.
2. ... npx prisma generate --schema=... -> I put ... but you can figure out what goes there from your Dockerfile.
3. npm run build
Basically you want to install npm deps, generate prisma schema, and then npm run build, that is what the steps above do.
Finally, in our Dockerfile we run npm run start-production -> check that command in package.json to see if there is anything you care about there, that you should also "steal".
As for the expected result: Actually, "hello world" on home page route is fine!
Server is an API server -> client needs to be running separately. Client is just static files, so either you run it on some provider that runs static files, or you run it via simple server that serves those static files.
Client will consume the API from server.
Some more info on deployment here: https://wasp-lang.dev/docs/advanced/deployment/overview .
Btw why don't you want to run the server via Docker, what is the motivation not to do it?Great...thanks a ton!! really helps.
Awesome, let us know if you need any more help!
Btw I am still curious, what is the reason why you don't want to go via Docker? I am interested, because if we understand the use case better, we maybe possibly offer better support for it.