Thursday, 30 March, 2017 UTC


We’re delighted to have Zell Liew writing for us today. Known for his practical and easy-to-understand tutorials, he gets into Node.js and how you can use it to create your first app.
Have you heard of JavaScript? It used to be a scripting language that’s only available in browsers. Chances are, if you’ve developed a semi-complicated website, you probably know some JavaScript.
With the advent of Node.js, JavaScript found its way into the server. Since then, Node has matured quickly as a server language, so much that even large companies like Netflix and PayPal use it.
Now, since you already know JavaScript, it wouldn’t be a surprise if you thought about creating an application with Node. In this article, I want to share 20 things you might want to consider when creating your first Node app. Hopefully, these points will help navigate your first app-filled waters.
5 things to consider before starting to code
Before you dive right into Node, it’s worth spending some time examining different frameworks and technologies that’ll help you create your app. This is where you choose your stack (a stack is just a set of technologies you use).

1. Choose your Server Framework

The first decision to make when working with Node is to select your server framework. Selecting a framework is similar to selecting Rails (for Ruby) or Django (for Python). With Node, you have access to over 30 libraries to choose from, including Express, Koa and Hapi.
It can be daunting to select a server framework if you’ve never heard of them so far. It’s hard to know what’s the best and why you should use it. It’s a common problem to have. A friendly advice here is to just go with something and learn it throughly. You’ll begin to see how everything falls in place very soon.
If you’re totally new, I highly recommend going with Express.

2. Are you building a Single Page App?

Single Page Applications (SPAs) are web applications that serve up only one HTML page. Then, through the use of JavaScript, content is fetched, shown or hidden depending on where the user navigates to. Examples of SPAs include Facebook and Redmart.
Non-SPAs (let’s call them traditional apps), on the other hand, are apps that load new HTML pages whenever a user navigates to a different URL. These apps behave very much like websites. Examples of traditional web applications include Twitter and Delicious.
If this is your first application, I recommend you go the traditional route since these apps are much easier to grasp. Once your foundations are firm enough, feel free to explore SPAs.
3. Select your template engine
Template engines are tools that let you feed variables into your HTML code. When creating applications, mastering the use of template engines is a must.
If you decided to create a traditional app, you can choose from (again) many template engines, including EJS, Nunjucks and Mustache. As with selecting frameworks, just pick one and go. I recommend Nunjucks if you can’t decide.
If you chose to create a SPA, your choice is pretty much limited to the framework you go with. For instance, React uses JSX and Angular uses HTML with its own syntax. What you can do is learn that engine to its fullest.
Let’s move on.

4. Choose your router

Every application comes with a need for a router. It lets you determine what to show users when they navigate to a specified URL. It also lets you determine what your app does if the HTTP request method changes from GET to POST, PUT or DEL.
If you build a SPA, the routing takes place in the browser instead of the server (which is why there’s no need to load new HTML).
Most frameworks, such as Express and Angular, have a built-in router you can use. Some frameworks, like React and Koa, allow you to select a router you prefer.

5. Select your database

Once you’re done selecting the server framework, router and template engine, the next big decision you have to make concerns your database.
Selecting a database language is almost like deciding whether to use Node as your server language. It’s a huge one.
When it comes to databases, you have two types to choose from – relational databases or non-relational databases. Relational databases are commonly called SQL databases; the most popular ones include MySQL and Postgres. On the other hand, non-relational databases are commonly called NoSQL databases; the most popular ones include MongoDB and Redis.
Like selecting a server framework, there’s no right or wrong in going with either choice. If you’re new, I highly recommend going with MongoDB since I find it much easier to learn.
If you want more help to decide between SQL vs NoSQL databases, consider reading this piece by James Serra.
4 things to consider when setting up your dev environment
Have you chosen your stack? Great! Next you need to set up your development environment to take away the pain while developing your app. I’ll share what pain you’ll encounter and the solutions you can use.

1. Select a package manager

If you have chosen any of the tools mentioned above instead of writing vanilla JS all the way, you already have libraries to work with. The first thing you need while setting up your dev environment is to choose your dependency manager(s), also called package managers.
Package managers are great at helping you download libraries into your app. For example, you can download Express just with one line of code instead of downloading it through GitHub.
npm install express --save
They’re also great at helping you update packages whenever you need to.
Since you’re already using Node, you can use npm as your package manager for your backend.
For the frontend, it’s not so simple. You can still use npm, but you need to set up some tooling (see the next point) because browsers don’t support npm packages out of the box.
If you want a simple, painless solution, consider using Bower, which is the old-school package manager of choice. Here’s an intro article to Bower.

