With the Project Midpoint fast approaching, I had two main objectives: get my portion of the project to a state where it at least looked like it could, at some point in the future, function as a game, and host the app somewhere that our project sponsor and the grading team could interact with it. Up until this point, my Phaser app had only functioned in a local environment. More than that, this was going to be the first time that any app that I had ever made would be hosted outside of a local environment.
Luckily for me, my team members had much more experience in this regard, and were willing to assist me. One of them suggested a service called Heroku, which they claimed would be easy. At this point nothing about the situation seemed easy, but I was willing to give it a try.
Using Heroku for the First Time
Heroku is a web-hosting service, where you can send them your code, and they will host it using their servers, allowing access to your app from anywhere, at any time. Signing up was easy, though Heroku requires more from potential users than a service like Amazon Shopping or Gmail. Two-factor authentication was mandatory, which I found interesting.
Heroku operates using a system that they call “dynos”. Essentially, the server power that you are renting is expressed in these dyno units, with payment plans ranging from a single dyno, to a huge number for commercial-scale apps. They even have an “eco-dynos” option where you pay per access time used, for extremely small-scale personal projects. For our project, I opted for the single dyno. There shouldn’t be too much traffic, but I would like my project team and the project sponsor to be able to access it at any time.
Once the dyno had been acquired, I had to actually deliver a version of my code that Heroku can run. This is a build of the program that is compressed into a distribution directory, in my case named dist. It sounds easy enough, just run “npm build” and call it a day, but there were some changes that needed to be made, both to the source code and the distribution directory.
Firstly, the app internally uses a lot of network communication. In the pre-deployment version, the app was talking to itself over two local ports, for the Mid-Project release, those references would need to be updated to point to Heroku. Secondly, there were assets referenced within the app that would not carry over to the dist folder. My solution to this issue was crude but effective: I simply built the distribution and then copied the assets folder into it. While there are probably more elegant workarounds, I needed it to work, and work it did.
Sometimes it is That Easy
After those changes, it was as easy as uploading a Github reference to Heroku! The service can host the code from a GitHub repo, which made the whole process almost painless.
I hope that this post has inspired someone who has never hosted an app online to give it a try! It was much simpler than I initially thought, and the end result of seeing a live app hosted non-locally was amazing!
Leave a Reply