Hit the Ground Running with ReactJS and Node API Development

I’ve recently taken a look at what tech you might need to get involved as a dev, and realised I was lacking in the frontend space. Last year I ran the gauntlet on a multi-page application in VueJS 2, complete with data persistence, user account authentication, fancy multi-screen sign ups, a whole host of state changes, and developing a keen appreciation of reactive data stores. But that was a year ago, and I hadn’t touched it since.

I wanted to jump into ReactJS, and it’s dead simple with create-react-app.

I already knew how to set up an Express server, and was comfortable serving API calls through it.

What I didn’t know was how to combine the two for fast software development, and eventually, deployment.

Enter the Companion Repo

You can see the companion repository on GitHub here for this project – it has all the explanations, and more. For reference, it was originally destined to be some useful webapp for GaryVee style, “hustling all day erry day”, motivational business Instagram pages. It turned into a useful hobby project to see how quickly I could get up and running with a viable ReactJS - ExpressJS stack, that could be deployed to the cloud. Very fast, it turns out.

Spinning up ReactJS and Express

Create-react-app makes it dead simple to spin up a dev server on localhost, hot-load some changes, and really get moving on the frontend. I won’t reinvent the wheel: the documentation for that package cover it way better than I do.

The dev tools in your browser – I user Firefox Developer edition – make it easy to trial some CSS changes, or understand network requests, or figure out how long til first paint you have on your site. If you’re privy to market share you’ll know that Chrome is the weapon of choice for most users, and make the decision to test all of your code there. Even better, since Edge now renders using Chromium under the hood.

ExpressJS I chose as a server module, just because I knew how to use it. The workflow of declaring routes and middleware comes naturally to me. They’ve got a great getting started guide here on their site, and usually for development it suffices to set up an npm script to spin up nodemon on the server file (usually index.js).

Caveat: API design

Eventually your app, no matter what its purpose is, will start to get reasonably complex. In other words, you’ll start considering what resources you want to serve, and what the relationships between those resources are.

When you’re setting up a multi-page application, all server rendered, then you don’t need to worry too much about how the structure of your data impacts the frontend. Any client-side code just renders that data, and maybe makes a few light AJAX calls against the server.

Using a framework like React, however, to a sufficiently complicated level – in other words, you’re approaching “single page app” territory – will make API design a pain in the ass, for one simple reason:

You’re violating the DRY principle. (You’re repeating yourself!)

Your frontend will dictate what it is that you’re trying to accomplish with your data. Your backend will safely interface with some database to manage that data in a way that’s reliable across N-many users. You’re going to expose API endpoints for your client – any client, really – to access and manipulate that data the way it sees fit.

This means that in development, when things are moving quickly, you run the risk of losing a lot of time constantly changing endpoints in your server-side code.

Saviour: Dummy Databases

This is not a new problem – the concept of API mocking for your backend is a great one. Essentially, we’re going to use a thin, development-only server module, that reads some dummy data file, and programatically exposes generic API endpoints for that data.

In NodeJS, that’s json-server.

Here’s what the dummy data looks like:

  "images": [

        "id": 0,
        "figureId": 0,
        "url": "https://upload.wikimedia.org/wikipedia/commons/thumb/8/83/Billgates.jpg/800px-Billgates.jpg"
        "id": 1,
        "figureId": 0,
        "url": "https://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/Steve_Jobs_and_Bill_Gates_%28522695099%29.jpg/640px-Steve_Jobs_and_Bill_Gates_%28522695099%29.jpg"
        "id": 2,
        "figureId": 0,
        "url": "https://upload.wikimedia.org/wikipedia/commons/7/7f/Bill_Gates_2004_cr.jpg"

And here’s the NPM script that sets up the server;

node \"node_modules/json-server/lib/cli/bin.js\" --watch ./api/dummy_db.json --port 8989

Then from here on out, any time you need endpoints changed, you just change the underlying data in your JSON file. This really speeds up development, and lets you realise the shape of your data efficiently, which is something we all love to hear.

749 Words

2019-05-02 00:00 +0000