2. Select a build tool

Earlier I mentioned npm packages aren’t supported by browsers natively. You need to go through some tooling before you can use npm for the frontend. Here, you need tools like Browserify, Webpack or Rollup.
If you want to use better technologies like ES6, Sass or PostCSS to help you write your app, you also want to think about how to compile these assets into CSS and ES5 (which is the JavaScript browsers use today).
Here, you have two tools to choose from – Gulp and Webpack. Gulp is an all-purpose build tool that helps you run all kinds of tasks like the ones I mentioned above. Webpack also does it in its unique way.
If you’re starting out, I highly recommend Gulp. Here’s a handy tutorial for you to start with.

3. Refresh your server automatically

One of the most painful things about Node is that your server doesn’t automatically update when you save a file. So, you often have to restart your server in the command line whenever you make a change. It’s a lot of keystrokes…
There are two methods (why are there always so many ways?!) to restart your server when you save a file. The first is to use Nodemon to restart the entire app. The second is to use chokidar to refresh your require cache.
If you’re just starting out, I highly recommend Nodemon because it’s much simpler to use. You just need to start your app with nodemon instead of node.
nodemon server.js

4. Refresh your browser automatically

Last but not least, consider refreshing your browser automatically whenever you make a change to your templates, HTML or CSS. This way, you save a few keystrokes from hitting alt+tab and CTRL + R. (Tabbing to refresh the browser anyone?).
The best way to do it so far is through the use of a package called Browsersync. I’ve written extensively about using Browersync in my book Automating Your Workflow. Just download the sample chapters and set it up.
Another way to do this is through Webpack. But that’s a topic for another day since it’s much more complicated to set up a Webpack build.
4 things to consider when coding your app
Once your development environment is set up, you’re ready to dive into coding! Here, there are four considerations you probably want to make.

1. Select your API architecture

There are two main API methods out there right now – REST and GraphQL. REST stands for representational state transfer. It has been the de facto standard for a long time. GraphQL is a method Facebook came up with that allows you to get multiple sources of data with one request.
If you’re new to building applications, I recommend going with REST since it’s still the standard way of doing this. Here’s a tutorial to help you get started.

2. Learn to write a good REST API

There’s a lot to learn when you write your first piece of server code. One of them is designing your API. If you don’t learn to create a good API, your code might end up very messy.
Here’s an article to help you learn the best practices for a RESTful API.

3. Consider using async/await to manage asynchronous operations

