** Abstract: ** In this article, we will discuss why we need to separate the front and back end in software development, how to separate the front and back end, how to decouple.
In a nutshell, it’s about taking complex problems and simplifying them, turning a problem from zero to N into N problems from zero to one. A similar term is “decoupling”.
For example, we received a customer needs, asked to write an application that has a page in the application of the switch, there is a corresponding page data interaction, data acquisition, data calculation, if put these features in a single application, from the perspective of the vision, this single application is more complex.
In order to reduce this complexity, the first thing we need to do is to separate the front and back ends. About the definition of the front and back ends, generally speaking, it is as follows: the front end is responsible for page path management, page corresponding data display and management, etc. The back-end is responsible for the main content of data provision, data calculation, security management and so on; Communication between the front and back ends is generally achieved through HTTP requests. Of course, there are exceptions. For example, some functions may require real-time performance, such as chat functions, document sharing functions, drawing board sharing functions, and multi-person collaborative operation functions, which need to be implemented through socketio communication mechanism.
To break it down further, a single application framework Model will be MVC (Model-View-Controller). After the front and back end are separated, the back end will have Model/ entity-repository/service-Controller, and the front end will have view-Model-API calls.
** Look at the front part, **View mainly refers to the web page, mobile page (Android is Activity, Layout and View, iOS is View Controller and UIView, etc.), If you use cross-platform technologies (React Native, Flutter, Xamarin, etc.), this concept is similar. This part of the processing, of course, depends on the data Model and API calls. After that, the front-end tasks are done.
** Look at the back end, ** interface related processing is no longer a task of the back end, the back end only needs to provide the data required by the front-end through the API. Controller is used to define these apis. This part will analyze or calculate the input and output models of the front end. The specific processing methods are considered by the following factors: Request types such as GET, POST, PUT, DELTE, PATCH, etc. Data From Body, data From Route, data From Form, etc.; After the data is processed, one is returned through API, and the other is to update the data source, which can be database such as SQL and NoSQL, message middleware such as Kafka, or data buffer server such as Redis and so on. From the above description, we can see that the tasks on the back end are much lighter and logically simpler.
So, by separating the front and back ends, we keep the complexity of the front and back ends under control. If we use this philosophy consistently in software development, we can greatly expand our software development efficiency and program quality. Because solving one n-difficulty problem is obviously much harder than solving N 1-difficulty problems. For a problem of N difficulty, we divide it into N problems of 1 difficulty, we can beat them one by one, step by step, step by step, in the work calmly and confident, because we always use the simplest way to solve the problem. If you have a complex problem, break it up into multiple problems of difficulty one, and so on. To put it simply, it means making sure that when we come to solve problems, we don’t start off unprepared, we keep our feet on the ground, divide and rule, and avoid roasting ourselves on the stove.
When complexity is reduced, the maintenance cost and expansion cost of the whole project will be very low. Our ability to control project development will also improve a lot.
There’s another problem with data flow, which is mostly in the front end. This part of the processing is directly related to the complexity of the front-end programming. There are two-way data flows and one-way data flows in the three front-end frameworks. React only supports one-way data flows. Now with Hooks, you can pass both Setter and Getter references to modify data. This pattern of passing parameters to other components actually increases the complexity of the program because the layers of passing increase the coupling between components.
So how to solve this problem?
Angular solves this problem by defining getters and setters in a Service. Every component that needs to manipulate data can rely on the Service to inject it. With the Service, it is easy to read and update data. By defining a Subject in the Service and listening for data changes, you can update the interface, send requests to the server, and so on, and coupling between components is greatly reduced.
Again, one-way data flow mechanisms such as Ngrx, VueX, Mux, etc. The one-way data flow mechanism is commonly used in current front-end development, however, it can actually increase the complexity of the application. This is mainly because this mechanism introduces another system in the front-end development hierarchy to maintain the flow of data. If we add this mechanism to the existing business as a zero to one implementation, then it becomes a zero to one plus another zero to one, and it becomes a zero to two problem. That’s where it gets complicated.
The front-end just needs to do the following tasks such as page switching, data and back-end interaction, data model and API correspondence, and components should be self-contained as much as possible.
So I don’t recommend adding a similar data flow mechanism to the front end.
Let’s talk about back-end analysis. When we talk about the back end, we don’t really care what technology we use (Node JS,.NET Core, SpringBoot, PHP, Python, Ruby On Rails, etc.) because the logic is clear and the hierarchy of application design is pretty much the same regardless of which technology you use.
The main task of the back end is to provide API data. For example, the user API, creating a user, updating a user, deleting a user and so on are defined in a user Controller API. For Controller additions, I recommend adding them according to the business layer and not doing too much in one Controller. For example, we could add a Book Controller to handle book-related operations and an order Controller to handle order-related operations.
This is done to minimize the coupling between linear, parallel API designs and their respective controllers, thus reducing complexity.
Further, at the implementation level, we can have Data sets for database tables, Entity for Data table records, Model for API Data models, Service/Repository for logic implementation, and so on.
In the selection of back-end technologies, database-related operations are an insurmountable threshold, and some frameworks use mechanisms similar to EntityFramework such as. NetCore and PHP Laravel, some use JPA Hibernate, Mybatis like Spring Boot, some directly use JDBC SQL statement execution, and some combine Stored Procedure. In this place, the order in order of program complexity is EntityFrameWork<JPA Hibernate+Mybatis< JDBC SQL < Stored Procedure.
Of course, database design, database upgrade Migration are also related to the program project complexity factors. This is in the context of specific back-end technologies. We won’t expand it in this article.
Ok, this paper mainly discusses the role of front and back end separation, how to carry out front and back end separation, how to decouple, there are shortcomings, please correct.
Click to follow, the first time to learn about Huawei cloud fresh technology ~