The popularity of Node.js is growing at a rapid pace. With more and more unicorn companies adopting the technology, it has become very crucial to follow certain conventions to make code readable and modifiable by other developers. The code you write is also directly proportional to the scalability of the product you ultimately build. A good project structure setup lays a solid foundation for an effective and scalable application. If you plan and implement a well-defined structure before starting, it provides a bird's eye view of the functions of your system. Organising your data models, routes, controllers, services etc. systematically gives clarity about the functionalities of the components and becomes easy to work on as well as debug the applications when in need. A well-defined structure helps you in the reusability of the code. Best Practice #1 Choose a Layered Approach: Separation of your concerns Popular Node.js frameworks like Express.js allow you to define routes as callback functions that are executed when a client request is received. This gets you tempted to write all the business logic under a single function which unknowingly escalates to messy code that is difficult to interpret for a human being. Thus this should be implemented keeping in mind the principle of programming. According to this principle, we should have distinct modules addressing distinct concerns in the application. The server-side aspects are broadly divided as Separation of concerns These aspects can be handled by programming three different layers: API routes & endpoints Controller: For business logic Service Layer: For working with database Data Access Layer: Controller layer In this module, you only write API routes. In the route handler function, you can deconstruct the request object from HTTP to get params, query params, payload etc and pass them to the service layer for processing. Service layer This layer houses the business logic. This contains all the methods that take up singular responsibility and are reusable. Data Access layer The main role of this layer is talking to the Database - Fetching from, updating, writing to it. All DB connections, models, ODM/ORMs are defined here. Best Practice #2 Folder Structure: Properly organize your code files In the previous section, we spoke about how to logically modularize a project into layers. To get this abstract architecture in play we need a proper folder structure src
      ├── app.js			    app entry point
      ├── /api			      controller layer: api routes
      ├── /config			    config settings, env variables
      ├── /services		    service layer: business logic
      ├── /models			    data access layer: database models	
      ├── /scripts		    miscellaneous NPM scripts
      ├── /subscribers		async event handlers
      └── /test           test suites Here, (controller layer), and (data access layer) are the three layers we spoke about. layer can store your constants and app configurations/settings like environment variables etc. directory can be used to store automation scripts like deployment pipelines. will house the test cases you write for the application. /APIs /services /models /config /scripts /tests Best Practice #3 Publisher subscriber models The Publisher/Subscriber models can be used for communication between two entities in your code. Publishers (Message Senders) send out messages, along specific channels without having knowledge of who the receiving entities are. Similarly, Subscribers ( receiving entities ) on other hand listen to one or more channels without the knowledge of publishing entities. It is a good practice to implement this model in your project to manage multiple children operations corresponding to a single action. Let consider an example where, in your app, on user sign up, you do numerous things like - create a DB entry, generate an Auth key, sending a confirmation email.  If you handle this in a single service function the function code tends to get lengthy and messy. The structure of the code would look like: export default class AuthService() {
		async function signup(user) {
			//1. create DB entry
			//2. generate auth key
			//3. send confirmation email
	}
} We can very well simplify this with pub/sub model. Pub/sub model can use Node.js Events API var events = require('events');
      var eventEmitter = new events.EventEmitter();		

      export default class UserService() {

        async function signup(user) {
          // emit 'signup' event
          eventEmitter.emit('signup', user.data)
        }

      } To handle such events emissions, you can have multiple subscribers that are essentially event listeners, waiting for certain events to be emitted. These subscribers can be organized into separate files based on their purpose and stored in the /subscribers directory // email.js

    // ...

    eventEmitter.on('signup', async ({ data }) => {  // event listener 
      // send email 
    }) // auth.js

    // ...

    eventEmitter.on('signup', async ({ data }) => {	// event listener
      // generate auth key
    }) Best Practice #4 Clean Code & Easy Readability: Use code linters, formatters & comments Linting & Formatting The main goal here is improving code quality and readability. A linter warns you about syntactic errors (sometimes even semantic ) whereas code formatted styles the code in a more readable way. Some of the popular linters for JavaScript are Jslint and Eslint. For code formatting, Prettier is a well-known code formatter. Plugins for these linters and formatters are available in most of the code editors like Atom and VS code. Adding Comments When writing code it is important for a developer to write proper comments so that the team working on the project can benefit. A proper yet short comment explaining the functionality of the code can save much confusion and time for peer developers and ultimately the time of the entire team.  The screenshot below shows one of the examples of a proper comment: Proper nomenclature of functions, variables and constants The function, variables and constants names that you define should indicate the use or significance of that function( / variable / constant). Poor naming of the variables can create confusion among the team members and peer developers. Proper naming also helps you recognise the functions when checking memory snapshots. : How not to write a function name Here we are not clear about what kind of items have been defined in the items array, moreover, items is a common term that is likely to be used frequently. This is an example of bad nomenclature. The function name too doesn't go with the functionality of the method. The function can both mark items available and unavailable, so naming it 'makeAvailable' doesn't seem to be right. The parameter n inside the function is just a letter 'n'  and doesn't tell what it signifies. Better code would be: Best Practice #5 Write Asynchronous code: Use Promises, Async/Await Javascript is quite known for callback functions. They allow you to define the asynchronous behaviour in javascript. But with more and more callbacks in the code, the code gets clunkier, resulting in what is known as callback hell. Javascript introduced promises in 2015 which is a much cleaner way to handle asynchronous behaviour. Furthermore, in 2017, the async/await syntax was introduced to further simplify things. Therefore it's advisable to scrap the use of callback functions and choose promises or async/await. These syntaxes make the code more readable and easier to look at the code flow and debug. Just as an example, this is how the same code would look in callbacks vs the async/await: With callbacks: With Async/Await: Code with async/await syntax does the exact same computation as the callback one, but is much easier to read and debug. Best Practice #6 Testing, Logging & Error Handling Testing It's quite common for newbies to overlook the importance of writing test cases for the code. However, writing test cases is as important as writing the code as it checks the validity and accuracy of the code by bringing to light even the smallest inaccuracies. Unit tests form the foundation of most testing setups. Here, individual units/components are tested in isolation from the rest of the code to verify their correctness. This allows your code to be validated at the (logically) lower level to ensure that each of the internal components is working accurately, as expected. Logging Logging is a crucial part of the development process as it helps track down the errors in case of failures. This helps you record your important information and analyse various aspects of it with respect to accuracy and performance metrics. It helps you manage the application better and helps in debugging. Catching Errors The errors provide relevant information on what went wrong in the code and possibly where it went wrong. But instead of Node.js throwing errors, interrupting code execution or even failing sometimes, it's better if we take control by handling error conditions. We can achieve this through try/catch blocks. In such a way, we can keep things simple, stable and easier to debug as well as prevent poor user-end experience. try {
		if(somethingHappened)
				throw "Error Message";
} catch (err) {
		console.log(e);
} finally {
		console.log("Finally Executed" );
} Best Practice #7 Third-party solutions: Don't Reinvent the wheel | Don’t overdo either Node.js has a huge developer community across the world. As far as third-party support is concerned, Node’s package manager, NPM is full of feature-rich, well maintained, well documented, frameworks, libraries and tools for any use case you can imagine. It is therefore very convenient for developers to plug these existing solutions into their code and make the most of their APIs. While these libraries and tools ease off a lot of the burden, it is important to be intelligent and responsible about every package that we import. We should be aware of the purpose, strengths and weaknesses of each package we import and ensure that we aren’t over-reliant on them. First Published here

Too Long; Didn't Read

Making security fun one episode at a time

7 Best Practices for Writing NodeJS Applications

Too Long; Didn't Read

Amod Shinde

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

7 Best Practices for Writing NodeJS Applications

Too Long; Didn't Read

Amod Shinde

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES