client-side web development.
- mature technology (developed for at least 2 years), as part of the principle to use boring technology.
- actively maintained, and have updates within the last month, and a history of frequent updates without the developers taking off on long vacations.
- ideally sponsored by a large organisation that won’t die tomorrow (Google & the like preferred, but Airbnb, Palantir et. al. are acceptable), and,
- have developer mindshare, as measured by a healthy number of stars on Github.
Based on these criteria, here’s what we chose for the frontend:
- & how to deploy this application, for which we chose to build a Docker image that combines the server & client parts of the app, for eventual deployment to a managed Docker cluster.
Note: in future versions, we might explore building an auto-generated and configured GraphQL backend instead of the Express app, probably using Hasura’s excellent frontend for Postgres, but that’s a post for another day.
The Application Structure
Let’s start with a sane application structure. We’re essentially building two apps: a frontend SPA client app, and a backend API that the client consumes to display data from a database. So let’s make:
We also need tests, so a folder for that. Note: we prefer integration tests, so these are independent of the client and server, and indeed will only work if both components are present and running:
Eventually when we deploy the app for distribution, we also need a dist/ folder, so let’s create that too:
Inside the client/ folder, we start with a simple SPA application:
- All React components of our SPA
- The HTML entry-point of the client-side app, this is what webpack injects assets into & loads in the browser.
- Generic styles and imports that remain outside of components. This is usually used only for
@imports & special things like
Note: as our app expands, we might logically create more folders, for e.g. sub-components inside the components/ folder by business theme or any other organisational unit we might choose.
The server folder uses the folder structure generated by the excellent express-generator. Note: we choose to configure it with the EJS view template (i.e.
express -v ejs) . It looks like this:
- Both these folders will be empty when developing, but we’ll use this in the deployment step to link the client and server applications correctly.
- This is the /api/* endpoints that you would configure. Each file would be a separate route.
- This is the default route that will just serve views/index.ejs. We’ll use this during the deployment step.
- Used when there is a 40*, 50* error in the application.
- Copied in by the deployment process to load the client-side SPA.
- This is called by boot/www during the startup process and sets up the main Express app. You also configure the API routes here.
That’s it for now! In Part 2 of this article, we’ll look at configuring Webpack correctly to minify & remove un-used CSS, and process images and fonts.