This is from the training I did before. I have deleted some relevant information and referred to a lot of materials (
List of resources), thank you, 😘

With the continuous evolution of the Internet architecture, the front-end technical framework has undergone tremendous changes from the background output page to the background MVC, and then to the front-end MVC, MVP, MVVM, as well as the implementation of Virtual DOM and MNV*. Overall, the front end is also rapidly evolving toward modular, componentized, and high-performance Web development patterns. In addition to the traditional desktop browser applications on the Web, the front-end technology stack has never stopped trying and developing on the server or mobile end, and has formed a series of mature solutions. The technology stack on the front end solves more than just the problems on the page, and the front end engineers pursue more than just the technology on the page.

Cross backend technology

In recent years, full stack engineer has become a very popular keyword. From the earliest MEAN technology stack to the straight back end, and then to the present isomorphism of front and back ends, the front-end development mode combined with Node is more and more recognized by developers and has been practiced in more and more projects. Front-end developers are keen to develop on Node for several reasons:

• Node is an event-driven, non-blocking server that is ideal for handling concurrent requests, so application services built on Node perform better than those implemented by other technologies.
• The Node side runs JavaScript, which is relatively cheap for front-end developers to learn, and the issues to focus on are relatively pure.
• As a front-end engineer, you really need to master a background language to assist your technical learning.
• The Node end processing data rendering way can solve the problem that the front-end can not solve, which is reflected in the advantages of large Web application scenarios, which is also an important reason why the Node back-end straight out or isomorphic implementation is widely used by developers.

Node backend development

Node.js is a JavaScript runtime based on the Chrome V8 engine.

There was a geek named Ryan Dahl who wrote high-performance Web services in C/C. For high performance, asynchronous IO, event-driven is a basic principle, but writing in C/C is too painful. So he started thinking about developing Web services in a high-level language. He evaluated a number of high-level languages and found that many offered both synchronous and asynchronous IO, but once developers started using synchronous IO, they didn’t bother writing asynchronous IO anymore, so eventually Ryan turned to JavaScript. In 2009, Ryan officially launched an open source Web server project named Node.js based on the JavaScript language and V8 engine.

Node was the first to bring JavaScript to back-end server development, and there were already millions of JavaScript developers around the world, so Node exploded. Node’s biggest advantage is that it makes writing high-performance Web services a breeze thanks to the event-driven nature of JavaScript and the V8 high-performance engine.

Blocking and non-blocking

Blocking means that other JavaScript commands in Node.js cannot be executed until a non-javascript operation has completed. This is because the event mechanism cannot continue to run JavaScript when blocking occurs.

In Node.js, JavaScript performs poorly due to CPU intensive operations. Rather than waiting for non-javascript operations (such as I/O). This is called blocking.

Blocking methods execute synchronously, but non-blocking methods execute asynchronously. Using the file system module to read a file, the synchronization method looks like this:

const fs = require('fs');
const data = fs.readFileSync('/file.md'); // This will blockCopy the code

An asynchronous equivalent:

const fs = require('fs');
fs.readFile('/file.md', (err, data) => {
  if (err) throw err;
});Copy the code

In the second example, fs.readfile () is non-blocking, so JavaScript continues to execute without blocking, which is excellent design for efficient throughput.

JavaScript execution in Node.js is single-threaded, so parallelism is related to the ability to poll for events (that is, the ability to process JavaScript callback functions after completing other tasks). Any code that attempts to run in parallel must have the event polling mechanism run with non-javascript operations, such as I/O.

For example, each request to the server takes 50 milliseconds to complete, of which 45 milliseconds are database operations that can be done asynchronously. Selecting a non-blocking operation frees up that 45 milliseconds for processing other requested operations. This is a major difference in choosing blocking versus non-blocking methods.

The event polling mechanism in Node.js differs from that of other languages, where threads are typically created to handle parallel tasks.

MEAN

