What Future Programming Looks Like Based on FaaS and Flutter

Best practices from the Alibaba tech team for service frameworks

8 min readApr 24, 2020

This article is part of Alibaba’s Utilizing Flutter series.

The long-term plan of Xianyu(闲鱼), Alibaba’s second-hand trading platform, calls for it to use Flutter and FaaS to build a future technology development system. New technologies may appear confusing at first, so they need to be continuously pondered and explored. Moreover, only practice will allow us to gradually draw the contours of how such technologies can be applied. This article lays out our thinking on the future forms of programming based on the FaaS and Flutter combination and introduces our preliminary practices.

Integrate Flutter and FaaS with Xianyu

Xianyu has been exploring and practicing technology integration for a long time. We hope to use a single language and technology stack so that development engineers can perform business development in any scenario. In this way, we can integrate the development model and technology stack. This approach reflects our pursuit of development efficiency and empowers developers, allowing us to better utilize the capabilities of our staff and drive business growth.

Xianyu has leveraged the strong cross-stack capabilities of Flutter to unify the technology stacks on apps. This approach has already yielded preliminary results. On this basis, we want to further integrate the frontend and backend and use Flutter to create a unified technology stack. The rise of Function as a Service (FaaS) gives us a new perspective and opportunities. In backend development scenarios, FaaS separates the runtime environment, deployment, and O&M from routine development, allowing developers to focus more on creating business value and lowering backend development difficulty. Xianyu is already building a Flutter + FaaS integrated development system based on this approach.

As the technology develops, the current solution will be constantly abstracted, summarized, and refined. By gradually separating the changing parts from constant parts, developers can focus more closely on the parts that can be changed, improving their productivity. In this way, we can break up the system into different layers and gradually sink lower layers into the infrastructure. This follows the general pattern of the evolution of technology systems, as shown in Figure 1–1.

In terms of the Flutter + FaaS technical solution, we will build a new infrastructure layer for integrated development on top of the current mid-end infrastructure to focus business development on upper layers. In this process, we need to consider two basic questions:

What capabilities should the Flutter + FaaS technical system provide as an infrastructure that supports integrated development?
Based on the new integrated infrastructure, what form will business development take?

In fact, both questions represent two sides of the same coin. Once we can answer one question, the answer to the other will become clear. Here, we will explore the second question.

Business Development Based on the Flutter + FaaS Integrated Technical System

To attempt to answer this question, we need to first try to develop an abstract definition, implement it in practice, and then summarize and refine our approach based on iterative practices. Afterward, we can improve our abstract understanding of the issue and repeat the process until the issue gradually comes into focus.

First, let’s take a look at the current business development pattern, as shown in Figure 2–1. The main issues in the current pattern are data processing, network communication, state management, and UI rendering. Proceeding from these four points, we can consider the changes that will occur in the new integrated scenario:

Data Processing: This refers to traditional server-side REST APIs. In the integrated scenario, data processing is performed by FaaS functions. In fact, the responsibilities and positioning of this component have remained the same. Instead, only the format of organizational communication has changed. In traditional development, page development is completed by the server and client teams. In the future, integrated backend and frontend development can be done by a single developer. Conway’s Law points out that software designs tend to mirror the communication structure of an organization, so we may see major changes in this respect. However, we will first see changes in the method of interaction with the client, that is, the network communication method.
Network Communication: In the integrated scenario, frontend and backend development are done by one person, so the same languages can be used throughout a project. As a result, network communication will be lightweight, secure, and more intuitive. It will come to resemble common function calls. For this component, one possible change is that the communication model may break out of the client-server model. In a communication “session”, the client and server will be able to call each other more naturally in a “peer-to-peer conversation”. This will replace the traditional model where the client sends requests and the server responds to these requests. As network hardware improves, network connectivity is improving and communication costs are decreasing. This opens up a great deal of room for innovation.
State Management: Application states are a piece of special data cached on the client. Due to the isolation of technical systems, development communication costs, and network communication costs, it was previously necessary to cache state information on the client. However, in the integrated scenario, the influence of these factors is decreasing or eliminated. Therefore, we want to further remove states, minimize state management efforts, and move as much management work as possible to the underlying layer.
UI Rendering: This is an area that may be influenced by Flutter. The proposed reactive style and data-driven UIs are in line with our ideas. This is also the trend for UI development frameworks in the industry.

