[Appreciated soft top working group] Technical Specifications

First, introduce the technology stack

front end

We produced product is a Android APP, all developed for production based on Google's Android SDK. We use Android Studio for development, the development of language Java.

Android Studio on IntelliJ IDEA, is Google's Android provides developers with development tools on the market today is the most widely used Android development IDE. In the framework of the software development, we can use the powerful and convenient layout editor, drag the effect of UI controls and carry out a preview.

While our goal is that all users Northern students, but also take into account a lot of Northern students to use iOS system, but due to the number and time, we iOS No front-end development plan, and strive to deliver the finished product in the Android platform as soon as possible. If the Alpha version of the design has been well received, we will consider the development of front-end iOS.

rear end

Backend Django as a framework, MySQL as the database to achieve Python-based language.

Django itself is a balance between the front and rear ends of the frame may also be able to do the whole stack development, but we only use the relevant functions of its backend. Django MVC design pattern has a foundation, the foundation provides a number of features to meet the needs of our end before and after the interaction. We might consider using Django REST Framework as a back-end implementation framework, reflecting RESTful development.

database

Database using MySQL. MySQL database is the most familiar is the use of a large number of databases, more stable, and the related technology is more mature, and phase of Django is also very good.

Django comes with SQLite database more portable, can be used as local debugging use, but not for the deployment of more supply people use on the server, performance may be limited.

reptile

At present due to security reasons, the school did not directly interface to the database to read open to students, we can not get the data on the educational websites in a conventional manner. But we still want to make this piece of software, it is forced to select a reptile to get the data

As the session verification Northern Senate is more complex, and educational systems have iframemore complex structures and the like, it is difficult to use a general framework for reptiles, so we chose an easy to use a headless browser Selenium as a tool to get data from school.

We will control the frequency of crawling and data, will be guaranteed not to carry out cross-border operations to protect the user's security to a great extent.

At the same time, the database static data storage using encryption, decryption key is generated by user, rests in the hands of users, allowing developers unable to get to everyone's unified authentication account by a simple way to query the database.

Cloud environment

We tentatively set course using Huawei cloud resources provided for 1 core 1G server.

Taking into account the actual situation, a nuclear 1G too, may not be able to meet our needs, when higher frequencies reptiles crawling, could lead to insufficient memory, and the most important server bandwidth more or less will affect our response speed. If it is found insufficient in practice, it may consider their own expense to replace higher server configurations.

Second, the front and rear ends Interface Design

Front and rear ends butt using HTTPS request to complete. At the same time, we follow RESTful principles of design ideas, just call the front-end interfaces to get data, you do not need to think inside details. Architecture design is shown:

The following is a tentative interface rules, to be further refined.

# Request method Request path use
1 POST /api/users/phone_num/verify/code Send phone verification code
2 POST /api/users/phone_num/verify Verification code is correct
3 POST /api/users/email/verify Verify mailbox, send a letter to the mailbox
4 GET /api/users/email/verify/:uid/:hash_code Verification email, click the link to return mailbox
5 POST /api/users/forgetpassword/email Forgot your password, bound mail
6 GET /api/users/forgetpassword/email/verify/:uid/:hash_code Forgot your password, email jumps
7 POST /api/users/forgetpassword/phone_num/send Forgot your password, phone
8 POST /api/users/forgetpassword/phone_num/verify Forgot your password, phone verification
9 GET /api/users/:uid/get_class Gets Timetable
10 GET /api/users/:uid/update_class Update Timetable
11 GET /api/users/:uid/todolist Course Center ddl query
12 GET /api/empty_room Empty classroom inquiry
13 GET /api/users/:uid/get_score Result inquiry

Third, design principles

  • abstract

    • Abstract behavior

      Abstract act mainly on the interactive front-end and back-end, back-end and reptiles. We are the interface for specific functions were clearly defined, in which the caller does not need specific operation to worry about.

    • Data Abstraction

      We will present all of the data in the database, the database design in models.py, each packaged in a target table, read and write operations to facilitate additions and deletions. While changes in the structure of the maintenance records for the migration, facilitate future development and maintenance.

  • Cohesion / coupling / Modular

    Mainly on the back-end design. Django framework itself used to support the rear end of the MVC pattern is more convenient, each of the different features can be designed into different djangoapp, each method has its own djangoapp management, do not affect each other in the data and functions therebetween.

    The front APP also divided into different pages, each page has its own independent function, they do not affect each other, each page of their duties, to complete their own function, which is the inevitable development of the division.

  • Separation information hiding and encapsulation, interfaces and implementation

    Hidden encapsulation information, a principle separation architecture are front and rear ends. We did not put all the queries in the user program to achieve, but experienced users - Servers - educational process, to interact with as little information as to hide between, only through the API exchanges with each other without exposing the internal details.

    The user's hand distal Android APP, itself has good encapsulation, and illegal reading data unpack with some difficulty, and has a good package to help hide information, interface and implementation separation.

  • How to handle error conditions

    As an Android APP, the front left to the user the opportunity to make mistakes is very limited, if simple mistakes like illegal input occurs, it will be detected at the front, it does not send the request to the backend.

    Most errors will be detected in the back-end. Once the errors are detected, or the rear end of the inner crawler crawling error occurs, returns the corresponding HTTP Status Code, to determine what kind of error has occurred. The front end of the Code translated into text that tells the user what specific error occurred that give users detailed operating instructions.

  • Templates for the operating environment, related templates, input and output parameters have any hypothesis? These assumptions and associated personnel verified it?

    Operating environment and template-based front-end Android platform, which itself has a large number of applications available for reference, and our products are not performance and network requirements, it will not have much of a problem.

    Back-end there may be some problems for high concurrency processing reptiles, mainly server resource consumption is too large, resulting in performance can not keep up, if questions arise subsequent practice, we will immediately replace the cloud environment.

    Front and rear side interaction dependent HTTPS request, input and output parameters itself has very strict standards limit, and we have good error-handling design, it will not be a big problem in the interaction.

  • Flexibility to cope with change

    Flexibility is built on a modular and low coupling. We try to separating the front and rear end, back-end modular as possible is also based on this. If new needs arise, or educational sites unforeseen circumstances, we can modify as little as possible in the code, the completion of our work, to reflect a high degree of flexibility.

  • Large amounts of data processing capabilities

    For the back-end processing power of a large number of requests from the front, built on the performance of the Django framework of rationality and the server itself, both of which have been verified in other large projects. In the interface design, we have as far as possible the API and data content was simplified because the interface does not deal with problems caused by the difficulty of qualifying.

    For a large number of reptiles command from the back-end processing may be a difficulty. The server itself does not support the bandwidth and resources to open high-chrome concurrent queries, so our solution is to minimize the number of crawling. Can be solved by caching mechanism to determine the data in a short time will not change, we will not repeat crawling, as far as possible to reduce the pressure on the server.

Guess you like

Origin www.cnblogs.com/se2020djlj/p/12650551.html