Enterprise software front-end architecture based on ANGULARJS [reprint]

This is my speech in Qcon Beijing 2014:

Outline:

Enterprise application in the software industry occupies a large proportion, and most of this kind of software is now using B/S model development, in this ever-changing era, their front-end development technology to find out what improvement point?

b/S enterprise software Front-end development mode is generally similar to desktop software, are partial heavyweight, there may be more business logic in the front, how these business logic is reasonably modular, and interface separation, so as to test, become an important challenge in this field. On the other hand, because the enterprise application interface is relatively structured, the emphasis is on data access, not too much fancy things, so the common interface control is also enumerable, how to make the development of the interface can be done faster, even by the business designers are not good at writing code to do, and interface prototype work into one, Can improve a lot of development efficiency.

After the advent of the mv* framework such as ANGULARJS, there are some opportunities for this field, and architects will have the opportunity to re-engineer the front-end architecture, or even the development process, to make the entire software production more efficient.

This article will explore the changes it brings to this field.

Text: Features of enterprise application front-end

Enterprise Application System is a very common software system, the characteristics of such systems are oriented to an industry, the function is more complex, the requirements of the interface is generally neat, not the pursuit of fancy. Such systems usually have C/s and b/s two schools, of which the B/s method because of the deployment and integration of convenience, the use of more common.

The same is done in the browser, writing business applications and Web site differences are also obvious. Enterprise Application business logic is heavier, the front end has a certain thick, but the effect is not the pursuit of many, mainly the use of various types of controls, form access values and so on.

Some features of enterprise application products are as follows:

• Exclusive mode.

General users use the Internet products, are fragments of time use, such as shopping or reading, after the completion of the refresh or close the browser, and enterprise applications are often the work of all, from the morning to start work, to turn off the day, most of the work is done on top, such as a call center operator.

• Heavy business, light vision

Enterprise application to the vision of the pursuit is relatively low, generally do not require fancy effect, to the smoothness of business operations as the first goal.

• Neat interface, single mode

Enterprise application of the interface layout of the relative pattern can be used in a few scenes to the poor, the interface horizontal vertical, relatively regular, the use of the control elements are also poor lifting, basically no special effects.

• Keyboard operation

Because enterprise application users are relatively professional, before the induction needs to undergo a unified training, and the frequency of use of each user is high, many times they will use as fast as possible to do the operation, such as the keyboard, which in the Internet products are relatively rare. Therefore, sometimes everyone in order to pursue good-looking, the system of the original select with a div to replace, in this case instead of increasing the user's trouble.

• Complex logic

In my previous industry, the business logic was complex, and the front-end might need to write a lot of complex logic, and the JS code was mostly in processing logic, not interface interaction.

• Load speed with a different focus

Internet products often attach great importance to the first screen optimization, but the strategy may be different from the enterprise application. For example, 3 200k modules may be optimized as a 100k plus three 150k module in a web-based product, but in enterprise applications it is likely to be optimized as a 400k plus three 50k module. Why is that? Because content-oriented web site optimization strategy is apportioned, if the first load is too slow, will affect the user's confidence, but the enterprise application user tolerance is higher, he does not care about the time just opened slowly, because after opening a day, for each step after the module loading speed is very high. In addition, the processing of memory leaks is also required to be relatively high. The whole strategy is actually derived from the influence of C/s system.

• Relatively loose browser version

Often mentioned enterprise application, everyone's idea is low-end, IE6, but in fact, the reason is that customers only buy software, operations generally do their own, there will not be a lot of continuous investment to improve, so many old systems can not continue to upgrade. Software vendors can actually use a more aggressive strategy to upgrade the browser, the user acceptance of this is still relatively high, the use of the system is much smaller than the Internet users, the abandonment of old browser things can really dry, such as I saw a few years ago a telecommunications business system preinstalled Firefox.

Common front-end framework for enterprise applications

In the development of B/s enterprise application front-end crowd, a large part of the group chose the service side of the component approach, such as JSF, its disadvantage is the heterogeneous service side of the third-party system integration is more troublesome. There are also a lot of people use bindows and ExtJS such framework, the recent Kendoui is also a good choice.

Each type is chosen by a representative saying:

• HTC extends tags on the browser side

In the early days, some teams used a combination of XMLHTTP, ease of use, and clean interface code, but were discarded by mainstream browsers.

