Beautiful Summerdale nordan, she’s gonna stay a few nights this year

The front-end page is created by (Vue + Vux + Vuex + VUE-Router). My GIF is too big for wechat.

Project address: http://m.jiasux.com, you can open your mobile phone to view the effect.

---

All right, cut the crap. Let’s talk about the back end

What do I write on the back end, what would be a better summary for me and a better help for you? In preparing to write, I thought long and hard.

Before preparing hand to hand, mouth to mouth tutorial. I thought maybe it would be more helpful to summarize the back-end structure design, code organization, and module division.

Backend development confusion

One of the most common issues facing back-end development: performance, high concurrency, and so on. But that’s beyond the scope of this article. We’ll just cover the basics of how to write good code and how to partition business modules.

High-performance, high-concurrency solutions, mostly extensions out of code.

So standing in pure code writing perspective, how to write good back-end code? I used to wonder: What code does the Controller layer put in? What can a Model do? How do you organize your extensions and utility classes?

Found that now can think of less doubt, if you have any doubt, welcome to leave a message we study together to discuss

While the code is primarily about implementing business logic, choosing the right framework can greatly improve your team’s ability to perform at the code level.

Choice of frame

To be honest, after php7 came out, the code level performance has been to a very high level. Basically a system in the millions has no language concerns.

In terms of frameworks, I have used PHP frameworks including: ThinkPHP Laravel Yii Phalcon

All of the code structure and organization design in this article is based on Phalcon, and the other frameworks are excellent except for our own, but the performance at the framework level, by itself, is gradually improving. However, through some integration, its performance can also be gradually improved, for example, Laravel Yii combined with Swoole can also reach the level of Phalcon.

PHP version 7.1 (if you are a new project, be sure to use PHP7)

What does the back end do

Of course you have to design the DB first, but that’s beyond our scope, assuming you’ve already done that.

Our code needs to provide the following parts of the ability: command line script, API version, background management of these three parts. Of course, these three parts can also be divided into three projects, but small companies, small projects are not necessary (put in one project, strengthen the reuse of the code)

These are three big modules, and then one by one.

Command line script

First, the command line script is a relatively independent part that does not need to be invoked by users. It is mainly used to complete some scheduled tasks. More modern frameworks provide this module. Phalcon provides a CLI module to facilitate this capability. His code is still written in an MVC structure, but access is done from the command line.

For example, a simple CLI

class MainTask extends Task

{    

    public function mainAction()
    {

return fwrite(\STDOUT, 'hello task! ')}}Copy the code

The API module

When I first encountered the concept of the API, I was confused and felt superior. Now my understanding of it is: a way of pure data communication between the front and back ends. When we were doing Web development, we didn’t provide apis, we rendered the data on the page directly in the back, and the user would operate directly on the rendered interface, and then trigger a request to the back end through a button or something.

In the ERA of APIS, there was the concept of front and back end separation on the Web; The back end of mobile app is even weaker to render (natural front and back end separation). Therefore, the background needs to send the data to the front end, and the front end shows the data in a way that users can understand according to the description of the data. For example, an API for a product might have the following structure:

{code: 1, MSG: 'query OK ', data: {name: '9999.00', img: 'xxx.webp', stock: '10'}}Copy the code

This approach allows the development of the front and back ends to be independent of each other and everyone to do their own thing. But this brings up another problem: with a so-called version on the front end, the back end must take care of all versions in use. If we only use one API address forever. The code could be pretty ugly.

For example, now there is a new demand, before only one picture of air conditioning. Now there are multiple pictures when the air conditioner is displayed. So there are two ways to do this: one is to add fields, and the other is to change the img field into an array.

Adding fields does not cause compatibility problems. However, if an IMG type is violently changed to an array, the previous version will not be able to resolve the type, so the only way to change to an array is to upgrade the API as a whole (not usually because of this issue).

So what are the ways to do API versioning? I used Phalcon’s module for API versioning. Controller versions have been tried before. For example: ApiV1Controller indicates that this is version V1. ApiV2Controller indicates that the version is V2. Phalcon’s module is a great convenience for versioning, with a new module called V1 and a new module called V2 if you upgrade later. For functions that do not need to be modified, the V2 controller can simply inherit the v1 controller.

The version of the API can be done simply through the URL, for example:

• https://api.xxx.com/v1/user/123

• https://api.xxx.com/v2/user/123 version information is very clear.

Background management

Most systems need a CMS to upload and modify relevant information. Take Speedman for example: you need to upload a game, you need to edit some game compilations, etc. You can do it as a standalone project, or you can still do it in modules (which I recommend, with a great deal of code reuse).

My most unacceptable sentence is: backstage by the way, anyway for internal use of the company.

As ambitious programmers, we have to draw a line in the sand. Our goal is to make it easier and easier for people to work, and ultimately make people unemployed. Therefore, I also recommend the use of back-end separation, through Vue to develop.

The current backend is developed using Vue + Element UI + Vuex + VUE-Roter. Reference, the network: hand touch hand, take you with vue lu backstage, write really good, for me to learn to save a lot of dettour, especially in the front of the authority control on this part, his way to let my eyes a bright. My background is just finishing up the basics (routing planning, some vUE extensions myself)

After the front and back end are separated, the back end actually comes down to the development part of the API. And one advantage of this is that if you want to do some mobile functionality in the future, the API is already available.

To be continued

The longer you code, the more you learn about the language, the more you do it, the sooner you get to a level. But no amount of business code is going to get you very far in technology. So if you are lucky enough to be in a large company and have access to a large project (millions, tens of millions of users), you must take a good look at the project for the development of so many people, but also very good operation? How does he decouple business logic from system architecture? If it is in a small company, then try to do some system construction as far as possible, so that we can carry out business development on this basis, and do not need to care about some of the bottom things, a novice can also quickly write business.

There will probably be two to four more on the back end. This includes the segmentation of the back-end project structure (which I have tried to use in 3 or 4 projects and have worked well so far), back-end login control (which will open source a Phalcon oAuth2 code), and automated testing of the back-end API.

I will continue to post relevant code on Github. Let’s call all of this code x minus. X has left a deep impression on me since primary school mathematics.

• X-api is a back-end project for PHP

• X-control is a vUE written back-end management system

• X-client is a vUE client interface

---

If you are interested in my content, please follow my wechat official account:

Public id: ICanfo

Personal blog: https://helei112g.github.io/