Division and coordination of the front and back

2014-08-03 01:06 by Barret Lee, 3214 Read, ... Comments, Favorites, editing

The front and back end division of labor is a commonplace topic, many companies are trying to use the engineering way to improve the efficiency of communication between the front and back, reduce communication costs, and also developed a large number of tools. But there is hardly a way to satisfy both parties. In fact, it is impossible to satisfy everyone. The root cause or the intersection between the front and back end is not large enough, the core of communication is often limited to the interface and interface to spread out part. This is why many companies in the recruitment of the hope that the front-end staff proficient in a background language, back-end students to understand the relevant knowledge of the front-end. first, the development process

The front end cut diagram, handle the interface information, and then the static demo to the background to stitching, this is the general process. There are many flaws in this process. After the end of the file to split the splicing, because the front-end knowledge is unfamiliar, may make a pile of bugs, to the end, and need to help the end of the students to analyze the reasons, and the front-end students are not particularly familiar with the back-end use of the template, resulting in embarrassing situation. If the front end does not use a unified folder structure, and static resources (such as pictures, CSS,JS, etc.) did not peel out to the CDN, but use the relative path to reference, when the back-end students need to make the relevant configuration of static resources, but also to modify the Link,script label src attribute, error prone. Interface problem back-end data is not ready, the front-end needs to simulate a set of its own, high cost, if the late interface has changed, their own simulation of the set of data again. The back-end data has been developed and the interface is ready to be tested locally for proxy online data. Here are two places to bother, one is the need for agents, otherwise it may cross domain, the second is the interface information if changes, late pick up your project people need to change your code, trouble. It is not convenient to control the output. In order to let the first screen load faster, we expect the back end to spit a bit of data, the rest is to Ajax rendering, but let the back end spit How much data, we are not easy to control.

Of course, the problems are far more than those enumerated above, and this traditional approach is really not cool (Kimi possessed ^_^). There is also a development process, SPA (single page application), the front and rear responsibilities are quite clear, the backend to me interface, I use AJAX asynchronous request, this way, in modern browsers can use Pjax slightly improve the experience, Facebook as early as three or four years ago on this SPA model presents a set of solutions, Quickling+bigpipe, to solve the problem of SEO and data spit too slow. His shortcomings are also very obvious: the page is too heavy, front-end rendering workload is also large first screen or slow back and forth template reuse can not SEO is still very dog blood (quickling architecture cost high) history management trouble

The problem is already unable to spit, of course, he still has his own advantages, we can not vote veto.

For the problems seen above, there are also some teams that try to add an intermediate layer between the front and back (such as Taobao ued Midway). The middle layer is controlled by the front end.

    +----------------+
    |       f2e      |
    +---↑--------↑---+
        |        | 
    +---↓--------↓---+
    |     Middle     |
    +---↑--------↑---+
        |        |  
    +---↓--------↓---+
    |       R2E      |
    +----------------+

The role of the middle layer is to better control the output of the data, if the MVC model to analyze the interface, R2E (back-end) only responsible for the M (data) This part, middle (middle-tier) processing data rendering (including V and C). Taobao ued has a lot of similar articles, here do not repeat. Ii. Core Issues

There are three common patterns that are seen in the business, and the core of the problem is who to deal with the data. Data to the background processing, which is mode one, data to the front-end processing, which is mode two, the data to the front-end layered processing, which is mode three. Three models do not have good or bad points, the use of it depends on the specific scene.

Since it's all a matter of data, where does the data come from? The problem goes back to the interface. The interface document is written and maintained by WHO. How the changes to the interface information are delivered to the front and back ends. How to get the test data available from the front and back by the interface specification. What kind of interface to use. Json,jsonp. How the JSONP security issues are handled.

This series of questions has been plagued by front-line engineers and backend developers fighting at the front. Taobao team made two sets of interface document maintenance tools, IMS and dip, do not know whether there is open, two things are based on the JSON Schema of an attempt, each has pros and cons. The JSON Schema is a specification of JSON, like we create tables in the database, we do some restrictions on each field, and here's the same principle, you can describe the field, set the type, restrict the field properties, and so on.

