Thank you, Martin, I thought it was an excellent introduction to how to deploy a React app to Google Cloud for someone who had never done it, it really helped to get me started. However, I want to bring everyone's attention to 13:57 where it is said the Load Balancer integration incurs a min monthly cost of $20. I personally needed only to connect a domain to my WIP app so I immediately followed the steps first, and if I didn't listen carefully later I would end up paying that extra $20 to Google without even knowing it. In my opinion, such important information should be presented upfront, as clearly as possible, rather than just being mentioned passingly. Otherwise, great video!
You can also use Firebase Hosting to point your custom domain to your Cloud Run service. It does not incur a fixed monthly cost. Search for "firebase hosting cloud run" and you will find the right docs.
Thanks, Martin really appreciate the practical example! The info about pricing and the extra 3 optional steps were really helpful. I'd like to see a similar tutorial with pub/sub in future videos.
Such a great intro to cloud run. I worked with GCP on my last project, but I wasn't part of devops so I only know a little bit about it. We would deploy from Github to Cloud Run and had different environments. This helps me understand a bit more about the process. Thank you, your videos are really good.
Looks like I made a mistake when editing this video. The index.js file should be in the pirate-app directory and it should not be moved. Sorry about that.
Thanks Martin. What about the pros and cons of deploying separate Cloud Run services (For React and Server side Express) versus your approach of packaging both frontend and backend in a single image? With a single service it is a very simple architecture and perhaps lower costs but regardless of changes with only Frontend aka FE (React) only Backend aka BE (Express) entire app still needs to deployed. The advantage of using separate Cloud Run services is that it provides individual scaling of FE and BE plus the flexibility of deploying only FE or only BE with increased security by having the option to make the BE service internal ONLY but yes complex architecture in setting up service to service communication.
Good points! I think you summarized the pros and cons very well. Three more thoughts: 1. CI/CD and rollbacks become easy if your application is a single container. In many web apps, the front-end and back-end are tightly coupled with each other, so deploying one without the other may not be a strong need, and it may make automated testing difficult. 2. On the other hand, I have heard from some teams that want to let web designers deploy new graphics without being part of the CI/CD pipeline. In that case it may be useful to store the graphics outside the container, like in a Storage bucket. That bucket can be used by multiple web apps, making it easy to update a logo for all apps at once. 3. Independent scaling of backend vs frontend is useful if you are managing virtual machines, less so in serverless where scaling is automatic.
@@TheMomander Thanks so much Martin appreciate your reply. One other question I have is whether it is possible to use the googel-auth client library on client side more specifically in a React JS CR service deployed as a public front end service or is it supposed to work server side?
@@dheer211 Firebase Authentication is meant to be deployed on the client and works well with React. If you prefer more enterprise features (and don't mind paying a little more) you should check out Google Cloud Identity Platform. Both products use the same client-side libraries, so it's easy to switch between them.
Рік тому+1
11:48 after deploying and folowing the link I get a 404 instead of the react app, but the API works fine. It looks like google cloud did not use the dist folder. Any ides?
This is most likely because you don't have a .gcloudignore file in your root project folder. When that file doesn't exist, gcloud will default to your .gitignore file. Your .gitignore file most likely has the "dist" folder in it to exclude. So that is why the folder does not exist. You can basically just copy paste your .gitignore file into a .gcloudignore file, but remove the "dist" folder from it.
Either App Engine or Cloud Run would work. If you are familiar with one of the two, use that one! If you are equally familiar with both, or you haven't tried either yet, I would go with Cloud Run. Cloud Run is more modern, it is container-based, and it gives you more freedom, for example to include binary libraries.
Hi Martin! Thank you so much for the great video. I run into an error at around the 11:00 minute mark. I get the error that the user-provided container failed to start and listen to the correct port. What can I do to ensure the container starts? Does GCP build a container for me when I follow the instructions in this video?
Yes, Google builds the container for you. You can go to the Cloud Console and check the logs (hamburger menu in the upper left, then Logging, then Log Explorer). Most of the time when I get the error you described it's one of these two causes: 1. I forgot to include *"start": "node index.js"* in the scripts section of package.json of the Express app. Google is looking for that script and will run it to start your container. See 5:54 in the video. 2. I used *import* in my code (instead of require) and I forgot to add *"type": "module"* in package.json of the Express app. Hope this helps!
Great video! The new load balancer integration is nice, but even if Cloud Run creates all the necessary resource types for you, it doesn't solve the problem that understanding and configuring a load balancer is still a very complex task.
I agree that configuring a load balancer from scratch is complicated, and I personally avoid it. But if you click the "Integrations" tab like I did in the video at 13:13, all you have to do is fill out a single form. Google Cloud does complicated parts for you.
@googlecloudtech - I had a question ... I built a react website with no backend(no server code) and simply hosted it on cloud run with a domain I had purchased. Is there any downside in this type of deployment? What I am wondering is security? How should I do a user authentication within FE? If I have to create another service on cloud run for authentication, How would i secure the communication between the 2 services (react app FE and user authentication service).
Your deployment sounds good. For authentication, I propose you implement Firebase Authentication. Once that is done, whenever your front-end code is sending a request to your backend code, attach a token from Firebase Authentication to that request. In your backend code you'd validate the token, which would give you the ID of the user. Do a web search for "firebase authentication verify id tokens" and you will find sample code. Best of luck with your project!
Yes, it is. I shot another video titled "Run your Next.js app on Cloud Run" which shows how to set up continuous deployment for React apps on Cloud Run. Do a UA-cam search for it and have a look. Best of luck with your project!
Thank you for the suggestion. If you search for "Hosting a REST API with a Cloud Firestore backend" and "Cloud Run + Cloud SQL, setup" here on UA-cam you will find two videos that address those scenarios. Hope you'll find them helpful!
I'm able to get the front and backend working together on localhost, but the landing page of the React app isn't hit when deployed to Google Cloud with "error": "Sorry couldn't find /". The error is looking for my home route which was never set. Should I create a home route and send the index file? I wouldn't think so since it's working nicely together on localhost. Maybe a Google Cloud setting?
@@MrGudmestad Here are the two things I would check in this situation: 1. Did you include the express.static("react-app/dist") call at 3:53 of the video? 2. Seen from the Node.js app's directory, does "react-app/dist" point to a directory that includes an index.html file?
@@TheMomander Thank you for the reply! Yes, I absolutely completed item #1 on your checklist and without that line of code, the React App doesn't work on localhost. I am confused a little by #2 though. Yes, there is an index.html file inside of my dist folder. Again, the weirdest part in my view is that the React App does work on Localhost but not on Google Cloud.
Hi, I am having problem deploying the App. Deployment failed ERROR: (gcloud.run.deploy) FAILED_PRECONDITION: failed precondition: due to quota restrictions, cannot run builds in this region. Please contact support. When I check it seems I have quota, I am not sure why this happening
Subscribe so you never miss an episode of Serverless Expeditions! → goo.gle/GoogleCloudTech
I was literally dying to see someone let me go through this process. Thanks a lot
Happy to hear it was useful!
Thank you, Martin, I thought it was an excellent introduction to how to deploy a React app to Google Cloud for someone who had never done it, it really helped to get me started. However, I want to bring everyone's attention to 13:57 where it is said the Load Balancer integration incurs a min monthly cost of $20. I personally needed only to connect a domain to my WIP app so I immediately followed the steps first, and if I didn't listen carefully later I would end up paying that extra $20 to Google without even knowing it. In my opinion, such important information should be presented upfront, as clearly as possible, rather than just being mentioned passingly. Otherwise, great video!
You can also use Firebase Hosting to point your custom domain to your Cloud Run service. It does not incur a fixed monthly cost. Search for "firebase hosting cloud run" and you will find the right docs.
Thank you, this is key.
Thanks Martin. Very helpful for someone new to deploying to the cloud.
Happy to hear it was useful!
thank you Mr.Martin Omander for this helpful video
Thanks, Martin really appreciate the practical example! The info about pricing and the extra 3 optional steps were really helpful. I'd like to see a similar tutorial with pub/sub in future videos.
Thank you for the suggestion! Happy to hear you found the video useful.
Absolutely amazing video for anyone to get started with how to build and deploy an app on google cloud
Happy to hear you found it useful! You may also want to check out our video "Run your Next.js app on Cloud Run".
Such a great intro to cloud run. I worked with GCP on my last project, but I wasn't part of devops so I only know a little bit about it. We would deploy from Github to Cloud Run and had different environments. This helps me understand a bit more about the process. Thank you, your videos are really good.
Happy to hear the video was useful to you!
why did you switch the locaiton of index.js from being i the pirate-app directory to react-app/src at 3:50?
Looks like I made a mistake when editing this video. The index.js file should be in the pirate-app directory and it should not be moved. Sorry about that.
Thanks Martin. What about the pros and cons of deploying separate Cloud Run services (For React and Server side Express) versus your approach of packaging both frontend and backend in a single image? With a single service it is a very simple architecture and perhaps lower costs but regardless of changes with only Frontend aka FE (React) only Backend aka BE (Express) entire app still needs to deployed. The advantage of using separate Cloud Run services is that it provides individual scaling of FE and BE plus the flexibility of deploying only FE or only BE with increased security by having the option to make the BE service internal ONLY but yes complex architecture in setting up service to service communication.
Good points! I think you summarized the pros and cons very well. Three more thoughts:
1. CI/CD and rollbacks become easy if your application is a single container. In many web apps, the front-end and back-end are tightly coupled with each other, so deploying one without the other may not be a strong need, and it may make automated testing difficult.
2. On the other hand, I have heard from some teams that want to let web designers deploy new graphics without being part of the CI/CD pipeline. In that case it may be useful to store the graphics outside the container, like in a Storage bucket. That bucket can be used by multiple web apps, making it easy to update a logo for all apps at once.
3. Independent scaling of backend vs frontend is useful if you are managing virtual machines, less so in serverless where scaling is automatic.
@@TheMomanderThanks for the video. Can you please make a video on React/Postgres security on GCP like DDoS, Firewall, https, encryption etc.
@@rakab2010 Thank you for the suggestion!
@@TheMomander Thanks so much Martin appreciate your reply. One other question I have is whether it is possible to use the googel-auth client library on client side more specifically in a React JS CR service deployed as a public front end service or is it supposed to work server side?
@@dheer211 Firebase Authentication is meant to be deployed on the client and works well with React. If you prefer more enterprise features (and don't mind paying a little more) you should check out Google Cloud Identity Platform. Both products use the same client-side libraries, so it's easy to switch between them.
11:48 after deploying and folowing the link I get a 404 instead of the react app, but the API works fine. It looks like google cloud did not use the dist folder. Any ides?
This is most likely because you don't have a .gcloudignore file in your root project folder. When that file doesn't exist, gcloud will default to your .gitignore file. Your .gitignore file most likely has the "dist" folder in it to exclude. So that is why the folder does not exist. You can basically just copy paste your .gitignore file into a .gcloudignore file, but remove the "dist" folder from it.
@@JJTrades_Xthanks a bunch!
great tutorial . thanks
Is there a difference between deploying to Google's Cloud Run service and Google's App Engine service? When should you use one or the other?
Either App Engine or Cloud Run would work. If you are familiar with one of the two, use that one! If you are equally familiar with both, or you haven't tried either yet, I would go with Cloud Run. Cloud Run is more modern, it is container-based, and it gives you more freedom, for example to include binary libraries.
Hi Martin! Thank you so much for the great video. I run into an error at around the 11:00 minute mark. I get the error that the user-provided container failed to start and listen to the correct port. What can I do to ensure the container starts? Does GCP build a container for me when I follow the instructions in this video?
Yes, Google builds the container for you. You can go to the Cloud Console and check the logs (hamburger menu in the upper left, then Logging, then Log Explorer). Most of the time when I get the error you described it's one of these two causes:
1. I forgot to include *"start": "node index.js"* in the scripts section of package.json of the Express app. Google is looking for that script and will run it to start your container. See 5:54 in the video.
2. I used *import* in my code (instead of require) and I forgot to add *"type": "module"* in package.json of the Express app.
Hope this helps!
thank you! 🥰🥰
Hi! Martin, really like the videos. How about create a terraform version with github action for this template integration:)
Thank you for the suggestion!
I love this solution.
Happy to hear you found it useful!
Great video! The new load balancer integration is nice, but even if Cloud Run creates all the necessary resource types for you, it doesn't solve the problem that understanding and configuring a load balancer is still a very complex task.
I agree that configuring a load balancer from scratch is complicated, and I personally avoid it. But if you click the "Integrations" tab like I did in the video at 13:13, all you have to do is fill out a single form. Google Cloud does complicated parts for you.
@googlecloudtech - I had a question ... I built a react website with no backend(no server code) and simply hosted it on cloud run with a domain I had purchased. Is there any downside in this type of deployment? What I am wondering is security? How should I do a user authentication within FE? If I have to create another service on cloud run for authentication, How would i secure the communication between the 2 services (react app FE and user authentication service).
Your deployment sounds good. For authentication, I propose you implement Firebase Authentication. Once that is done, whenever your front-end code is sending a request to your backend code, attach a token from Firebase Authentication to that request. In your backend code you'd validate the token, which would give you the ID of the user. Do a web search for "firebase authentication verify id tokens" and you will find sample code. Best of luck with your project!
Is it possible to deploy this application on Google Cloud Run with the Continuous Deployment button and GitHub?
Yes, it is. I shot another video titled "Run your Next.js app on Cloud Run" which shows how to set up continuous deployment for React apps on Cloud Run. Do a UA-cam search for it and have a look. Best of luck with your project!
@@TheMomander Thank you so much for making a video about this topic! I am looking forward to watching the video and following the steps.
Please give tut on database integration with gcp both sql & no sql
Thank you for the suggestion. If you search for "Hosting a REST API with a Cloud Firestore backend" and "Cloud Run + Cloud SQL, setup" here on UA-cam you will find two videos that address those scenarios. Hope you'll find them helpful!
I'm able to get the front and backend working together on localhost, but the landing page of the React app isn't hit when deployed to Google Cloud with "error": "Sorry couldn't find /". The error is looking for my home route which was never set. Should I create a home route and send the index file? I wouldn't think so since it's working nicely together on localhost. Maybe a Google Cloud setting?
When I navigate to /index.html, it returns "error": "Sorry couldn't find /index.html" - It just seems that Google Cloud doesn't see my React App
If I create a home route and res.send('hello world") and the browser will receive that instead of my React App 😑
@@MrGudmestad Here are the two things I would check in this situation:
1. Did you include the express.static("react-app/dist") call at 3:53 of the video?
2. Seen from the Node.js app's directory, does "react-app/dist" point to a directory that includes an index.html file?
@@TheMomander Thank you for the reply! Yes, I absolutely completed item #1 on your checklist and without that line of code, the React App doesn't work on localhost. I am confused a little by #2 though. Yes, there is an index.html file inside of my dist folder. Again, the weirdest part in my view is that the React App does work on Localhost but not on Google Cloud.
@@MrGudmestad Have you had a chance to check the server-side log in the Google Cloud Console? There may be clues in that log.
This is great! Could you please make text-music or text-text or text-image ai apps with react native and then publish on gcp? Thank you, sir.
We just released such a video. Do a UA-cam search for "Serverless Generative AI" and you will find it!
And to do it with React and NextJS ?
That's a great idea. I will add it to my list of upcoming episodes. Thanks for the suggestion!
We face difficulty to host out react js website built on vs code...
How do you deploy a react application with a python server all with google cloud run?
actually I figured it out
@@Christina-fg4jp That's good to hear -- well done!
google cloud says [Error: ENOENT: no such file or directory, open './dist/client/index.html'] {
Nice!
great video
Great, thanks
Awesome!
Astro + Vercel.
1 cmd
BS
Hi, I am having problem deploying the App. Deployment failed
ERROR: (gcloud.run.deploy) FAILED_PRECONDITION: failed precondition: due to quota restrictions, cannot run builds in this region. Please contact support. When I check it seems I have quota, I am not sure why this happening
Not sure what is happening. I propose you post your question in the Google Cloud sub-reddit.