Merging Code and Deploying for Project Midpoint

Time really flies! Before I even knew, the project midpoint check was coming. After 5 weeks of dedication and work, each of our team members had made excellent progress. Though the project still has a long way to go, we really wanted to combine existing functionalities to see a working website. This was not only for the midpoint testing, but we also wanted to integrate our current code base and establish a file structure that we can all follow in the future, which will only make code merge easier in the future.

One person on our team mainly focused on building pet profile related pages and functions, the other teammate worked on building the sign-in and logout system while I took on the sign-up and edit accounts functionalities. As you can imagine, the sign-in and sign-up system were closely tied together so the conflicts were primarily tied to those, but I really appreciate this opportunity to discuss more about our application design.

According to our initial plan, we will have three Datastore entity kinds for each user role – admin, user, and shelter. However, we noticed it was more complicated to implement because all sign-ins share the same login-in UI, which makes it indistinguishable as to which type of user is logging in and which entity kind to call for password verification. After some more research, we also found out that most people recommend having just one entity kind for all types of users but adding user role as a column in the database to distinguish the roles.

Since we decided to combine all user kinds into one entity kind, there were some updates needed. I combined user sign-up and shelter sign-up routes into one register route and added default user type on the frontend. If a user signs up from the user sign-up page, the user type is default to ‘User’. Similarly, the user style is default to ‘Shelter’ when a user signs up from the shelter sign-up page. And, the login issue was resolved!

Last task was deploying the application to GCP, which ended up taking way longer than expected. To combined the React frontend and the Express backend into one single app, I followed the reddit post at this link: https://www.reddit.com/r/googlecloud/comments/bbnpx3/how_do_i_combine_my_react_frontend_and_express/eksn2se/. And yes, I was able to deploy but there were issues.

First of all, the multer middleware for handling image uploads was throwing errors because of file permission issue, which was later fixed by using os.tmpdir for temporary file storage before storing permanently in Google Cloud Storage. Then, I noticed React’s dynamic routing was not working properly. When a user is redirected to say <domain>/pets/viewprofile/:petID, the view profile page isn’t rendering. Instead, it’s processed as a GET request in the backend and returns an error saying it cannot GET the resource. For a quick fix, I just added the following lines of code to our server.js file to have the React app handle the routing instead of the server.

app.use(express.static(__dirname + '/public'));
app.use('*', (req, res) => {
  res.sendFile(path.join(__dirname, 'public', 'index.html'));
});

This experience of having to deploy an application with combined React frontend and Express backend to GCP and to debug issues was valuable to me. It gave me an opportunity to learn more about cloud applications as well as React framework that I would otherwise never have. At the end of the day, the effort was all worth it. We now have a working web app hosted on GCP!

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *