The Lockdown Coder: Deploying My Next.js App With Headless Wordpress
It was time. I had spent the best part of two months working on my app and I was ready to deploy and get it live on the internet. I procrastinated over doing this step for at least a couple of weeks because I felt out of my depth and didn’t know enough about web hosting. There were so many angles to consider and I wasn’t quite ready to get stuck into the weeds again — but I had to.
Hosting Headless WordPress
So far, my WordPress was in the form of a local development site so I needed to get that hosted on a proper server. But wait — if I have many apps each with a headless CMS setup does that mean I need to pay one plan for WordPress and pay another plan to deploy my React app every time? That sounds expensive.
After going around in circles I found my solution lay in sub-domains. The idea is you can use a single domain to set up multiple websites. Perfect! I could pay for one plan for one single domain and have all my WordPress websites running as sub-domains. Each one would be a full-blown website and not a page of a website, which is what I thought it would be initially. For example, you buy one hosting plan and associate it with your domain name of myreactapp.com . Next, you have two WordPress websites you want to create as sub-domains ( wordpressone and wordpresstwo ) so you follow your host’s instructions, set them up and they will be available at wordpressone.myreactapp.com and wordpresstwo.myreactapp.com . Clearly, this is a simplistic overview but I hope it illustrates how it can work.
Now I had a live WordPress site that I could connect my app to via the REST API. I still needed to import all the products I had created and install the plugins but that was straightforward.
Time to deploy the Next.js app
With one hurdle cleared I moved onto the next one: getting my Next.js app deployed. I was building a website, right? So, all I needed to do was find a web host to host it. I had already paid for a plan for my WordPress sites so surely I could continue with them and pay for another plan to host a separate domain for my website. It turned out I hadn’t quite understood what was going on.
My understanding is still a little hazy so I would be grateful for correction in the comments if you know better.
When your Next.js app is ready to be deployed you want to use the npm run build command to compile all your hard work into one neat package containing all the directories and files you need. I was under the impression that all I needed to do was figure out how to get this build package over to my web host. I had paid for a shared-hosting plan and was given some space on a server to use for my website. I figured out how to use FTP to connect to my root directory and the next step was to copy the Next.js build files into the _public_html directory. You might need to edit the .htaccess file but that is essentially it. But, of course, I couldn’t get my website to work.
After some more research, I found a suggestion to use next export with Next.js so I edited my package.json build script to next build && next export and when I ran npm run build I got a ‘static HTML export’ of my app. When I used this build package and followed the steps above it worked! There is a big problem though: none of my API routes worked. The static HTML export is meant for apps that can be run standalone without the need of a Node.js server. All my API routes needed a Node.js server. I checked the documentation and it said, “Next.js can be deployed to any hosting provider that supports Node.js”. OK, I hadn’t appreciated that bit even though I should have.
I was with tsohost.com at this stage and discovered their shared hosting plan did not support Node.js. They did have other plans that supported Node.js but they were expensive as you needed to pay for your own server and not use a shared one — it seemed overkill for my purposes. Never mind, I found a shared hosting plan that supported Node.js with a2hosting.com and was still a reasonable price! I followed instructions to install Node.js and tried to get things configured for my app. No dice. I couldn’t figure it out. I still don’t really know the answer but I think this approach requires my Next.js app to use a custom server rather than the default integrated solution. Shared hosting is the best value option (which is why I chose it) but I couldn’t get it working with my Next.js app.
Vercel knows best
Next.js is owned by Vercel and they have their own hosting platform which works perfectly for Next.js. I did know this but was blinkered to this solution and got fixated on trying to deploy the app in the same way I managed with WordPress. I had convinced myself that Vercel was expensive but, in actual fact, the pricing structure is very reasonable. I thought the pricing was per project but you can deploy multiple projects.
Setting up was pretty straightforward as you can connect to your Github account and choose the repository you want —then any changes that you make to the ‘main’ branch of that repository will trigger an automatic deployment. It only needed to be as simple as that.
I learned a lot about deployment but I still only managed to absorb the bare minimum. What I realised was that although I had created a website that people could visit it really was technically an app and had server-side functionality that needed to be supported. Whenever you want to run server-side code a shared hosting plan is always going to be difficult because the operators don’t really want users running server-side code on shared servers. Getting your own server is an expensive proposition so platforms like Vercel offer an alternative, cloud-based serverless solution. As far as I understand, in a serverless environment your app is essentially hosted in one location and server-side calls (e.g. to API end points) become known as serverless functions. The serverless functions run on the cloud and only execute when they are requested. So, the term serverless can be a bit confusing as you are still executing server-side code and servers are still involved albeit under the guise of cloud technology.
Serverless solutions can also be problematic as I found out. I had a function that created a PDF and saved it to disk so that it could be used later. In development this worked fine as the file was saved in a specified directory on my computer and I knew where to retrieve it from. However, in Vercel saving files to the server is forbidden so I needed to change my app to account for this. There will be other limitations so it’s worth getting acquainted with it to save you a headache later on.
There was a lot to consider but finally I had a working app live on the internet. After extensive testing we were ready to push this app to the public and start receiving orders for the local restaurant. Although there were some inevitable teething issues it was a success!
Part 1: What I managed in 12 months with no coding experience
Part 2: Getting to grips with Flutter
Part 3: Beyond mobile apps and into the web
Part 4: Building on my React foundation
Part 5: Components and classes and hooks, oh my!
Part 6: Next.js vs Create-React-App. (Undercard: Persistent Data)
Part 7: Headless WordPress, WooCommerce and Stripe
Part 8: Deploying my Next.js app with Headless WordPress