In the early stage of Node’s emergence, it does not have as complex concepts as it does now, and the relevant technology and language standards are not mature. The most common solution for Node development is to use Express as a Web framework for small Web site construction. The mainstream technologies combined with M(Mysql), E(Express), A(Angular), N(Node) are the most typical, and even today the combination of MEAN technologies is still in use.

The front-end uses Angular to manage and implement the page application, the server-side Web framework is mainly Express, and the free and open source MongoDB database is used, so you can build a Web application quickly.

It may not be necessary to use it today, because there are already many mature alternatives to implement it. Various other front-end and back-end frameworks can be flexibly combined as an alternative to MEAN. For example, Vue and React can replace Angular, Koa can replace Express, and there are many database options.

Node back-end data rendering

For front-end developers, in large-scale Web application development, it is not necessary to completely redesign the architecture of the whole application background, but more often, it is necessary to combine the ability of Node to help us solve the problems that cannot be solved under the development mode of front and back end separation. Let’s take a look at some of the problems associated with the usual front-end separation and how using Node services can help us solve them:

SEO issues in SPA scenarios

In general, the basic flow of page loading in SPA applications or in development mode with separated front and back ends is as follows:

1. The browser side loads an empty page and a JavaScript script.
2. The interface is then asked asynchronously to get the data.
3. Render the page data content and present it to the user.

So the problem comes, when the search engine crawls the page to parse the keywords, descriptions or other content in the HTML of the page, JavaScript has not been called and executed, the search engine gets only an empty page, so it can’t get the specific content in the <body> on the page, which affects the ranking of the content of the page included by the search engine. Although we add keyword and description in the <meta> of the empty page, this is not enough because the key body description of the page is not captured by the search engine.

If you use Node back-end data rendering (some people call it direct out or server side rendering SSR) to render the content to the page for output when the page is requested, then the HTML obtained by the search engine already contains the complete content of the page, and the page is easier to be retrieved.

Slow rendering of front-end pages

In addition to SEO issues, in development mode where the front and back end are separated the page is blank (or the user is prompted to load) before JavaScript renders. The network waiting time that users have spent before seeing the data includes:

DOM download time + DOM parsing time + JavaScript file request time + JavaScript partial execution time + interface request time + DOM rendering time.

At this point, the user sees the page data after three serial network resource requests. If the data is rendered directly from the back end, first of all, the problem of SEO no longer exists. After the content parsing of DOM is loaded by the user browser, it can be displayed immediately, and the problem of network loading is also solved. Other logical operations, such as event binding and scrolling loaded content, can be loaded on demand and asynchronously, drastically reducing the time spent displaying page content.

The general architecture design of background page data direct output is as follows:

The direct outputting layer accepts the front-end routing request, and asynchronously requests the service access layer interface at the Controller layer of the Node end to obtain Model data and assemble and splicing, and then extracts the corresponding View template of the Node end to render HTML and output it to the user’s browser. Instead of using front-end JavaScript to request dynamic data after rendering.

Moreover, according to different browsers, userAgent can also extract different templates to render pages and return them to different user browsers. Therefore, this implementation method is not only very suitable for the realization of large-scale application services, but also can easily realize the responsive content of the website.

The front and back ends are isomorphic

Adding a straight out layer to the development pattern of front and back end separation solves SEO and slow data loading display problems. But there are two new problems:

• Front-end development implementation to straight out of the shift, have to in the original development model to make changes to To adapt to the development of the out layer content, such as the back-end template change to adapt to the development of the existing models, the results we have to maintain two different sets of Taiwan before and after template or rendering – front end technology, realize the logic and the back-end straight out the implementation logic, Even though it’s probably all written in JavaScript.
• If it is a Hybrid application on the mobile end, the offline package mechanism implementation may be problematic. It is difficult to cache HTML files offline because the HTML structure is always directly from the back end to the front end, and only other static files can be cached. In the application scenario of Hybrid App, we actually prefer to solve the problems of slow loading and SEO by using the content directly from the back end when the mobile terminal opens the page for the first time. In the case of offline cache, static file pulling data from the local cache of the client can be used to return to rendering. Or, in the future, use front-end rendering if older browsers support HTTP2, and direct rendering if lower-end browsers don’t.

