In 2017 I was engaged and we we’re looking to put up a wedding website. Obviously, as a software developer, I naturally thought “I can totally spin that up with ease”. I had written some JavaScript apps in 2014 using CoffeeScript and figured I could catch up pretty quickly.

Three months later, I came to the conclusion that JavaScript had evolved greatly, and I really should have just used a free wedding website.  My experience with re-learning JavaScript was quite similar to this hypothetical conversation. It was evident that I would need to a lot of reading up.

In the end, I was able to get it spun up. It successfully took RSVPs, meal requests (with allergies), and even hooked into a web service for music requests. To say I learned a lot would be an understatement.

Recently I’ve transitioned into more NodeJS development at my job, and it has given me time to reflect on what I got right and what I got wrong with this website. I figured I’d share my thoughts and hopefully help the next developer who’s in a similar situation.

The Design #

I went with a traditional web stack:

• A front-end coded in ReactJS, compiled using BabelJS, and packaged in Webpack. It would be a Single Page Application using React Router.
• A back-end coded in NodeJS, leveraging Express for the RESTful API calls.
• PostgreSQL for storing RSVPs and song requests.
• Nginx for proxying traffic on port 80 to the NodeJS app on port 8080.

The interesting decision I made was to leverage Docker as a development environment. I had recently heard about it through a co-worker and was interested in learning more about the technology. Given that the Docker image would contain all the OS and NodeJS dependencies I would need, I thought it would be great to develop within the running instance.

The two big features (aside from the static information on hotel location, registry sites, etc) was the ability to RSVP and request songs. The RSVPs were mostly hard-coded (e.g. there were only three options for food). The song request service leveraged a Web API on musicbrainz.org.

Hosting the app would be done on digitalocean.com. They had a very simple server that cost $5/mo that I could run everything on. For an extra amount of money, it would do weekly backups (you do not want to lose those RSVPs).

What I Learned #

Nginx was overkill #

I don’t think I truly leveraged Nginx the way it was designed. The static files were still served from NodeJS, so Nginx was nothing more than a port proxy. If I needed to massively scaled site where I would need to load balance, Nginx would be a good choice. Another good use case would be if I had microservices that I wanted to use Nginx as a reverse proxy.

Learning vs. Getting Things Done #

I was really committed to learning all of these technologies. This meant I spent more time experimenting and less time actually creating a viable site. There’s a balancing point where learning has to give way to producing. While it all worked out, it helps to have a backup plan, like using a free wedding website. If you do decide on writing the website, make sure to leverage the NPM community to simplify your app.

People still use Internet Explorer #

Immediately after sending it off to a select set of friends and family, I quickly discovered that half of them could not see the website because the JavaScript wouldn’t run in IE8.

Luckily, I learned about two things:

• Internet Explorer VMs for testing
• BabelJS polyfill

Using these two, I was able to quickly figure out the issue and push out a quick patch. As developers, we should remember that not everyone runs on top-end tech using the latest version of a browser.

Best Practices: Use Them #

There’s a reason why they’re called best practices. I followed some of them (e.g. using 12factor for the app design). Many I didn’t follow, like unit testing, linting, and proper OO design. Not using those best practices made my life more painful as I had to fix things.

Considerations for a rewrite #

I would bucket this into two paths: fixing what I have and a full rewrite. If I were to fix what I have:

• Use Swagger for REST APIs – It would have made my APIs a lot cleaner and managing them easier.
• Add a linter – Makes the code more readable and avoid common pitfalls.
• Add unit tests – Use SinonJS to stub out external calls, use Istanbul for code coverage.
• Coding with a running docker container – Only make sense if you’ll have differing OS requirements. For example, if you need specific native libraries for image processing, this makes more sense. If you’re building a site where the libraries are all managed through npm, then developing within a docker container doesn’t get you as much value.
• Standardize on a JavaScript version for the front and back end – In the backend I used ES5 and in the front end I used JSX. It would be nice had I kept them the same; however, it would require more research on what .

Now, if I’d do it all over again, I’d probably try out a server-less solution like AWS Lambda paired with Amazon DynamoDB. There’s a great tutorial on AWS that walks through standing up a web site using server-less technology.

The positive here is that you manage none of the underlying technology, like managing updates to your VM or your database. You can also reduce your costs because your code only runs when someone makes a request. Since AWS has a free tier, you could potentially run the site for less than $5/mo.

The downside is that it might not be the easiest thing to troubleshoot. From what I’ve read, AWS has a local version of AWS Lambda you can use for testing locally. It’s a big paradigm shift, but more companies are embracing server-less.