Wasp-lang•6mo ago

manual deploy gcp

I am trying to manuelly deploy to gcp cloud run and when doing the wasp build i get that the database url is not found but i did set it in .env.server Then when deploying cloud run it says that the app couldnt be deployed kn port 8080 (which i dont know where it gets from) but even when puttin port = 8080 in .env.server

27 Replies

MEE6•6mo ago

Wohooo @tomas.morales, you just became a Waspeteer level 2!

kapa.ai•6mo ago

Hi @tomas.morales. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Hmm, I don't know enough to give you a confident answer yet. However, I can provide some insights based on the information available. The DATABASE_URL environment variable is crucial for your PostgreSQL database connection. It should be provided to the server and the database should be accessible from the server source (https://wasp-lang.dev/docs/advanced/deployment/manually#4-deploying-the-database). The error message you're seeing might be related to an open issue in Wasp where the DATABASE_URL environment variable is not found during the wasp build process source (https://github.com/wasp-lang/wasp/issues/1321). This issue seems to be a duplicate of another open issue where the DATABASE_URL is not found by Prisma during the wasp build process source (https://github.com/wasp-lang/wasp/issues/1282). As for the port issue, currently, Wasp uses default values from CRA and Node for client and server port numbers. There is a closed issue about making these port numbers configurable source (https://github.com/wasp-lang/wasp/issues/146). However, there is an open issue about allowing automatic and/or manual choosing of another port than 5432 source (https://github.com/wasp-lang/wasp/issues/1049). Unfortunately, I don't have specific information about deploying to GCP Cloud Run. I recommend checking the official Wasp documentation or reaching out to the Wasp community for more specific guidance. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @tomas.morales, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

albert6232•6mo ago

what about the firewall rules for opening ports on cloud run

Vinny (@Wasp)•6mo ago

Hi @tomas.morales I'm not familiar with Google Cloud Run. What's your reasoning for choosing it over Fly.io or Railway, for example. We have one-command deploy for your entire app, DB + server + cleint, for fly with wasp deploy fly launch ... and it's all well documented here

Deploying with the Wasp CLI | Wasp

Wasp CLI can deploy your full-stack application with only a single command.

tomas.moralesOP•6mo ago

Its just because i have my infrastructure in google cloud and i understand it could scale easier. Havent used fly before

miho•6mo ago

I think you can get a lot of info by reading this bit in the docs: https://wasp-lang.dev/docs/advanced/deployment/manually It's related to other providers, but it should be useful to understand how Wasp is just a React + Node.js + Postgres app in the end

Deploying Manually | Wasp

This document explains how to build and prepare your Wasp app for deployment.

tomas.moralesOP•6mo ago

Ok thx

Vinny (@Wasp)•6mo ago

How did it go? Were you successful?

tomas.moralesOP•6mo ago

I ended up going with fly for now, in case i need to migrate in the future ill deal with this haha

Vinny (@Wasp)•6mo ago

Ok great. I assume you got everything running successfully then?

tomas.moralesOP•6mo ago

Yep, thanks for your help

martinsos•6mo ago

@tomas.morales , back to your initial issue here: that "database url is not found" during build, that error didn't really stop you from doing anything, right? That is a spurious error actually, I just fixed it recently here https://github.com/wasp-lang/wasp/pull/2070 , but we didn't cut this release yet. But you can in any case just ignore it, it shouldn't be causing you any trouble. As for port 8080 -> that sounds GCP specific, so I don't have an answer out of the box. But I can tell you that .env.server is only for local development -> up there, once you deploy an app, you will want to set those env vars directly up there. So, if GCP expects the server to be listening on 8080, you will have to set PORT=8080 as an env var for the deployed server via whatever mechanism GCP has for that. Check out instructions for deploying server manually here https://wasp-lang.dev/docs/advanced/deployment/manually#2-deploying-the-api-server-backend, this is what you need. But you will also need to undrestand here what GCP expects from you regarding that 8080 port.

tomas.moralesOP•6mo ago

Yes didnt stop me from anything 8080 cloud run default Env vars i just like to keep control of those so i did a script that reads a local env file Everything okay now, thx

TomD•6mo ago

I actually solved the issue you've had with port 8080 on cloud run. The server by default was launching on port 3001, just setting the env variable "PORT" to 8080 solved the issue. Additionally you have to set the appropriate env variable, else the container will fail at the beginning and you'll likely get the same error, this is a bit hard to debug as the log is the same but the reason for it is different ! Nontheless I'm still having some issue, the server is up and running no problem but the frontend doesn't want to work. As I'm on GCP, I deployed the frontend using firebase hosting but I get a blank page. When looking at console logs I get:

index.tsx:1 Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.
saas-example-426610.firebaseapp.com/:33 
        
        
       GET https://saas-example-426610.firebaseapp.com/manifest.json 404 (Not Found)
manifest.json:2 Manifest: Line: 2, column: 1, Syntax error.

index.tsx:1 Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.
saas-example-426610.firebaseapp.com/:33 
        
        
       GET https://saas-example-426610.firebaseapp.com/manifest.json 404 (Not Found)
manifest.json:2 Manifest: Line: 2, column: 1, Syntax error.

I'm going to investigate, if I succeed and I have some time left I'm probably going to document it 🙂 Ok I succeeded finally ! I was deploying the wrong folder, the documentation was clear I just ignored it for some reason 😦

martinsos•6mo ago

@TomD documentation would be awesome! If you can make a PR toward our docs ( https://github.com/wasp-lang/wasp/tree/main/web ) for instructions on deployment to GCP and/or firebase hosting, we would be happy to review it and get it merged. If that is too much "birocracy", even opening an issue on our Github where you document your experience and important steps is already great, as we can then work from there to turn that into the page in the docs. Hah, well maybe it is up to us, could we have made it more obvious in the docs? Maybe mentioned sooner? What were you deploying vs what you should have been deploying?

TomD•6mo ago

It was fine I think. After running npm install && REACT_APP_API_URL=<url_to_wasp_backend> npm run build I deployed the content of .wasp/build/web-app/ and not .wasp/build/web-app/build so the frontend was obviously not what I expected Do you know if there is a way to prefix every routes of the server ? Firebase offer the possibility to do some automatic route rewrites but I must add a prefix for some reason . So I can link the backend and frontend URL only if the backend route looks like this (any prefix would work but /api makes more sense). For example : https://my-super-exceptional-backend.run.app/auth/me --> https://my-super-exceptional-backend.run.app/api/auth/me https://my-super-exceptional-backend.run.app/auth/google/login --> https://my-super-exceptional-backend.run.app/api/auth/google/login etc...

martinsos•6mo ago

Actually I do think we can improve those docs a bit! It isn't emphasized enough that the contents of web-app/build dir should be deployed. I emphasized it now with this commit https://github.com/wasp-lang/wasp/commit/74a2977ad8ce6c0a169c499c64e044dabcd21040, it will come out with the next release. @TomD the thing with the Firebase is tricky! We don't have a built-in way to add such prefix. Interesting enough, we do have support to do it for the client: https://wasp-lang.dev/docs/project/client-config#basedir-string, but we don't have it for the server, as nobody needed it so far. You could maybe do this by adding nginx inside the Dockerfile that would be rewrtiing the routes, and possibly by setting REACT_APP_API_URL for to this url with subdir included, but we haven't tried this out, it could be problematic, I am really just doing a wild guesss here. I wonder how you even got into this situation, why does Firebase require you to do this? How is it even that you are hosting the server on Firebase, I thought you were hosting it on GCP? Can Firebase even host proper server apps, I though it is for hosting static content only?

TomD•6mo ago

Okok, I see the use of nginx. I probably won't go that road and I'll try to find a workaround. Actually, GCP offers "cloud run" that can run the backend. Firebase, since it is a GCP product, offers the possibility to automatically redirect traffic of the website under a specific route, to the cloud run backend. See this documentation: https://firebase.google.com/docs/hosting/cloud-run?hl=en This make connecting the front and back really easy when you have full access on your code usually. Still there is some workaround I guess, I just need to find it

Firebase

Serve dynamic content and host microservices with Cloud Run | Fir...

TomD•6mo ago

I've done this issue to document my journey to deploy it, I've not added the automatic redirect to have the front and back under the same domain name as I'm not completly sure on how to do it yet. https://github.com/wasp-lang/open-saas/issues/178

GitHub

deploy open-saas on Google Cloud Platform (firebase + cloud run) · ...

Hello, I've recently gone through the steps to deploy open-saas on GCP and I believe it could be useful to document it here for now. This could be added to the real documentation in the future,...

martinsos•6mo ago

@TomD it seems a bit weird to me that you have to do this configuration with Firebase. I quickly read the docs you linked and I don't quite get the part with Firebase, it seems to me it is focused on actually using the server to render html when part of your website is accessed, which is not what we need here, we just need it to serve as an API server that is in the background and answers to web client's requests. I also asked GPT :D, and it confirmed this idea that the step with Firebase Hosting is not needed for the server. But let's take that with a grain of salt. My question is, couldn't you get it to work without this step with Firebase? Gave it a look, this is awesome, thanks a lot! Especially the CI action! Aha I see it now in the issue, you say it does work but URL for backend is ugly and not under same domain. Ok, reading more, it indeed seems the way to solve that is to go the Firebase route as you did. So it makes sense to me now. But yeah, Wasp doesn't have built-in support for serving the backend under the directory. Also, did you indeed have any CORS issues? Btw a nice way to do this, and I would say actually a typical/nicer solution, is to set up your cloud run service (server) to be behind the subdomain, instead of a dir. So if you client is currently on example.com, you can put the server on api.example.com instead of example.com/api. I don't think you need to do any Firebase set up for this, instead you will need to set this up on your domain provider (configure DNS records) and possibly set something up on the GCP Cloud Run side, GPT says you will need to set sometihng under "Domain mappings", which sounds reasonable. Yeah, and this is also nice because then you don't have this weird situation of your web client being hosted at example.com but there is this one special route on it under example.com/api that takes you to server, ... . You can ask GPT about using api.example.com vs example.com/api, it is quite good at explaining the pros of the api.example.com.

TomD•6mo ago

Thanks for the brainstorming ! You are right with everything you said, the cleanest way is what you specified with an api.example.com I think. Unfortunately to do this in GCP you need to provision your own load balancer, then you can basically do whatever you want with it with any redirect to subdomains, url rewrite, etc.. I can do this but this cost a something like 5/10 e per month for the load balancer to be up and running, so I'm not going to go that way for now. I believe for clean production, this is definitely the way tho. But to come back to the the idea of having a prefix route, creating a custom api route under '"/api/**" that redirects to the same path but stripping the api would work ? When requesting https://backend-url.com/api/auth/me you would get redirected to https://backend-url.com/auth/me . This is not ideal but this is a minimal workaround I think I didn't with wasp, but for an old website with python fastAPI I went with this approach and I believe I did so I'm always precautious

martinsos•6mo ago

Yeah Wasp is currently made to work accross different domains on purpose, so you shouldn't ahve CORS issues custom api route -> how would you do that, in which tool / tech? I think if you have some kind of redirection, like nxingx that I mentioned, in theory it should work, but I am not 100% that there might not be some edge case. I think there shouldn't actually.

TomD•6mo ago

I'm trying to do something like:

export const redirectApi = (req: Request, res: Response) => {
    console.log('old path', req.path);
    const newPath = req.path.replace('/api', '');
    console.log('new path', newPath);
  res.redirect(newPath);
};

export const redirectApi = (req: Request, res: Response) => {
    console.log('old path', req.path);
    const newPath = req.path.replace('/api', '');
    console.log('new path', newPath);
  res.redirect(newPath);
};

With a new route in the main.wasp file:

api redirectApi {
  fn: import { redirectApi } from "@src/server/apis.js",
  httpRoute: (ALL, "/api/*")
}

api redirectApi {
  fn: import { redirectApi } from "@src/server/apis.js",
  httpRoute: (ALL, "/api/*")
}

martinsos•6mo ago

I tihnk that is a decent try, but it is hard for me to guess at the moment if it will work for all the edge cases! Doing sometihng like nxingx in Dockerfile sounds like a cleaner solution. That said, how did this go for you?

TomD•6mo ago

I tried for a few hours, I couldn't make it work for some edge case indeed.. So I rolled back to use the ugly URL path, if I want to go the clean way someday I'll settle for your recommandation with api.example.com Thanks for the help, if someone ever has a problem to deploy it on GCP I'd be happy to help 🙂

MEE6•6mo ago

Wohooo @TomD, you just became a Waspeteer level 2!

martinsos•6mo ago

That sounds like the best solution! The issue you opened already helps a lot: if you learn something more feel free to add more info there!

Gaming

Programming

manual deploy gcp