This article is Part 1 in a 3-Part Series.
This is currently expected to be a three-part series. It will seem like a bit of a departure from my usual Domino and XPages grounded topics, but it will come full circle by the end of the series; trust me. This first post will be the ground work to a fully functional Node+Express app that will be the foundation for two different flavors that I’ll get into over the following couple of posts.
I’ve recently had two things surface, both of which are rather related and different in implementation. I’ll describe both in the next two posts, but first, some ground work on the common base of the Node app that will be used by both versions. The best part of this all is that when you create well structured app, the abstraction of the data service becomes different only by configuration.
Node and Express
I’m using Express to assist in some of the web server aspects of this app; it’s a pretty popular framework that reads fairly easily. There are plenty of other web frameworks for Node out there, but Express has generally been my preference for some time; use whatever works for you, but be sure to read the API docs.
Scope of Demo
This will illustrate setting up an Express app with:
- a highly configurable app layout, with:
- data access through a
I am not demonstrating:
- authentication middleware, such as any of the “strategies” for passport
- Express Router
- specifics of individual data service connections… yet (two interesting ones coming over the next two posts in this series)
Base App Layout
Structurally speaking, both versions are the same app, just with different data services plugged into them. At a high level, the common parts are:
server.js- contains the main definition of the server, creates the app as an Express app, and pulls in the
routesmodule (Node is generally pretty big on the module design pattern)
routesmodule, which since the
requirepulls it in by directory, it grabs the
/routes/index.jsfirst, which then pulls in the other endpoints’
.jsfiles, establishing the route information for those collections (and inevitably more beyond this example)
- each of those endpoint definition files perform the data service operations via functions defined in the
utilmodule (this is where I copied in a version of the functions to perform the actual API specific look ups, wrapped up and exported again as a module)
server.jsmake use of some app config, which is defined in the
configmodule, which also allows for a couple of environment variables
Here’s a project tree breakdown, minus the
node_modules folder, ReadMe, etc.:
. ├── config │ └── index.js ├── package.json ├── public │ └── readme.html ├── routes │ ├── index.js │ └── views.js ├── server.js └── util └── index.js
I breezed over the dependencies when I first posted this, since there are a whopping two (you’ll note I require ‘path’, but that’s part of the Node core, so it’s a freebie, just like ‘os’), and I’ve blogged about installing npm packages before. To make a long story short, with the required dependencies of express and express-toobusy, our install will look like
npm i -S express express-toobusy. The
i is short for
install and the
-S is short for
--save (which saves to the
Alternatively, if you clone the repository’s
master branch, all you need is to run
The main server definition, which sets itself up with an express app handle, instantiates
express-toobusy (to keep the Node process from melting under extremely high loads), pulls in the
routes module for the endpoint handling, and creates an error handler. The last thing is telling the app to listen on a port, meaning the app is running.
index.js of the
routes module is there to pull in the specific endpoints, which are contained within their own js files within the
The config module holds configuration info about the app, which is mostly unused in the initial version of this app. The two specific ones will rely on external connections, the properties of which will get stored here. For now, it’s a placeholder module.
The code for this base version of the app in its entirety, confirmed working with “hello world” style endpoints, returning
application/json data, can be found on GitHub in my edm00se/express-app-fun repository. More will be added as this blog series progresses.
Hopefully this all seems pretty straight forward. The next post should come along soon, containing some goodies related to one flavor of this style of RESTful API microservice that I had used for a while, to pull some data off of our IBM i. I’ll get into the benefit of doing so in th enext post.