My Journey from PHP & Wordpress to FullStack Javascript

For my first fullstack javascript app I built, Power Todos, a more advanced personal todos app than the typical beginner todos app. It tracks tasks for every todo and can store notes for every task. It was built with React, Express, Node, Postgres. It uses Redis, Redux, React Router and more…

My Background in Programming: PHP, JS, jQuery

My specialty has been search engine optimization. I am hyper aware of small things such as compressing css and js files, properly sizing and minimizing images, descriptively naming URLs, using proper 404 pages and headers, blocking bad bots in the robots.tx file, writing clear h1-h5 headers with organized, keyword dense paragraphs, while always maintaining a clear dom hierarchy, using proper anchor texts in links and creating a buzz to get as many other websites linking back to your site as possible.

However, that skill has lost much of its significance the past few years. Now, all that really matters is social traction. And I would be a great social media supervisor, if I didn’t loathe social media.

I am proficient with vanilla javascript, jQuery and AJAX, though I strayed from programming altogether when the industry took a turn towards OOP. I have built some pretty comprehensive php sites from scratch with no framework, which forced me to learn the ins and outs of things like encrypting passwords, verifying registrations via email confirmation using tokens, storing sessions on the server, keeping users logged in with cookies, and the biggest headache of all, dealing with dreaded cross-browser compatibility issues.

I was about to make the switch to Node/Express a couple years ago, and then PHP 7 came out. It allocated memory better than ever and my servers’ loads were eased, making a switch to a different technology unimportant. Scaling was not as much of a problem with the use of SSD hard drives, meanwhile, simple increases in RAM made my sites run super fast. And then there was the holy grail of all performance optimization techniques: caching sql queries and results. So I never felt the need to move my companies to fullstack JS or any other technology after that.

And Then There Was Node

So for the past two years I have studied JS extensively. I read everything by Eric Elliott (about ten times each). I ran through FreeCodeCamp a couple times, took a number of Udemy courses, watched and followed all the Fun Fun Functions, did 30 in 30 by Wes Boss, and I even joined the Hack Reactor bootcamp remotely. Ps — the free prep course Hack Reactor requires before entering is one of the best javascript training tools on the web. But, I dropped out of Hack Reactor the day before classes were to begin because my wife and I excitedly learned we were pregnant with our first child!

A few months after my boy was born I dove back in to learning, this time with more determination to follow through and a better base knowledge of javascript in general. I decided it was time to start building things.

I first found Net Ninja’s courses and I built a Project Manager that taught me about React, Redux and Firebase/Firestore. I then took Andrei Neagoie’s two courses, ‘Zero to Mastery’ and ‘From Junior to Senior Developer,’ on Udemy, and learned all about Node, Express, Postgres, Redis, middleware, libraries, reading documentation, best practices, and much more, including more practice on React and Redux.

React Redux

Eventually, I completely understood Redux and then I was like, why did I think this was so hard? It’s so simple…

You create a store, you make the store available to your app, you pass the props from the store to components that will use them, you pass actions that you create to components that will use them, in your actions you dispatch the type of action that was called, in your reducers you set watch for the type of action that is dispatched from the action, and then you update the store appropriately. Simple! (j/k)

Postgres & Knex

I used Knex, which is an SQL querying language library for an express backend. This made me a little uncomfortable, after all, if I already knew how to write proper queries, why would I need a library to do it for me? I also couldn’t find answers in the documentation as to whether they actually used placeholders, or did other things to protect against injection behind the scenes. I had to trust someone on Stack Overflow who told me they did.


Post Course Work : My First Fullstack JS App

PWA, Serving .txt, or .html Files, & HTTPS

Speaking of https. This was much different than a php site. In a php site, typically, the host provides the certificate for you. Just tell them you want it and they set it up for you. Not so simple in a javascript stack.

I used to create the SSL certificate. Then I used the certbot CLI. It was a bit frustrating because I had to verify my certbot installation by uploading a file to my site but I didn’t have a site, I had an app, that had one root index page. This was another difference between a PHP site and JS one.

In PHP this is simple. You create a file and upload it via your ftp software. This is not the case with a React app on Heroku. Ultimately, Stack Overflow gave me the answer. Put the file in your public folder. Then, in your BrowserRouter, assuming you are using React Router, which I was, create a path to the file with an onEnter={reload} tag like this…

<Route path=”/robots.ext” onEnter={reload} />

Then, add the reload script in your render method above the BrowserRouter:

const reload = () => window.location.reload()

The Unknown: Command Line & Git

I was also a little nervous about github. I use git on my local computer and I love the idea of reverting a change after I take a site down a wrong path, but I have yet to work on a team, create meaningful branches or handle real pull requests. But pushing my site to Heroku has forced me to get into the habit of git add . — git commit -m ‘message’, git push heroku master.

I am still a bit scared about not getting all of the great Apache tools that come with a server such as email setup and mailbox software like Roundcube, spam detection software, built-in stats programs like AWStats, and even php MyAdmin which makes viewing db tables as simple as logging in.


BUT… it finally clicked with me why testing is so important when, at the end of my process of building Power Todos, I had to rebuild something…


I spent three days investigating. I asked questions on Stack Overflow and even talked with the developer of express-session. No one had no idea why this didn’t work on Safari and I was baffled that something so important would remain unknown.

So, hitting a brick wall, I had no choice but to nix ‘express-session’ and learn about json web tokens, Redis and localStorage for handling my app’s sessions.