• JSF and so on server-side build interface

The most respected approach of the future-oriented architect, which is deeply influenced by the Struts MVC model, weakens the front end and makes the front end degenerate into a subordinate of the backend.

• GWT Compile Phase Build interface

Writing other languages to generate HTML and JS typically relies on a front-end UI library. This approach is also more popular with backend architects because they feel that writing JS is a headache, rather than writing Java.

• ExtJS with JS Package interface components, simply do not html

This is another extreme, starting with bindows, using purely logical code to describe the interface, walking along the same path as Java swing, and a lot of people like it. But this approach is very painful in the absence of an easy-to-use interface designer.

• Flex, etc. out of the HTML system

This road is actually a continuation of the Java applet, the benefits of the HTML system can not be restricted, independent development, so in fact, these systems in the enterprise application field of maturity far beyond the HTML system.

Once the Enterprise B/S application a few treasure

There was a time when we were almost only IE6, so the front-end developers at that time were happy, without the pressure of compatibility. At that time, how do we build front-end applications?

See Http://weibo.com/1858846672/B1fL3vuYN?mod=weibotime

• Htc

This is the best way to declare a control.

• XMLHTTP

Although there is no concept of Ajax, we can already use it as a transfer mechanism for the front-end separation.

• VML

Do you have any other options for drawing vector images in IE without using plugins?

• Xslt

Transform XML data into HTML, like the front-end template?

• Popup

The best way to create a right-click menu.

A typical enterprise application built with these technologies

Single-page applications and front-end tiering

At that time, these systems can be built in a single page application, we use the IFRAME to integrate the menu, each menu has its own independent function, the entire main interface is always not refreshed.

Time flies, these years, the front-end has what the nature of change, has made a radical change?

Sometimes we look back, but found that most are in addition to improve some of the details, there are really subversive, such as Requirejs and Seajs as the representative of the module definition and loading library, NPM such package manager, Grunt,gulp, Baidu FIS such integrated development model. Why are they essentially improvements?

Because these mark the front-end development from the extensive model, gradually change to the precise control of the form. For example, we can no longer ignore the code dependencies, and can not open the interface indiscriminately all possible to use the code immediately loaded, that era has passed, from any point of view, the modern front-end development is in fine, from the control of the code, to the interface experience of fine optimization, To the entire team and even to the company even the Internet component sharing, as well as front-end team Collaboration Process Improvement, this is a very large-scale industry.

We put our eyes to the 2013, in this year the most fire front-end technology is Nodejs and Angularjs, the former brings us a change in the way of development, the latter is a typical front-end layered solution. Angular is a genre of the front-end mv* framework, and people who have used it will feel very cool. Where does it cool? Because it helps us do a lot of things, a two-way binding, all-encompassing, all access value-related operations, basically do not have to write their own code. In the enterprise application front-end Function, the form's access value and check occupy a large proportion, these things do not have to dry, that is very good.

If you're using angular for this, it's a little early. There are some third-party codes called libraries, others called frameworks, and angular are frameworks rather than libraries. The meaning of the framework is that it is more restrictive and not provided as an accessibility feature.

Take a look at the usual patterns of enterprise applications, there will be a configurable menu, and then mostly in the form of MDI, you can open multiple business functions, with the form of tabs to display, you can switch operations at any time. Each person's daily function is can be poor, he entered the system, usually need to work to turn off. So this system is ideal for single-page applications, loading an overall framework at the beginning, and loading the function modules for each menu, on a new tab or somewhere else.

In the early days of such a system, the general use of IFRAME to integrate the menu, this is very convenient, but each menu page to load a common framework file, initialize an environment, the data can not be accurately shared.

So now we do enterprise Information system, no longer suitable for using IFRAME to integrate the menu, the business code of all the menus, will coexist in the scope of the same page. This is convenient in some ways, such as data sharing, a drop-down box that selects a national city, exists in multiple functions, means that the data of these cities can only be loaded once. But from another perspective, it is also a challenge, as the likelihood of interference between data is greatly increased.

Let's review how we do it in traditional client-side development, as early in the classic "Design Patterns" book, we mentioned the MVC pattern, which is a typical layered pattern. For a long time, the MVC in the web Developer's mind refers to the graph of the struts framework, but the MVC in our single-page application is actually closer to the original concept of the design pattern book. So we're going to layer on the front end, not just pushing the entire front end to the view layer.

