Business reason

With the continuous increase of business, the current system has accumulated 23 large business modules, each module has a lot of code. It would have been a nightmare to build react as a single unit, which was not split three years ago. I don’t think you can get home without 50 minutes have a nice dream.

Although the RcModule module injection function has been implemented, the long waiting time has been liberated during construction. However, the unnecessary code, as well as some core codes such as base.config.json, need to be removed in the standard when the project is delivered. There are customers did not give money to the code to delete their own.

Each time there is a lot of repetitive work in the bid before it can be delivered to the customer. For example, the PAAS service is not delivered to the customer, so I have to delete the review code to delete it. But some clients only needed a fraction of the functionality of certain modules, which made my job extremely complicated during delivery.

Sometimes c++ engineers are required to generate a binary file and then package it in V8 with c++ extensions that decrypt it during build time. So even if the client gets a piece of the code, they don’t know how it works.

Out of 23 business modules, if some clients only need 7 business modules, the workload for me is barely acceptable. However, when some big clients require 18 business modules and huge systems such as SRM and ERP, I will delete the redundant code. In order to protect the data of the standard products safely delivered to the hands of customers, this workload is undoubtedly a huge pit.

Why Cli?

At this point, I don’t need a simple project creation (management/build) tool like VUe-CLI or umiJS. I need powerful CLI tools like @angular/ CLI to implement multi-module project management

Such as ng’s

  1. addAdd support for external libraries to your project
  2. buildCompile the Angular application into an output directory named dist/ in the given output path. This command must be executed in the workspace directory.
  3. configGets or sets the configuration values for the project from the xxx.json file in this workspace.
  4. docQuick build opens project docs for document review
  5. i18nExtract i18N information from the source code and configure it
  6. newAdd a module quickly
  7. removeThe related code is removed by eny.yaml configuration and is not delivered to the customer.

Unfortunately, only NG currently provides a powerful CLI, but it’s open source.

Unfortunately, it’s not the React ecosystem. As a result, I spent a period of time looking for the React related CLI, but faced with the result that there was no such tool, almost used to build the scaffolding of the project, and then had to cooperate with their framework, such as UMI can expand by themselves.

But Ali open source, KPI will hang.

Forced to build their own trench coat foot food in-house CLI tools to facilitate developers/CRUD’s simple low code builder.

Side note: Low code is not the kind of thing that gets advertised these days. Low code is similar to code builders. The resulting things have to be processed by programmers, low code already exists, and that’s why the front end is slow to develop, and it’s very difficult to visualize it, and program development is about maintainability, not this kind of virtual head. If you think about what happened to dreamweaver and ASP.net webFrom 20 years ago?

Zero code is not as magical as it sounds, ok, zero code can do knowledge of the industry common workflow collection. You can think of it as a workflow framework for back-end event development. Workflow can solve 70% of your problems, but there are 30% unknown problems that can’t be solved. So zero code works, but it still doesn’t completely replace the other 30%. If it were possible, 20 years of work flow would have already killed the programmers, why do we need so many people on the back end to stack the business? Early began to enter the system design system optimization era. Like foreigners, the long-term maintenance costs are considered before the project is set up…

Choose Node or Golang

In the early days of cli, I was still thinking about using Node, Golang, Java? But Java configuration environment, there are a lot of OOP programming specifications to work on, I do not have a big project. Just to make it easier for projects to do ancillary work, such as low-code template generators.

The final choice is between Node and Golang.

First, 10W write operations are performed for comparison

Since I need to do a lot of read and write operations on the project, I am concerned about the read and write performance. Companies use YAPI for code generation. Back-end annotations generate YAPI documents, and the front end generates the data invocation layer of the front end via yapi-to-typescript. In the beginning, when the number of interfaces was small, the generation time was acceptable, but now the system has nearly 2W interfaces. Node.js does write operations and waits 8-10 minutes each time a deployment goes live to get the latest DB layer

/* Copyright © 2022 NAME HERE 
      
        */
      
package main

import "os"

func main(a) {
	file, _ := os.OpenFile("./write.txt", os.O_CREATE|os.O_RDWR|os.O_APPEND, 0777)
	defer file.Close()
	i := 0
	for i < 100000 {
		file.WriteString("a\n")
		i++
	}
}

Copy the code

The result of the go

React-boot -cli $time go run main.go real 0m4.214s user 0m0.842s sys 0m2.991sCopy the code

Because of the Node.js API file, I only know how to write this. Maybe the way of comparison is not correct. But the WAY the API is, I can’t help it.

const fs = require('fs')

let i = 0;

while(i<1000000){
    fs.appendFileSync("node.txt"."a\n")
    i++;
}
Copy the code

Node.js writes the result 10W times

React-boot -cli $time node main.js real 0m55.923s user 0m7.118s sys 0m44.187sCopy the code

😓 Speed varies by day, which would be acceptable if it were just a builder for creating CRUD templates. However, if it is to deliver the project instead of manpower to do a large number of read and write, remove operations, this will let me move very painful, plus Node.js multithreading also need to configure their own. Thinking of these reasons, I directly chose Golang to start this project, and applied to the company for an intermediate Golang developer to assist me in my work.

In this coding, I chose Cobra, the famous CLI open source library of Golang

Introduction to the Cobra

Cobra is a command-line library that can be used to write command-line programs. It also provides a scaffold for generating a CObra-based application framework. Many well-known open source projects use the COBRA library to build command lines, such as Kubernetes, Hugo, etcd, and many more. This article describes the basic use of the COBRA library and some interesting features.

Quick to use

go get -u github.com/spf13/cobra/cobra
Copy the code

-u Install global variables similar to NPM I -g cobra

cobra init appname

cd appname && go mod init appname

Copy the code

The project structure that we have

Appname / ▾ CMD/helper.go root.go version.go main.goCopy the code

Add more commands

cobra add time
Copy the code

A command file is added to the CMD folder.

/* Copyright © 2022 NAME HERE 
      
        */
      
package cmd

import (
	"log"
	"os"
	"os/exec"

	"github.com/spf13/cobra"
)

// timeCmd represents the time command
var timeCmd = &cobra.Command{
	Use:   "time",
	Short: "For time.",
	Long:  It is actually a dome,
	Run: func(cmd *cobra.Command, args []string) {
		// Focus on this, the call being made
		c := exec.Command("bash"."-c"."time ls")
		c.Stdout = os.Stdout
		c.Stderr = os.Stderr
		err := c.Run()
		iferr ! =nil {
			log.Println(err)
		}
	},
}

func init(a) {
	rootCmd.AddCommand(timeCmd)
}

Copy the code

Let’s try go run./main.go time

Can also achieve our results, well today simple water article, from what reason to start doing their own CLI tools.