In the Flutter + FaaS integrated technical system, application development is simpler, with less difference between the frontend and backend, lighter-weight and more natural communication, and more precise responsibilities, as shown in Figure 2–2.

Integrated Framework Design Practices

In the integrated scenario, one business team member can complete both frontend and backend development, minimizing communication and collaboration costs. Although large businesses inevitably require collaboration, collaboration methods will change somewhat. Instead of the traditional horizontal division of frontend and backend, collaboration will involve a vertical division of labor based on frontend-backend integration, as shown in Figure 3–1. Changes in the way we cooperate will also influence our design ideas.

Now, let’s imagine how we could design a framework based on the preceding discussion. First, let’s name the business we want to develop a “Story”. Here, a Story represents a product business and is divided vertically in the aforementioned manner. These vertical divisions will be called Scenes. Conceptually, a Scene corresponds to a page in traditional development, but it does not have a one-to-one correspondence with a page in the product design process, as shown in Figure 3–2-(1). A Scene is a virtual concept that integrates frontend and backend development, rather than a physical entity during runtime. A Scene consists of three parts, as shown in Figure 3–2-(2). The Model part processes the business data (RawData). The Converter converts the business data into data used for rendering (State). Finally, the Render uses the rendering data to generate and render the interface. Model and Converter are deployed at the backend and run in FaaS functions. Comparatively, Render runs on the client, and the data flow between them is one-way. In logic processing, events are used in a centralized manner. These events are processed locally and then routed to the other end. If the other end does not process them, the events are discarded. This is shown in Figure 3–2-(3).

Today, Stories are already used in Xianyu businesses. In the next section, we will look at the results in practice.

Difficulties and Insights in Practice

It is not easy to build and perfect an integrated technical system, and challenges are certain in practice. The good news is that FaaS and the serverless concept behind it are already the trends in the industry and are extensively used in practice. Alibaba’s frontend personnel have concentrated their efforts on serverless practices. Although this is not exactly the same as integration, many ideas involved in integrated technical scenarios can be tested out in serverless practices, and this helps polish each other.

Development and Deployment Toolchain: The Xianyu integration project relies on the support of the underlying development and deployment toolchain, which is part of the infrastructure. Deployment is also a key factor of the serverless system and we can observe the relevant tools, plug-ins, and platforms in the practices of frontend developers. Xianyu provides both a direct platform and in-house plug-ins. Over the long term, it will gradually standardize its system.
End-to-End Tracking and Monitoring: This component is mandatory for engineering. Xianyu directly benefits from the Alibaba Group’s platform, but also plans to build its own tools for special scenarios, such as learning from the hot update capabilities of Flutter functions and integrated local debugging.

Apparently, Xianyu is also exploring other areas on its own:

Network Communication: Many of our ideas impose demanding requirements on network communication. Unquestionably, we expect the network quality to keep improving and costs to continue to drop. However, there will always be scenarios that involve poor network connectivity. Therefore, ensuring service stability and availability remains a challenge. Integration will weaken the development team’s perception of the network and provide new ways to use the network.
Component Splitting: In Xianyu businesses, we must always consider complex pages. In the previous design, we set aside the Converter part for this purpose. However, we are still exploring how to abstract the components used in frontend-backend integration and how to combine and reuse them.

(Original article by Xiong Huali)

Alibaba Tech

First hand and in-depth information about Alibaba’s latest technology → Facebook: “Alibaba Tech”. Twitter: “AlibabaTech”.