This meant I had to create a whole new logic system for the login api, which, instead of simply going to the login function that would check the email and password, would now go to a new login function. I turned the original login function into a function that simply checked the supplied email and password and returned a Promise. I created another function that checked the JWT legitimacy if a token was sent in the authorization header, another to retrieve the stored token in Redis, another for creating a token if none existed, and another for storing the newly created token in Redis.

I then created a middleware to serve proper routes to logged in users for the backend api’s. None of that is the point, the point was I did major changes to section of the api that affected many other sections of the api.

Now, because I had a whole new system, I had to manually test everything again to make sure I didn’t f-up anything anywhere/everywhere. Finally, I saw the light of why writing tests from the start is so damn important!

If I had the tests written for all my functions on the frontend and backend, and they were thorough, I would not have to go through all this manual testing every time I made a change. I would just run the test suite before I uploaded and if all passed, great, if not it, fix what needs to be fixed.

Much better!!!

Even though I studied Jest and Enzyme before I built Power Todos, I did not want to implement any tests, I thought my app was too small and insignificant. But I learned that even the smallest apps can drive you crazy if you have to manually retest everything after little change you make. So, lesson learned, write tests from the start!

Going Live: Heroku, Docker, docker-compose

I was able to create a nice docker-compose.yml file and different images for Node, Redis and Postgres, including all the db tables needed for the app, as well as some seed data to give devs something to work with in the database when they started on a new machine. I was so proud that I got it all working and understood everything, only to finally finish my app and begin to deploy on Heroku to find they do not handle docker-compose.yml files. WTF!

What was the point of all that setup? Why did I even need to use Docker at all? I thought the whole point was that I could setup once and then be able to create new servers in a cinch so that it would be easy to scale should the need arise. This was my biggest road block and biggest pain point of switching to fullstack javascript. Not docker, but the whole deployment process.

What made it worse is that I found no answers on Stack Overflow. This was one of the biggest differences from PHP to node/express/react/javascript. In PHP every question you can possibly think of has like ten different answers, and most are up to date and you can pick and choose which you think is the smartest answer for your situation. But in the node world there are so many different libraries that there just isn’t an answer, or as big of a community ready to answer your questions, for every different pain point you encounter.

I did, however, figure out the docker-compose Heroku problem. Well, not really. What I figured out is that you can’t deploy your docker-compose.yml file to Heroku. So all I could do was deploy my main Docker image, which consisted of just setting up the express server. Then, I had to manually go in and add a Heroku addon for Postgres and Redis, then I had to manually create tables for Postgres using the Heroku CLI. I found out later I could have just added my Postgres and Redis docker image individually after I added the addons, but I already had it set up by then. Next time.

I had to edit my Dockerfile to get it work on Heroku. I will have to now go back and make sure that the Dockerfile will work whether I have to upload it individually to Heroku, or whether I upload to github so another developer can just install straight from docker-compose.yml. This whole deployment process was very frustrating and not even close to as easy as simply uploading files via FTP software in PHP (if you have your own dedicated host you just create a new account for a new site, then you can upload the files). But I do look forward to using Docker in the future so that the databases and backend run smoothly on all machines.

Things I love and things I hate

I also loved building an API on the backend that is completely separate from the frontend. In PHP everything is intertwined, and I am sure Laravel might have been an answer to this, but Wordpress is not. Wordpress is a nightmare compared to Node.

I loved the modularity of React, the pure functions and simple components. I love having the ability to add libraries like Lodash, while only including the exact function I need so it doesn’t bog down the system with its entire library in production.

I hate the deployment. In PHP it is as simple as uploading your files. And editing a file is as simple as, well, open-edit-save. This is not even close to the scenario with javascript, at least not for me… yet.

Being an SEO, I hate the idea of there being no HTML, though I understand this is less important these days. And I am well aware that Next.js solves this problem, it is actually coming up soon on my todo list, behind writing this article and learning and building something in React Native.

I like the separation of backend/frontend, but I hate having to pay for multiple servers for one app. I imagine that after a year or two of doing this I am going to have like 50 different servers, which could make costs insane. In php I would just get one Virtual Server and run as many sites as I want (to a point).

Now, I understand the value of this for big companies as it is easier to scale with a separation of servers, but so many of the sites I built in the past are for small businesses who get 1000 visitors a month max, they usually just need an internet presence, maybe they even have a shop that just isn’t as world-wide or as a full-fledged as an Amazon.

Again, there is probably a solution to this in JS world. For instance, I found a way to run the frontend from the backend server, thus only needing a host for the backend. But still, that seems a bit hacky and goes against the intended purpose of the Node ecosystem and separation of concerns.

Working on a New Codebase

When you dive into a new codebase, or if you are starting an app from scratch, it is okay to give yourself some time to understand what is going on. Keep a notepad as you go through code and outline your understanding of what is going on. Keep developing your outline and expand your understanding before you write one line of code.

Give your brain some room to grasp the code. Talk it out to a friend or partner, even if they aren’t programmers. If you can make them understand, then you know you understand. And take one little piece at a time and trust you have the brain power to get it, and ultimately, you will be able to contribute something of value.

Next Steps

PS- A large majority of the techniques I used in my app and which I wrote about in this article came from Andrei Neagoie’s courses on Udemy. I could not recommend his courses higher.

developer. entrepreneur. student.