Interface document This thing, using the JSON schema to automate production, so just write a JSON schema without maintenance issues, add some restrictive parameters to the written schema, and we can generate mock (test) data directly from the schema.

External invocation of mock data, which is well handled:

typeof callback = = = "function" && callback ({
   json: "Jsoncontent"
})

In the requested parameters to add callback parameters, such as/mock/hashstring?cb=callback, the General IO (AJAX) library for asynchronous data acquisition do encapsulation, we use the test when the Jsonp, back to the line, the DataType changed to JSON on the line.

IO ({
  URL: "http://barretlee.com",
  dataType: "Jsonp",//json
  success:function () {}
})

Here a bit of trouble is the Post method, Jsonp can only use get way to insert the script node to request data, but post, can only hehe.

The processing here also has multiple ways to refer to: Modify Hosts, let mock domain name point to develop domain name mock Set header response header, Access-allow-origin-control

For information about how to get the interface across the domain, I also give a few reference solutions: Fiddler replacement package, as if to support the regular, interested can be studied (to share the results of the study, because I did not find the regular settings) using HTTPX or other proxy tools, the principle and fiddler similar, But the visualization effect (experience) is much better, after all, the others are specialized to do agent use. Write your own script agent, which is to open a proxy server locally, you need to consider the problem of port occupancy. In fact, I do not recommend the listening port, a relatively good solution is the local request all point to a script file, and then the script forward URL, such as:

Original request: Http://barretlee.com/api/test.json
at the time of Ajax request:
$.ajax ({
  URL: "http://<local>/api.php?") Path=/api/text.json "
});

PHP is easier to deal with:

if (!isset ($_get["page")) {
  echo 0;
  Exit ();
}
Echo file_get_contents ($_get["path"));

Ctrl+s, save the interface data on the line to the Local API folder-_-| | Third, summary

This article is only to the front and back end collaboration problems and several existing common patterns do a brief enumeration, JSON Schema specific how to use, as well as interface maintenance problems, interface information access problem is not specifically elaborated, this follow-up will have time to tidy up my understanding of him.

My summary, the article mainly shares the front and back end technical cooperation related technical problem solution method, mainly includes the former late development interface determination and so on, needs the prior knowledge for Ajax, mocks, JSON and so on.

ajax:asynchronous JavaScript and XML (asynchronous JavaScript and XML) refers to a web development technology that creates interactive Web applications.

Mocks: Typically, when testing an object A, we construct fake objects to simulate interactions with a, and the behavior of these mock objects is predetermined and expected. Use these mock objects to test whether a is working properly under normal logic, abnormal logic, or pressure.
The greatest advantage of introducing a mock is that the behavior of the mock is fixed, and it ensures that when you access a method of the mock, you always get an expected result that has no logic to return directly.
The use of Mock object usually offers some of the following benefits:

Failure to isolate other modules caused a test error in this module.
 Isolate the development status of other modules as long as the interface is defined well without having to do with their development.
Some slow operations can be replaced with mock object for quick return.
For testing distributed systems, there are two other important benefits of using mock object:

Mock object can transform some distributed tests into local tests
By using mocks for stress testing, you can resolve that test clusters are not able to simulate the pressure of an online cluster on a large scale.

JSON: (JavaScript Object notation) is a lightweight data interchange format. It is based on a subset of ECMAScript. JSON uses a completely language-independent text format, but it also uses a family of C-language (c, C + +, C #, Java, JavaScript, Perl, Python, and so on). These features make JSON an ideal data exchange language. Easy for people to read and write, but also easy to machine parsing and generation (network transmission rate).

JSONP: (JSON
With Padding) is a "usage pattern" of JSON that can be used to solve the problem of Cross-domain data access for mainstream browsers. Because of the homology policy, it is generally located
Server1.example.com Web pages cannot communicate with servers that are not server1.example.com, while HTML <script> elements are an exception.