Therefore, a set of perfect development mode is needed, which is consistent with the original development mode and can be used in the development mode of front and back end separation and the development mode of back-end data rendering template. This development pattern is what we call the front and back end isomorphism.

The core of isomorphism

The purpose of the front and back end isomorphism is to develop only one set of project code, which can be used to implement JavaScript loading rendering on the front end, and can also be used for direct rendering on the back end.

Why can we do that? In the same way that front-end renders data content, page-out content is generated by adding data to template compilation. The difference between front-end rendering and back-out mode generates DOM structure only when the data and template are rendered. If you use a templating system that compiles data on both the front and back ends, you can use the same development code for data rendering and parsing on both the front and back ends. Therefore, the core problem of front and back isomorphism is to achieve the unity of front and back data rendering.

The advantages of isomorphism

In addition to solving the problem of front and back development style, a front and back isomorphic site has some obvious advantages:

• According to the needs of users can easily choose to use front-end rendering data or background direct page data;
• Developers only need to maintain a set of front-end code, and can use the original front-end project component-based management, package construction, according to different construction instructions to generate similar front-end and back-end data templates or components to perform parsing at the front-end and back-end, so this should be consistent with the development mode on the DOM structure layer.

Realization principle of front and back end isomorphism

Isomorphism scheme of front and back ends based on data template

Back in the era of front-end MVC development, front-end templates were widely used, such as Mustache, Handlebar, etc. The basic principle is to combine template description syntax with data to generate HTML code strings and insert them into specific elements of the page to complete data rendering. Similarly, the back-end straight out layer can also use this method to achieve data rendering to generate HTML strings output to the page.

If the front and back ends use the same template parsing engine, we only need to write the same template to describe the syntax structure and we can render the front and back ends separately. For example, the same template:

<div class="entry">
  <h1>{{title}}</h1>
  <div class="body">
    {{body}}
  </div>
</div>Copy the code

When the data is retrieved, the data is parsed consistently:

{
  "title": "Hello"."body": "World"
}Copy the code

<div class="entry">
  <h1>Hello</h1>
  <div class="body">
    World
  </div>
</div>Copy the code

For the same template syntax structure developed in the front end, we can choose to generate HTML string output by rendering in the browser side, or we can choose to generate HTML string output by rendering in the back end. If you choose to render in the front end, the template can be packaged and compiled to render DOM after the data request is successful. If you choose back-end rendering, you can send the template data directly to the View View of the outbound layer for rendering, implementing the same template syntax structure to render the same content on the front and back ends. The premise here is to ensure that the template rendering engine or template parsing syntax used by the front and back ends is consistent.

Mvvm-based isomorphism of the front and back ends

The JavaScript logic on MVVM framework pages is mainly implemented by Directive (not only Directive, but also filter, expression, etc., mainly Directive). Generally, after the front-end page is loaded, it will scan the Directive in the DOM structure and perform DOM rendering or event binding. Therefore, the display of data still needs to be completed after the page executes Directive. If the Directive is implemented in the direct output layer, the page output directly by the browser is the rendered content.

<div class="entry">
  <h1 x-html="title"></h1>
  <div class="body" x-html="body"></div>
</div>Copy the code

The same section of MVVM grammar structure written in the front end can eventually generate the same HTML structure through the parsing of the front end MVVM framework or the parsing of the back end Directive. The difference is that the ViewModel object generated after the parsing of the front end is reflected in the browser. Back-end rendering generates text strings of HTML tags for output to the browser. The same thing that needs to be done here is to implement the same module in the background that parses Directive in the front, even including filters, syntactic expressions, and so on. In this way, the same syntax structure can be parsed on both ends.

Virtualdom-based isomorphism of the front and back ends

