The date has finally arrived, the deadline to submit my solo project for assessment by Chingu to determine whether I deserve to be in the Full Stack Development tier. To be honest, I was getting scared that I wouldn’t be able to complete it in time as I was having difficulty deploying both my back-end and front-end to Heroku. I’ve managed to launch two applications on the platform so I thought it would be easy to do it again, but instead I realized I had a lot more to learn about deploying.
The first task was deploying my back-end, which went a lot smoother than my last attempt as I detailed in this blog post. I did have to update Ruby again, but the Heroku build was successful and it went live after two attempts. Except after testing some fetch requests from my front-end, some problems began to arise, mainly with authenticating users. After many attempts at fixing the problem, I realized the JWT tokens were not set up properly and not matching with Cookies being sent over by the browser.
Originally, I had set the token to a variable stored in a dot-env file as I had seen performed by another developer in their blog post about setting up JWT tokens. While this solution worked in my local environment, it wasn’t the correct technique for an external host. As detailed in this blog post, the JWT should be set as Rails.application.credentials.jwt_key
which can then be set privately through the terminal by executing EDITOR=”code --wait” rails credentials:edit
. This will open a credentials file that is not accessible by the directory, and where the JWT key should be stored for safekeeping. A truly awesome feature that makes complete sense when done properly, and of course fixes everything.
After my back-end was working properly with my front-end hosted in a local environment, it was time to tackle deploying said front-end to Heroku, and my first few attempts were coming up empty. It would barely build itself and the errors I received didn’t seem very common to other developers on StackOverflow or elsewhere. It wasn’t until I began carefully reading about my chosen buildpack, Create-React-App-Buildpack by mars that I realized my stupid mistake.
I had used this buildpack before to launch my front-end for my personal portfolio website, of course I had chosen it for it’s proven track record. Except, as detailed in the purpose section at the top of the ReadMe file, the buildpack was not designed for a React application “with a server-side backend (RUBY!)” This is why it is very important that to read the instructions before trying to force an application to perform an action it is incapable of performing.
Again, another simple fix finally allowed my front-end to be built and deployed on Heroku, just by including the Node.js buildpack on Heroku. :-) But again, the website was still not working properly, as I realized the procfile
needed to be updated as well to boot the application upon launch. Simple enough, it was the same command to start the application locally, web: npm start
. As I read, web
is very important to basically signal that the application is being launched on an external website or browser.
This however wasn’t the only problem with my website, it was also timing out before it could launch. I narrowed it down to my application not setting up a port for the website as is usually performed in Node.js server. Frankly, it seemed like too much work to define it in my index file, especially considering it was never taught in any previous lessons at Flatiron.
I also knew it had to do with my package.json
file where the start commands were defined. I eventually had a eureka moment when I defined the localhost address in my scripts to originally coordinate with my back-end. Because the default host is the same for both my front-end and back-end when working in a local environment, it was necessary to set it for them to work properly. But this was also causing my website to crash.
Finally, my website was displaying properly and I could login and make new records, with plenty of hours to spare. There was some minor tweaking and errors to be fixed, but eventually it was good enough to be submitted for assessment by Chingu. I still need to make some improvements to it, including finding a cookie image to display in my calendar, but I was proud to get it launched and confident I could do it again. Even after tearing my hair out and losing some sleep over it, I learned a lot and can’t wait to do it all over again.
Top comments (0)