Do single-page application, the front-end is not layered is difficult to do, when the scale of expansion, it is difficult to deal with some of the hidden dangers. The more important benefit of layering is the ability to think about things from a holistic point of view, such as sharing data. Cross-module data sharing is a more complex topic, bad will lead to inconsistent situations, if the consideration of the hierarchical situation, the various data sources are unified maintenance, it is much better.

Therefore, the most important work of the front-end mv* framework, which is represented by Angularjs, is to do the guidance and binding work of these layers, and on this basis, we can further optimize the single page application of this kind of products.

Custom Label system for front end

Building a large enterprise application, the most important thing is to build a complete set of components system. Generally for a certain industry software, long-term will have a lot of fixed patterns, can be refined into components and rules, from the front end, reflected as the control library and front-end logic. Control Library This is a cliché, in many frameworks there is this concept, but the corresponding mechanisms are different.

From the point of view of writing an interface, the most convenient way is the label-based declarative code, such as our common HTML, as well as the Xaml,flex in Microsoft's Mxml, are very straightforward, imagine that there is no visual IDE in the case of Java-like The way swing and Microsoft WinForm write the interface, there's no doubt that the way XML is written is easier to accept. So, we can draw a preliminary conclusion that the interface part should be labeled.

Unfortunately, HTML comes with a label that is insufficient, has a basic form input control, but lacks a more expressive control like datagrid,tree. So most of the interface libraries use some kind of javascript to write these kinds of controls, such as:

<div id="tabs">  <ul>    <li><a href="#tabs-1">Nunc tincidunt</a></li>    <li><a href="#tabs-2">Proin dolor</a></li>    <li><a href="#tabs-3">Aenean lacinia</a></li>  </ul>  <div id="tabs-1">  </div>  <div id="tabs-2">  </div>  <div id="tabs-3">  </div></div>

$(function() {    $( "#tabs" ).tabs();});

If so, these complex controls are created and rendered through JavaScript, which is contrary to the principle we have just mentioned. So what are we looking for, a way to expand the existing HTML system? In the early days, there was HTC in IE that could be used to declare components by introducing namespaces, and now the standard browser introduced the Web component to see more detail in the framework of polymer. After all, what does this kind of approach do?

• Isolate the implementation of the component, making it easy to use
• Supports self-scaling of new components
• For some scopes of isolation, such as Web Components, the style tag can be scoped, indicating that it only takes effect within the component

From another point of view, why do we have to do this? Where does the greatest benefit come from? For large projects, management costs and change costs need to be carefully considered. If a component needs to declare a node in the DOM, and then use a JS to get the DOM, render the DOM, and then populate the data, the management cost of this process is very large, because the two parts of HTML and JS are missing a problem, no matter when, Maintaining a file is always better than maintaining multiple files, we look at HTC that way, why it is very low cost of use, because it can be the control of its own dom, logic, style all written in their own, the entire file is referenced by the person can be. At this stage there is no such use of technology, can only retreat and seek the second.

So, at this point, the benefits of angular are the extensible labeling system, which is the semantics of tags. One of the main features of angular is instruction, which makes it easy to extend tags or attributes. For example, a business developer can write directly:

<panel>     <tree data="{{data}}"></tree></panel>

This is so intuitive, and can be written with the original HTML code, without causing any burden. Semantic tagging is the only way of writing interfaces quickly.

Business logic

With semantic tags, if we write only the interface does not write logic, that is enough, but the reality is often not so good, we have to consider the business logic to do.

Enterprise applications are generally oriented to a certain industry, in this industry, there will be a number of established business models and processes, how these things reused, has been a problem. In the past, these things will be placed on the server side, in a language like Java to implement business elements, business rules and business process management.

One drawback of this approach is the neglect of the interface layer, as he only displays the interface layer as a display, and is overwhelmed by the large number of JavaScript logic that may arise. Many architects in this field do not agree with the thickness of the interface layer, they think that this layer should only be very thin, pure display related, but in this era, there is no real lightweight interface.