As mentioned before, VirtualDOM, as a new programming concept, is widely used in actual project development. Its core is to use JavaScript objects to describe the DOM structure. Since the Virtual DOM is a JavaScript object, it means that it can exist on both the front and back ends, and realize isomorphism through different processing methods.

Declare a section of VirtualDOM description syntax in the front-end development component, and then generate VirtualDOM through the VirtualDOM framework parsing, here VirtualDOM can be used to generate front-end DOM structure in the browser, can also be directly converted into HTML markup text string output layer, In this latter case, the Virtual DOM to HTML text string conversion can be implemented on the server side. In this way, the front and back end rendering mechanism can be unified through different operations of the Virtual DOM, so that the front and back end of the component can render the same section of description grammar.

The logical implementation of VirtualDOM still needs to be completed by event binding on the browser side. It is best to let the isomorphic framework help us automatically complete the binding process according to the structure of THE HTML. Ensure that the final page displayed to the user is complete and with interactive logic.

In either case, the core is in the changes in HTML structure. There are many ways to describe the content of a page, and they can be transformed through specific processing processes, thus providing more possibilities.

Egg.js

Node, despite its popularity, has not yet been recognized as a mature enterprise framework, mainly because few enterprises use Node to develop large backend applications. Now there are two main Sails: Sails and egg.js.

Design principles

A plug-in does only one thing: Instead of having a lot of extra functionality built into it, Egg implements it as a plug-in, aggregating these plug-ins through a framework and customizing the configuration for its own business scenario, so that the development cost of the application becomes low.

Convention over configuration: Following a common set of conventions for application development within a team can reduce developer learning costs, which is the idea behind many frameworks.

The characteristics of

• Provide the ability to customize an upper-layer framework based on Egg: You can use Egg to encapsulate an upper-layer framework that is appropriate for your team.
• Highly extensible plug-in mechanism: can facilitate the reuse of business logic, ecosystem formation.
• Built-in multi-process management.
• Koa-based development, excellent performance: support all Koa middleware.
• The framework is stable and the test coverage is high.
• Progressive development: smooth implementation of code -> code abstraction -> function abstraction into plug-in -> plug-in encapsulation into the framework of the progressive process.

eggjs.org/zh-cn

Currently the Node project in our department is basically a Koa, Egg stream. Other departments also have Express streams.

Cross terminal technology

The mobile terminal

With the rise of mobile Internet, intelligent mobile devices appear and Native applications in a large number of application markets begin to emerge. As the first wave of mobile terminal Internet development gradually calmed down, various Native applications began to enter the stage of orderly update and iteration. People’s demand for mobile Internet is growing rapidly, and there are more and more demands for rapid iterative development of Native applications. However, the development and iteration speed of existing Native applications still cannot meet the rapidly changing needs of the market. Then comes the emergence of HTML5, which allows developers to rapidly develop web-based applications on mobile devices, and makes mobile Internet application development quickly enter the era of coexistence of Native applications, Web applications and Hybrid applications.

In the process of development, the maximum use of native capacity has become a major trend. Frameworks like React Native and Weex allow you to write Native applications directly in Javascript. React Native, for example, doesn’t produce “web apps,” or “HTML5 apps,” or “hybrid apps.” The end product is a true mobile application that is almost indistinguishable from an application written in Objective-C or Java.

import React, { Component } from 'react';
import { Text, View } from 'react-native';

class WhyReactNativeIsSoGreat extends Component {
  render() {
    return(<View> <Text> If you like React on the Web, you'll also like React Native. </Text> <Text> Basically uses Native components like React'View'and'Text'To replace web components'div'and'span'. </Text> </View> ); }}Copy the code

This means that you can write native applications in Javascript even if you don’t know anything about native application development.

The desktop

It is now possible to build cross-platform desktop applications using JavaScript, HTML, and CSS. With applications like Electron, you can package Web projects directly into desktop applications that run on various operating systems.

The famous Atom IDE is built on Electron, as are other apps like VS Code, Skype, and Github Desktop.