Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/jungleminds/jm_api-boilerplate
A boilerplate for web APIs using Nodejs - based on Domain Driven Design and Clean Architecture principles
https://github.com/jungleminds/jm_api-boilerplate
api boilerplate dependency-injection ecmascript es6 eslint javascript nodejs prettier server wbso
Last synced: 2 days ago
JSON representation
A boilerplate for web APIs using Nodejs - based on Domain Driven Design and Clean Architecture principles
- Host: GitHub
- URL: https://github.com/jungleminds/jm_api-boilerplate
- Owner: JungleMinds
- License: mit
- Created: 2018-10-03T08:20:22.000Z (about 6 years ago)
- Default Branch: master
- Last Pushed: 2023-01-04T15:50:21.000Z (almost 2 years ago)
- Last Synced: 2023-03-02T15:33:19.444Z (over 1 year ago)
- Topics: api, boilerplate, dependency-injection, ecmascript, es6, eslint, javascript, nodejs, prettier, server, wbso
- Language: JavaScript
- Homepage:
- Size: 2.38 MB
- Stars: 4
- Watchers: 4
- Forks: 1
- Open Issues: 25
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# JM API Node
[](https://circleci.com/gh/JungleMinds/JM_API-Boilerplate/tree/master)
[](https://github.com/prettier/prettier)
[](http://standardjs.com)
[](https://twitter.com/acdlite/status/974390255393505280)
[](https://david-dm.org/JungleMinds/JM_API-Boilerplate)
[](https://david-dm.org/JungleMinds/JM_API-Boilerplate?type=dev)
[](https://codeclimate.com/github/JungleMinds/JM_API-Boilerplate/maintainability)
[](https://codeclimate.com/github/JungleMinds/JM_API-Boilerplate/test_coverage)
A boilerplate for web APIs using NodeJS
the boilerplate follows an architecture inspired by Domain Driven Design and Clean Architecture. It implies in some patterns and methodologies having to be followed to ensure separation of concerns and make the codebase more maintainable.
## Features
---
## Folder structure
This boilerplate uses a folder structure and logical architecture focused on separation of concerns based in Domain-driven design and Clean architecture. Instead of the classical controllers/models/services folders, we now have layers inside the src folder. Each of the folder layers is scoped by a namespace regarding the concern it is about (like user, errors, logging and so on):
### Application layer (app folder)
The application layer defines the actual behaviour of our application, thus being responsible for performing interactions among units of the domain layer.
### Domain layer (domain folder)
In this layer, we may define units which play the role of entities and business rules and have a direct relationship to our domain
This is the most isolated and important layer of our software, and it may be used by the application layer to define use cases.
### Infrastructure layer (infrastructure folder)
This is the lowest layer of all, and it’s the boundary to whatever is external to our application: the database, email services, etc.
### Input interfaces layer (interfaces folder)
This layer holds all the entry points of our application, such as controllers, websockets, etc.
It should not have any knowledge about business rules, use cases, persistence technologies, and not even about other kinds of logic!
It should only receive user input (like URL parameters), pass it on to the use case and finally return a response to the user.
├── app
├── config
│ └── environments
├── domain
├── infrastructure
│ └── logging
└── interfaces
└── http
├── controllers
├── errors
├── logging
└── utils
## Prerequisites
#### Docker
Install [Docker](https://www.docker.com/) on your system.
- [Install instructions](https://docs.docker.com/installation/mac/) for Mac OS X
- [Install instructions](https://docs.docker.com/installation/ubuntulinux/) for Ubuntu Linux
- [Install instructions](https://docs.docker.com/installation/) for other platforms
#### Environment Variables
The initial (default) environment variables have been set for you in the `.env` file. If you need to have custom variables in your dev process you can use a `.env.local` file to override those. The application will use the following files in the following order to create a final set of variables:
1. `.env`
2. `.env.local`
3. `.env.`
4. `.env..local`
A server (via docker container) will **ONLY** read the `.env` file, so server specific variables should either be passed along in the build command (`ENV_VAR=value `) or in the server configuration.
## Setup
1. Run `npm i`. It will install all dependencies.
2. Run `docker-compose build`. It will pull a base images from the Docker registry.
3. Run `docker-compose up`. This will bootstrap a new app in your container optionaly add optionaly `-d` Detached mode: Run containers in the background.
4. Run `docker-compose down` It will Stops containers and removes containers, networks, volumes, and images created by `up`.
The app should then be running on your docker daemon on the port you specified in your `.env` file (default: `4050`) or override (see Prerequisites > Environment Variables)
## Scripts
This boilerplate comes with a collection of npm scripts to make your life easier, you'll run them with `npm run `
`npm run start` run the application
`npm run start:watch` run the application in watch mood on every file change
`npm run test` run all unit tests for the appliction
`npm run test:watch` run all unit tests for the appliction in watch mood on every file change
`npm run test:coverage` Create a coverage report for your code and determine whether your coverage is high enough
`npm run lint` Run linting on the application codebase