This repository aims to produce a production ready template that you can customize and use in real world projects.
The main branch on this repository includes a project with a basic REST API template following best practices and ready for production. It uses body-parser,cors,helmet,compression,morgan as middleware, winston for logging and chai with mocha for unit and integration testing.
The project structure is the following:
root
├───configs
├───src
│ ├───constants
│ ├───core
│ ├───middleware
│ ├───routes
│ │ └───helloworld
│ ├───serviceclasses
│ │ └───helloworld
│ └───utils
│ └───logger
└───tests
├───integration
└───unit
- configs: This folder contain configuration files (for modules, express middleware or other configurations)
- src: This is where our main code will be.
- constants: In this folder there will be some constant values that will be used along the api. For instance the template includes some majorly used status codes with messages that can be used when the response status is returned.
- core: The actual API code, here there is a server.ts file where the express server is initialized and calls initializeMiddleware.ts (which initializes all the middleware and the error handling middleware) and initializeRoutes.ts (which is where our routes are declared).
- middleware: this folder contains two files, the commonMiddleware.ts and errorHandlingMiddleware.ts which are two class called by initializeMiddleware.ts which includes the actual funcitons that act as middleware and error handling.
- routes: This folder includes an abstract class abstractRouteController.ts which defines how a route should be and then inside the routes folder you can create any folder that represents a group of routes. For instance in this base template there is a helloworld folder which has a helloWorldRouteController class that extends the abstract class. This helloWorldController has a path which will be the route's endpoint and then inside the runService app we call the function that will execute when the route is called and the status and message to be returned. Of course this can be changed to adapt to every project but keep in mind that since this is a production ready project we should separate the business logic from the application logic by creating functions in the serviceclasses folder which will be explained next. An example of this is the wishHello function being called inside the hello world route.
- serviceclasses: Here will go all the Business Logic Code. It is all the code pertaining to the actual processes that need to be carried out. This logic changes depending on the purpose of the API.
- utils: Some utiliy classes such as String handling functions, Logging Utilities, etc.
- tests:All the code for testing our api will be inside this folder, there is a distinction between unit testing and integration testing inside this folder.
This API Template will include modules (
- JWT Authentication module
- GraphQL API module (instead of REST)
- MongoDB connection module
- SQL connection module
- Neo4J connection module(problably connected to the GraphQL API module)
Clone or download the repo, run an npm install and then npm run build to generate the build folder. To run the API you can use npm run start|pm2|dev depending on your intention. To run tests you need to run npm run test.
- "start" command is used to run the API normally
- "pm2" command is used to run the API with pm2 which is a production process manager for Node.js applications.
- "dev" command is to run the API with tsc-watch and nodemon which allows you to make changes in your code without the need of restarting the API.
While the template has been created for production ready deployment using best practices and keeping in mind the security of the API and the data being handled by it, it is limited to my own knowledge and not prepared for every possible inconvenient. Therfore, I am not responsible for any damage that can occur to any project using this template, use it at your own risk. If you are going to modify this template or add your own code logic (which you should since this is a template), the production code can easily turn into non-production ready code due to bad practices included while changing the template. To avoid this, I would recommend you to visit the official ExpressJs Security Best Practices website and ExpressJs Performance Best Practices as well as to look into S.O.L.I.D Principles[1][2][3] which were followed on the creation of this template.
Special thanks to Dhairya Gada whose article on hackernoon was used as a starting point for this template.