Node is a single threaded language. To cope with multiple asynchronous operations needed in a server, Node defaults to using callbacks (functions that are called whenever an operation is done).
Sometimes, you need to wait for multiple things to be done, which leads to a phenomenon known as the callback hell.
// Look at three layers of callback in this code!
app.get('/', function (req, res) {
 Users.findOne({/* params to query for user */}, function (err, user) {
   if (err) {res.status(400).send({err: e})}
   user.update({/* params to update */}, function (err, raw) {
     if (err) {res.status(400).send({err: e})}
     // Do something with raw
     res.send({data: raw})
Node has progressed a lot since the days of callback hell. The most recent improvements are asynchronous functions that let you write asynchronous code as if it was synchronous.
// Callback reduced with async/await
app.get('/', async function (req, res) {
 try {
   let user = await Users.findOne({/* params to query for user */})
   let raw = user.update({/* params to update */})
   res.send({data: raw})
 catch (e) {res.status(400).send({err: e})}
It’s so much cleaner. I recommend learning async and await, but if you can’t do so, try to learn Promise at least.

4. Determine how to authenticate your users

Authentication is likely the part that trips most beginners up. It’s not simple. There are two main ways you can use to authenticate your users.
The first way is to ask for a username and password. This is probably the easiest, and the solution you should go for when you’re starting out.
The second way is to log users in with a third-party account (like Facebook, GitHub or Twitter). This method requires you to use OAuth2, an authentication protocol which is incredibly hard to understand.
Because it’s so difficult, many people accidentally leave security holes when they implement OAuth2 on their own. So, unless you’re a master with OAuth2, I recommend you use a service called Auth0 to help you create login credentials with Oauth2.
After you’ve verified your users credentials (either with username and password or oauth), you need to determine how to let them stay logged in while they’re using your app. There are two main ways – sessions and token.
Sessions is an older, tried-and-tested way of authenticating a user. JSON web tokens are a newer method that seeks to overcome some scalability issues posed by session-based authentication. Session vs token-based authentication is a huge debate, and I won’t be able to cover them in detail in this post. If you like more information, check out this guide by the guys from Auth0.
Personally, I’d recommend learning to use token-based authentication.
7 things to consider when bringing your app to production
Phew. Now that you’re done building your first application, it’s time to put it up for all to see (and use)! Here are seven things you want to consider before doing so:

1. Select your web host

Needless to say, you need to select a web hosting service to serve your website (unless you build one yourself). When you use Node, you need root access to your server so you can install your node packages and run necessary commands.
This means you need a virtual private server or a dedicated server. Or, if you prefer to keep things simple, you can choose to host with Heroku.
I recommend you start with Heroku if this is your first application. It’s much easier than learning to configure your server options.

2. Should you use HTTP or HTTPS?

If you need to authenticate your users, there’s not much room for negotiation. You should always use HTTPS to keep your users secure.
If you use Heroku, you can ignore this step. HTTPS is turned on by default.
If you use hosting providers that require you to configure your servers, you’ll need to buy an SSL certificate and configure your server to serve up the HTTPS version.

3. Should you use a content delivery network?

A content delivery network (CDN) is a collection of global servers that caches and delivers web content. These servers reduce the time it takes for your visitors to request a file. So you should always use a CDN.
But what CDN should you use? There are multiple options for you to choose from, like Amazon Cloudfront, Cloudflare and MaxCDN.
I recommend going with Cloudflare because it’s fast and free!

4. Learn to keep secrets

One of the worst mistakes I ever made as a developer is to check an Amazon API key into a git repo. Although this repo was private, a friend of mind forked it as a public repo.
The result? I incurred a bill of $60,000 out of the blue.
Thankfully, Amazon was willing to let the case slide, but this taught me a very important lesson – never commit any credentials directly in your code.
There are two ways to store your credentials safely.
The first way is to use environment variables. In node, you can get your environment variables simply with the following code:
let secret = process.env.secret
The second way is to gitignore your secrets/ folder or secrets.json file. You can then push these secrets into your server with scp, rsync or ever plain ol’ FTP if you wish to.

5. Make your app run forever

Right now, you should be running node server.js or something equivalent to start your application. This isn’t ideal because your app would crash if it runs into an error.
In production environments, apps should be able to restart themselves even when they crash so they can remain functioning. To do this, you’ll need to use a process management tool like pm2 or forever to start your app. Here’s how starting a process with PM2 looks like:
pm2 start server.js --name name-of-app
If you use Heroku, you’ll have to alter your package.json file to use pm2 instead:
"scripts": {
  "start": "pm2 start server.js --name name-of-app"
As you can tell, I recommend you go with pm2.

6. Tracking errors with logs

If your app automatically restarts itself, how would you be able to debug errors it encountered before it crashed?
The answer is to view the logs that PM2 creates for you automatically. You can view your logs by running the following command:
pm2 logs name-of-app
Optionally, instead of viewing the log through the command line, you may want to save the logs in a file with the following command:
pm2 start server.js --name name-of-app --log name-of-app.log
Once created, this log can be found in /root/.pm2/logs.
Note: If you use Heroku, you might want to use Paper trail to create a log.

7. Create a deployment script

Finally, deployment is a stressful activity. You’d want to minimise this stress to a minimum by creating a deployment script.
This script (ideally) does things like:
  1. Compile, minify and and deploy your assets.
  2. Test your application
  3. Push your application into the server
  4. Update the server
To do so, you might need to use a combination of task runners, npm scripts and git post-receive hooks.
Wrapping up
Phew! That’s a list of 20 things to consider when creating your first Node application. I hope this article has shown you something useful. Now, go ahead and create your Node app! The world is dying to see it .
The post 20 things to consider when creating your first Node.js application appeared first on Heart Internet Blog - Focusing on all aspects of the web.