As mentioned earlier, we layered on the front end, the presentation layer and the business logic layer completely isolated, the benefit is that the logic layer does not exist on the DOM operation, only pure logic and remote call, so that this layer of things can be easily tested. Continuous integration is necessary for a large product, and automated testing is an integral part of continuous integration. Without layering, this test might be difficult to do, and now we can make it easy to do it first, and the pure logic code can be tested in a faster way.

Before we do the front-end unit testing, we need to load the code into the browser to execute, or self-encapsulate some "headless browser", that is, do not open the actual display, simulation of the test process. This process is relatively slow, because it also has the process of loading this network transmission, if we can do this on the server side of this thing?

We see the recent nodejs, which has given the front-end engineers a chance to take more control of the development process in many ways, and in our scenario, it would be more efficient to put unit tests on the front-end logic in node.

Two-time development platform

Let's take a look at what to do with this layered mechanism and the interface tag library.

Enterprise software companies, there are many will do two times the development platform, the goal of this platform is to integrate some of the existing industry components, so that business developers and even do not know the technology of business personnel through a simple drag, configuration form, the combination of generating new business functions.

From the interface point of view, drag-and-drop generation is easy, many interface prototyping tools can be done, but how to integrate data and business? Because you want to generate this function, is actually to take to use, not have a look to be able, so should be able to combine with the real data. But this thing is not easy!

For example, the interface has a selection of the industry's dropdown box, the data is configured, the query operation on the back end, as a query service or business object management, some traditional way may be in the back end of this association, the angular framework can push this thing to the front. This process can be particularly hassle-angular because of the two-way binding, as compared to the backbone framework. One interface fragment wants to be associated with the data, the thing to do is to set the various properties, so dynamic loading and dynamic binding will be relatively easy.

Like what:

Partial.html

<ul>     <li ng-repeat="item in items">{{item.name}}</li></ul>

Main.html

...<div ng-include="‘partial.html‘" ng-controller="CtrlA"></div>...

A.js

function CtrlA($scope) {    $scope.items = [{name:"Tom"}, {name:"Jerry"}];}

B.js

function CtrlB($scope) {    $scope.items = [{name:"Donald"}, {name:"Micky"}];}

In the above example, what this list shows is entirely dependent on the phrase "Ctrla" of ng-controller=, and it is easy to replace the data source with another ctrlb, even if it is done on the same version, even if it is configured, The introduction of another JS file containing Ctrla Other versions, and basically no need to change the other code, this has reached a goal of two development: as far as possible to configure and not code to add, maintain new features.

Mobile development

Now the enterprise software can not only consider the browser of the PC, many customers will have mobile office needs. Responsive design is a common solution, but in the enterprise applications, want to complex business functions to design a responsive interface is too expensive, and the interface design itself is to develop enterprise software of these companies of the short board, so our relatively simple way is the PC and mobile terminal design interface alone, So there is a problem, the business logic of the two interfaces is not different, if we want to maintain two sets of code, the cost is very large, there is no way to share something?

If we don't take the form of layering, that's a hassle, we've noticed that the differences between the two systems are only in the UI layer, and if we use layered patterns, we can share things outside the UI layer. Specific to the angular inside, such as service,factory, and even controllers can be shared, only directive and HTML templates with the device differences can be.

We rarely saw a angular-based mobile development framework, but now there are, for example, Ionic, using a framework that can directly reference the existing business logic code and make some adjustments to the display. There are many benefits to this, as well as a certain requirement for the code's architectural level, and the need to fully cut the business logic with the interface display.

The benefits are also obvious, independent business logic, because it does not depend on the interface, so it is easy to control, do unit testing, integration testing, piling and so on, in short, it is purely logical things, in the back end can be used to ensure the quality of the code, in the front-end business logic can also be used, Business logic can therefore be clearly and stably.

For enterprise applications, this is a great way to reuse the business logic of the past and differentiate it only in the part of the code that is responsible for the final presentation.

Engineered

The above technical problems are solved, the rest is the marginal effect of scale, which requires us to consider many problems from an engineering point of view:

• A JS module is modified, how to know who will affect?
• What interface will be affected by an interface fragment being adjusted?
• How do I minimize publishing?
• How to test, package, compress with one click?
• 。。。。。。

These topics, which are limited in length, are not described in this article, but can be viewed in addition to my other articles on Web application components.

Original address: Enterprise software front-end architecture based on ANGULARJS