Shulou(Shulou.com)06/01 Report--

Today, I would like to share with you how to do a mobile application from scratch in web back-end development. The content is detailed and the logic is clear. I believe most people still know too much about this, so share this article for your reference. I hope you can get something after reading this article. Let's take a look at it.

Doubts about back-end development

One of the most common problems faced by back-end developers: performance, high concurrency, and so on. But this is beyond the scope of this article, we will only talk about the basics of how to write the code and how to divide the business modules.

Most of the solutions with high performance and high concurrency are extensions outside the code.

So from a purely coding point of view, how to write back-end code? I used to wonder: what kind of code does the Controller layer put? What can Model do? How to organize some of your own extensions and tool classes?

It is found that there are fewer doubts that can be remembered now. If you have any doubts, please leave a message and we will study and discuss together.

Although the code is mainly to implement business logic, choosing a good framework is very helpful to improve the team's ability to work and make the performance at the code level worry-free.

The choice of framework

To tell you the truth, since the php7 came out, the performance at the code level has reached a very high level. Basically in the million-level system, there are no concerns at the language level.

In terms of framework, the php frameworks I have used include (in chronological order): ThinkPHP Laravel non-famous self-made framework Yii Phalcon

In this paper, all the code structure design and organization design is based on Phalcon, except for the self-made framework is a very excellent framework, but the performance at the framework level, as far as itself is concerned, is gradually improved. However, through some integration, we can also gradually improve its own performance, such as: the combination of Laravel Yii and Swoole, can also reach the degree of Phalcon.

The version of php is: 7.1 (if you are a new project, be sure to use php7)

What does the back end do?

Of course, you need to design the db first, but this is outside the scope of our discussion, assuming that this step has been completed.

Our code needs to provide the following capabilities: 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 and small projects are not necessary (put in one project to enhance the reusability of the code)

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

Command line script

First of all, the command line script is a relatively independent part, which does not need to be called by the user, and is mainly used to complete some scheduled tasks. This module is provided in more modern frameworks.

Phalcon provides a CLI module that can easily complete this part of the capability. His code is still written in the structure of mvc, except that the access is done from the command line.

Like the simplest cli.

Class MainTask extends Task

{

Public function mainAction () {

Return fwrite (\ STDOUT, 'hello taskstores')}} api module

When I first came into contact with the concept of api, I was very confused and felt very lofty. Now my understanding of it is: a way of pure data communication between front and rear. In the past, when we did web development, we did not provide api, but directly rendered the data on the page in the back segment, and the user operated directly on the rendering interface, and then triggered a request to the backend through buttons or something.

In the era of api, there is a concept of front-end separation in web, and the mobile app back-end is even more unable to render (natural front-end separation). So the background needs to send the data to the front end, and the front end shows the data in a way that the user can understand according to the description of the data. For example, the api of a product may be structured as follows:

{code: 1, msg: 'query ok', data: {name:' coolest air conditioner', price: '9999.00 air conditioner, img:' xxx.webp', stock: '10'}}

This approach allows front and rear developers to be independent of each other and to focus on doing their own things. But this also brings another problem: the front end has the so-called version, and the back end must take into account all the versions used. If we always use only one api address. Then the code can be pretty ugly.

For example, now there is a new demand. In the past, there was only one picture for air conditioners. Now there are many pictures when the air conditioner is displayed. So there are two ways, one is to add fields, and the other is to change the original field img into an array.

If it is adding fields, it will not bring compatibility problems. However, if you rudely change the img type to an array, the previous version will not be able to resolve the type, so if you want to change it to an array, it can only be an overall upgrade of api (it is not usually upgraded because of this problem).

So what are the ways to make a version of api? I use the module of Phalcon to do the version control of api. The controller version has been tried before. For example:

ApiV1Controller indicates that this is the v1 version. ApiV2Controller indicates v2 version. Phalcon module provides great convenience for the version, directly open a new module, named v1, if you want to upgrade later, open a new module called v2. For functions that do not need to be modified, you can simply let the v2 controller inherit the controller in v1.

In terms of the version of api, we can simply do it through url, such as:

Https://api.xxx.com/v1/user/123

Https://api.xxx.com/v2/user/123

Version information is very clear at a glance.

back-stage management

Most systems need a cms to upload and modify relevant information. Take Accelerator as an example: need to upload games, need to edit some game collections and so on. You can develop it as a separate project or as a module (I recommend that code reuse is provided to a great extent).

The last thing I can accept is: do it backstage, anyway, it's for internal use in the company.

As an aspiring programmer, we must have a bottom line, and our goal is to make it easier and easier for everyone to work, and finally make everyone without a job (ha). So in the background, I also recommend using front and back end separation, through Vue for development.

The current background uses Vue + Element UI + Vuex + Vue-Roter for development. Reference, the network: touch your hand, take you to play backstage with vue, the writing is really good, for me to learn to save a lot of detours, especially in the front-end access control of this part, his way let my eyes bright. My backend has just finished building the basic parts (routing planning, some self-extended vue plug-ins).

After the front and rear ends are separated, the latter part can actually be attributed to the development part of api. And one of the benefits of this is that if you want to do some of the functions of the mobile version in the future, api is ready-made.

These are all the contents of the article "how to make a mobile application from scratch in web back-end development". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.