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

This article will explain in detail how to analyze the data flow of Web applications. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

I made a toy called Cumulo, which roughly means the back end calculates the data and sends it to the front end through Diff/Patch.

Then the Store of the front-end browser does not need business logic, thus reducing development.

However, this approach has natural defects, first, performance problems, and secondly, persistence problems.

In fact, it all boils down to performance, if you want performance, you must do increments, then the whole architecture will collapse.

This article attempts to describe a slightly more normal idea of designing an architecture based on data flow.

Due to the lack of back-end development experience, I do not intend to give a feasible solution.

Before we begin, review the architecture design of real-time Web applications.

First of all, the separation of Model-View in the front end is a * step, in order to liberate the development efficiency of View.

At this time, the data flow of Model is sent to View, and the update operation of View goes back to Model.

(the Model here is close to Store, not simple data, but contains update logic):

Then, put Server back, which is roughly the case of Cumulo.

At this time, the data flow is sent directly to the server, and the front-end Model synchronization server

Going back to View, Model becomes an intermediate process:

Then combine the above two pictures, simplify this part, and basically return to the case of *. The difference is that the Model is replaced by the server, and the data flow is popular from the server browser:

When we consider databases, especially databases, such as incremental processing, the problem arises.

First, the data is sent to Server instead of Database, because Server is logical.

Second, the entire data stream of Database cannot be sent to Server because it is too large.

The Diff/Patch scheme is used in Cumulo, which is not feasible for Database

So the reality is that Server goes back to the role of Controller:

* * for performance, the update logic also needs to be removed from Database and let Model come back

So Model has to deal with data requests on the one hand and push on the other, so it can only increase

The whole data flow also has a few more lines and becomes more complex, which is the general structure of the brief talk at the beginning:

However, this picture is not rigorous. For example, the specific relationship between Database and Server is difficult to draw clearly.

And the request, of course, accesses a web server and cannot be put directly into the database.

The point of this diagram is that compared to the original one stream, there are now two streams and the architecture has changed.

Data is obtained in two ways:

Data crawling, data fetched directly when accessing the page, and crawling history

Push, updates obtained from other clients during the user's use

The problem is that there is no point in thinking if it can't be simplified to reduce the writing of business code.

The calculation methods of the two data streams are not consistent and cannot be merged into one.

So I'm thinking about, from another perspective, how to construct a framework to deal with data flow.

So I sorted out the common actions needed in the chat room:

Switch chat rooms

Grab the first screen message

Grab the message

Receive message updates

Query historical messages

User login

User rights verification

I care about the first four operations, because there is a commonness between them.

For example, a message flow, there will be switching, fetching, history, update, these operations.

On the whole, other data that can be abstracted to the stream can also be reused.

Then the page switching, data consulting and data updating of the whole application can be put into a unified frame.

That is, when routing is switched, select which streams the client subscribes to, and then browse by stream.

Of course, there are still some problems, which need to be further considered.

The message list is a stream, so is the user configuration a stream?

Configuration is often a JSON object, and to become a stream, it is necessary to include modification operations at different times.

But this still involves new problems, and every message may be modified, so it is also a stream.

As a result, we have to deal with a much more complex concept of flow.

The other is the data association. There will be attachments in the message and there will be members in the chat room.

How to deal with the association of data? How does the design of API correspond to the interface, while the two are decoupled?

If there is still a cyclic relationship between the data, will the whole scheme fail?

This is a very troublesome thing, which may be avoided at first.

In addition, even if the above two problems are solved, the remaining options in the previous list still need to be dealt with

Permission system, search system, two are independent of the structure of the flow, can not be abstracted at the same time.

Further problems, databases and servers may be distributed, and there will be more complex data streams.

On how to analyze the data flow of Web applications to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.