background

Front-end development is too fast, front-end framework and technology development also emerge in an endless stream, including the emergence of different intelligent devices, for front-end development students is a big jump, a brief list:

  • Front-end frameworks: Vue, React, Angular

  • Applets: wechat applets, Alipay applets, Bytedance applets

  • Smart devices: Apple devices, Tmall Genie, Xiaodu

This leads to some problems. For example, if I want to develop a common page that is compatible with different sides and applets, it is obviously not possible at present. We have to develop multiple pages to fit different scenarios, which would be too expensive.

Many students are trying to solve this problem, which has spawned a multi-terminal unified development framework like Taro. This is a good solution, but it is passive and lacks certain expansibility.

What we want to discuss in this article is to see if we can solve this problem from another Angle and improve development efficiency.

ViewModel

When we develop a page, regardless of which framework we use, we usually abstract out a ViewModel layer that serves two main purposes

  • Interact with the server side, accept the data returned by the background, processing and transfer to the view layer rendering

  • Receives the view layer’s callback, processes the data and returns it to the View layer for rendering

As you can see from the figure above, the ViewModel is a separate piece of generic code logic that serves as a bridge between the past and the future. It is more closely related to the View layer, so it is usually tested at the front end.

Since the ViewModel is independent, can we put it in the back end? One of the biggest benefits of this is that the ViewModel can be reused, do not need to write repeatedly, and only need to change a viewModel, can be fully effective.

It seems like a nice idea, but who will develop this part of the code? We can’t rely on the backend students, of course, only ourselves, thanks to the emergence of the Serverless architecture, which makes this possible.

Some of you might say, well, now that the ViewModel has moved back, what about the View? Later, we will consider combining our UI2code technology, which is really perfect.

What is a serverless

Let’s first briefly introduce what is Serverless. Serverless is based on cloud technology, which is a revolutionary high-end architecture emerged when cloud technology has reached a certain stage. Serverless does not mean that there is no need for a server. It means that the developer does not need to care about the state of the underlying server, resources, capacity expansion, etc. The developer only needs to focus on the implementation of the business logic.

Architecturally, we can divide Serverless into FaaS and BaaS.

FaaS is a computing platform for creating, running, and managing functional services. It supports a variety of development languages, such as Java, NodeJS, DART, etc., which is conducive to the involvement of developers from different sides of the development. FaaS is event-driven, and only when a function is triggered by an event does it consume server resources. Otherwise, it does not consume server resources.

BaaS provides third-party basic services for function calls, such as identity verification, logs, databases, etc., which are directly provided by service providers and can be directly invoked by developers without relational implementation.

Business floor

We developed the back-end interface through the GAIA platform, which can be understood as the FaaS platform mentioned above.

There is a requirement in daily development, and here is a page for this requirement.

Because the data on this page is more, first cut it into a small module, when the background returns data also according to the module to return data.

We design the interface based on the ViewModel, first of all there must be a front-screen data interface; Secondly, the interaction on the page, such as switching cards and sesame credit button, will cause the change of page data. We can uniformly encapsulate a page update interface. Finally, there is an open interface.

The backend interface

In the design of the most important data structure for the front and back end interaction, we omit the intermediate business logic processing and look at the data structure of the interface.

The data returned by the first-screen interface has the following characteristics:

  • Return structure according to the page module definition of the front end

  • The granularity of the fields is very fine, with each element on the page corresponding to a field value

  • There are two fields to control the display and refresh of the module

The data structure returned by the update interface is similar to that of the first-screen interface, but the input parameters are different, mainly including two fields:

  • Data: indicates the data on the current page to avoid repeated data acquisition

  • Action: Defined page action

The front-end processing

As you can see from the data returned from the back end, the data is extremely detailed and we don’t need to do any business logic processing, just map directly to the page. As a result, the front end has become a thin layer of data, without the task of business logic processing, become very simple, when the need to migrate to other end, just need to migrate the view layer. When any service changes occur, you only need to modify the back-end interface to take effect.

Revenue and Summary

Through the concrete practice, we found that for the front-end development students, become simple, development efficiency has been greatly improved, front-end students do not even need to understand the specific business logic, can complete the development of the page. Moreover, the extracted ViewModel can be reused to different ends, including the native end. We can also split the ViewModel into smaller viewModels that can be reused across different page interfaces. Some of us also encapsulated a general state management framework based on Redux in FaaS and standardized the interaction between front and back ends.

Later, there are still some problems to be solved, such as development cost, logical separation of viewModel, specific interface problem location, etc.

The Idle Fish Team is the industry leader in the new technology of Flutter+Dart FaaS integration, right now! Client/server Java/architecture/front-end/quality engineer recruitment for the society, base Hangzhou Alibaba Xixi Park, together to create creative space community products, do the depth of the top open source projects, together to expand the technical boundary achievement!

* Send resumes to small idle fish →[email protected]


Open source projects, summit insights, key insights, in-depth interpretation

Please look for the idle fish technology