node. JS Project Unpacking Engineering

Background

In our development process, often encounter such problems, developed a number of code or an interface, the other small partners came to ask you, the code can be reused, the interface to call him. This means that the reuse and abstraction of code is important for team collaboration. As an example,

In this picture, a service developed first, B service development is similar to a service function, as far as possible to use a service interface to improve efficiency, then B service is dependent on a service, this will produce the following pain points

1. If the B service has a demand, a service is not satisfied, then the need to first mention to a service, if a service of small partners do not have time to develop ... Then the B service can only wait, because this is a dependency.
2. Code reuse, because it is through the interface, so there is no reuse
   To solve the two pain points, the general idea is to do a service sink abstraction, find a team to do, or contract a service group and B service group to maintain a sinking service, here we use node. js to develop A, B projects, through the package instead of Web services, can provide a different way of thinking, Optimize the dependencies of A and B projects by engineering the node. JS Project, enabling development support for B services while developing a service

Ideas

How to develop a service side to provide external support? node. JS is the abstract form of the package, that is, we develop a service side to publish public packages, we look at the following picture

This is a KOA project directory, the problem comes, in addition to Node_modules, this project can have a few packages, someone will say a project is a package, we first write a simple example, such as

Add a routing address inside the routes to invoke the methods inside the services

const router = require('koa-router')()const FooService = require('services').FooServicerouter.get('/queryFoo', async (ctx, next) => {  let fooService = new FooService()  ctx.body = await fooService.queryFoo()})module.exports = router

Write a service

class FooServices {  async queryFoo () {    return 'foo'  }}module.exports = FooServices

The following starts the transformation:
Add Index.js and Package.json to the services and expose fooservice.js through the index.js, so that services we break into a package.

Then directly to the services into the node_modules inside, modify the routes inside the introduction of the Index.js

const router = require('koa-router')()const FooService = require('services').FooService //修改router.get('/queryFoo', async (ctx, next) => {  let fooService = new FooService()  ctx.body = await fooService.queryFoo()})module.exports = router

Then routes can become a package, models may not, of course, although not so extreme to all the package, but the services into a package, the effect is very good, such as

Here we can define, a service in the development, but also the development of a common sunken service package, after the development of services, a group can continue to develop controller, view layer, B group on the basis of services can begin to develop, Do not need to wait for a service to be developed, more efficient, more flexible teamwork.

Realize

The above just provides an idea that the realization of this idea requires a process, first of all, to say what the problem arises:
Question 1, if we split the services into a single project, we can ... But we developed the time back very depressed, will encounter: Modify services, package, debug, modify, Contract, package, Debug ... That's a real hassle.
So how to solve the package dependency in a project, let's look at a way to realize it:
Write a JS script to link the Services folder to Node_modules by creating a symbolic link

#!/usr/bin/env nodeconst fs = require('fs');const path = require('path');const rootPath = process.cwd();fs.symlinkSync(`${rootPath}/services`, `${rootPath}/node_modules/services`, 'dir');

Arbitrarily configure a command to configure the Invoke script command to Package.json

  "scripts": {    "start": "node bin/www",    "dev": "./node_modules/.bin/nodemon bin/www",    "prd": "pm2 start bin/www",    "test": "echo \"Error: no test specified\" && exit 1",    "l": "node bin/link"  }

Executing scripts with commands

npm run l

After establishing the symbolic link, modify the code inside the services, and the services in the node_modules will change, so that we can solve the problem above.
Note: Here is just to provide ideas, to improve the function, please have the interest of the small partners to achieve their own.

Question 2, the above project we only develop a package at the same time, if in a project to develop dozens of packages at the same time, the introduction of the package and release, not every time to do dozens of times, this problem is OK, the more frightening is, if the dozens of package also has a citation relationship .... Can not imagine, then look at the following example,

There are two packages in the services, below we use zz-foo-services to refer to zz-bar-services, and references between multiple services are very common.

The problem came, Zz-bar-services did not publish, from where to quote ah, difficult to build a script to build a symbolic link, if more than dozens of packages have dependencies, how to build a link AH ~ ~ ~
Here we need to use Lerna to help us manage a project of multiple packages of package dependencies, package release, etc., such as Babel project development is the use of Lerna for package management, release, below we look at the use of Lerna.

Installing Lerna

npm i -g lerna

Initialization

Executing commands in the project root directory

lerna init

In the root directory to build a packages, is the Lerna management of the directory, we have just moved the package to this directory, such as

Use the command to install the dependencies of the package inside the packages

lerna bootstrap

This command executes NPM I and creates a symbolic link

For example, Zz-foo-services has been linked in.
Note: Here packages inside of the package link to node_modules, interested in the small partners to try their own hands.
Issue 3 multi-package version management, here we use the Lerna Publish command to bulk publish the package out, here we do not cite examples, interested in the small partners can try their own hands.

Summarize

With the project Engineering of node. JS, we can develop multiple packages at the same time in a project, manage multiple packages, make a closer team collaboration, package efficient split, package management and optimization of the development process, the author just provides some engineering ideas, in order to produce best practice also need to do a lot of optimization.