Skip to main content

Introduction to Front-end and Back-end Data Processing

Introduction​

This article will explain the advanced content of visual development (WeDa) in the cloud development platform, aimed at helping you more comprehensively master its core capabilities. If you are not yet familiar with visual development (WeDa), it is recommended to first read the Quick Start to solidify the foundation.

In this chapter, we will focus on explaining the use of data, including the following examples:

  • How to integrate data with the frontend

    • Display data via data table or data list and other data container components
    • Binding the data model to general components for display

  • How to integrate data with the backend

    • Process data in the data model through custom code
    • Retrieve external interface data through cloud functions

Data Source​

Data in cloud development can originate from data model or external data sources.

  • If there is no existing data (data already stored in other databases), it is recommended to use the data model in cloud development to manage data

  • If there is existing local data, such as local files like excel, it is also recommended to use the data model to manage data by importing the local files into the data model

  • If you have your own database, you can connect via Data Connector

  • For data integration from third-party applications, you can connect via API integration

    • APIs/Custom Code (Guide)
    • Cloud Function (Guide)
    • APIs/HTTP API

Data Model​

First, let's understand the several ways to define data models.

Define data models in CloudBase/Database, relevant link Create Data Model

preview

External Data Source​

  • If the external data source is provided through direct database connection, you can use the Data Connector to connect the external database to the data model, thereby using the data model to proxy database operations

preview

  • If the external data source is provided in the form of HTTP API, you can access the data through methods such as APIs|Cloud Function
    Among them, APIs include two methods to access external data: HTTP Request and Custom Code

preview

Through the above methods, you should be able to integrate data into Cloud Development. Next, we will explain how to connect the data to the frontend.

Frontend Data Integration​

After configuring the data source, the next step is to display the data on the frontend.

According to the architecture diagram, we can see there are several ways for the frontend to retrieve data:

  • Data Configuration

    • By configuring data source parameters, directly bind data to data container components for display

  • $w Invocation (Related Documentation)

    • If data is stored in global variables, system variables, etc., it can be accessed via $w
    • If the data is obtained via cloud functions, it can be invoked through $w.cloud.xxx

We prioritize displaying data through data container components. Only when the data model cannot be directly bound to data container components do we consider storing the data in global variables and accessing it via $w

preview

Data Configuration​

Configuring Data Sources for Data Containers​

If the scenario involves data management, you will likely need a list to display data and a form to store data.

We recommend using data tables or data lists and other data container components to quickly display data. By selecting a data model, you can bind the data source to the component.

As shown, we can quickly configure data sources in data container components

preview

Configuring Data Sources for Common Components​

If the component you wish to display is not a data container component but a regular component, you cannot use the quick data source binding method. Instead, you can follow the steps below.

  1. Globally create a built-in data table query

preview

  1. In the component, retrieve data via $w and bind it to properties

preview

For details of this demo, please refer to Hands-on Practice

tip

Expressions cannot be directly entered into properties; they must be switched to expression mode for input. Otherwise, they will be displayed in string format and data cannot be retrieved.

External Data Source​

If we want to display external data on the page, the data must first be obtained through methods such as cloud functions, HTTP API, or data connectors

For data connector scenarios, we can rule them out since they provide data through data models.

If data is fetched from the backend via methods such as HTTP or Cloud Function, we can call it on the frontend via the $w method

The following is an example of invoking a cloud function via $w

  1. Create a cloud function query on the page

preview

  1. The following sample code is provided by default
async ({
    params
}) => {
    // Parameters passed when the query is triggered
    console.log("params", params);

    const result = await $w.cloud.callFunction({
        name: "test", // TCB cloud function name
        data: params, // Parameters received by the cloud function, depending on the input parameters of the cloud function you created
    });

    // Cloud function execution result
    return result;
}

In the above example, the cloud function test is invoked via the $w.cloud.callFunction method with the parameter params passed in, and data is the return value of the $w.cloud.callFunction method

Subsequently, at the location where data needs to be retrieved, use the following expression to obtain the data.

$w.query1.data

Data Processing​

Now you can retrieve data to the frontend through various methods. Next, you may need to bind the data to a component or perform some processing on the data.

The issue then evolves into how to process the data into the format required by your (component).

At this point, you can process everything directly in the JS method or handle it step by step via the event flow approach.

Below we provide an example:

Suppose that now we want to retrieve the backend blog category list data and bind it to the tab component, the problem encountered is:

The data retrieved from the backend is in database field format, and we need to process it into the format required by the tab component.

1. JS Resolution:

  1. Retrieve data via the $w.cloud.callDataSource method.

  2. Convert the data into the format {label: 'Category Name', value: 'Category id'} using the map method.

  3. Return the newly formatted data

export default function({
    event,
    data
}) {
    const data = await $w.cloud.callDataSource({
        dataSourceName: "blog", // data source name
        methodName: "wedaGetRecordsV2", // data source method
        params: {
            // Return field selection
            select: {
                $master: true, // returns the main table fields
            },
            getCount: true, // returns the total field
        },
    });

    const tabList = data.records.map((item) => ({
        label: item.name,
        value: item._id
    }))

    return tabList;
}
tip

If you are unfamiliar with JS methods, you can always ask AI for assistance.

2. Event Flow Resolution:

  1. Create a custom variable `blogCategoryList

  2. Create an event flow. In the first step, configure Invoke Data Source Method to retrieve data.

  3. In the second step, configure the js method to convert the data queried in the previous step into the format {label: 'Category Name', value: 'Category id'}, and assign the converted data to the custom variable `blogCategoryList

  4. Invoke the event flow at the appropriate time, for example when the page initializes

preview

The differences between the above two methods are as follows:

JS method

Advantages: The return value is data, so it can be directly bound to components. Binding automatically executes the method, making it convenient and efficient.

Disadvantages: Data is not cached; each execution requires a new query, cannot be reused, and requires full coding.

Event Flow

Advantages: The flow is implemented through configuration, with data cached to variables for reuse.

Disadvantages: Configuration steps are relatively more numerous, requiring manual invocation and execution.

Backend Data Integration​

Backend data integration aims to execute data acquisition and processing operations in the background, eliminating cross-origin and concurrency issues while significantly enhancing efficiency and performance compared to frontend data handling.

Therefore, when multiple interfaces need to be requested simultaneously to obtain data and process it, using backend data integration is recommended.

Since the script is executed on the backend, there is no $w global variable, resulting in slight syntax differences in the invocation chain, as detailed below:

Custom Code​

In APIs, data models can be invoked via custom code.

The context input parameter contains contextual information and invocation methods for the Cloud Development Environment.

For detailed information, refer to Custom Code

The following example demonstrates how to invoke data models via custom code.

// params is the input parameter, and context contains contextual information, etc.
module.exports = async function(params, context) {
    const data = await context.callModel({
        dataSourceName: "blog", // data source name
        methodName: "wedaGetRecordsV2", // data source method
        params: {
            // Return field selection
            select: {
                $master: true, // returns the main table fields
            },
            getCount: true, // returns the total field
        },
    })

    // use data doing sth...
}

Modify Non-Owned Data

If you wish to modify non-owned data, you can add the following parameters in callModel

fetchOption: {
    useAdmin: true
}

Sample code:

module.exports = async function(params, context) {
    const data = await context.callModel({
        dataSourceName: "blog", // data source name
        methodName: "wedaUpdateV2", // data source method
        fetchOption: {
            useAdmin: true
        },
        params: {
            data: {
                name: "test"
            },
            filter: {
                where: {
                    $and: [{
                        _id: {
                            $eq: "xxx"
                        }
                    }]
                }
            },
        }
    })

    // use data doing sth...
}

Cloud Function​

Cloud Function is a function that runs in the background and can be encapsulated into HTTP to provide interface calls to external systems.

In Cloud Function, you can call data models via SDK. For detailed instructions, refer to SDK Initialization

The following example illustrates how to call data models via Cloud Function.

const cloudbase = require("@cloudbase/node-sdk");

// Specify the Cloud Base environment ID.
const app = cloudbase.init({
    env: "some-env-id",
});

exports.main = async (event, context) => {
    const models = app.models;

    const res = await models.blog.list({
        // Return field selection
        select: {
            $master: true, // returns the main table fields
        },
        getCount: true, // returns the total field
    })

    // use res doing sth...
};

The following example demonstrates how to invoke external APIs via custom code.

Here we choose to use fetch to call external APIs.

const fetch = require("node-fetch");

exports.main = async (event, context) => {
    const res = await fetch("https://api.example.com/data");
    const data = res.json();

    // use data doing sth...
}

Differences Comparison​

Custom code and Cloud Function differ in the following ways:

Custom Code

Custom code can be considered as single-file JavaScript code deployed and running in the cloud.

Advantages: Handling data model-related logic is convenient, with no publishing and deployment required.

Disadvantages: Does not support introducing third-party SDKs and can only write in JavaScript.

Cloud Function

Cloud Function can be considered as a complete backend service deployed and running in the cloud.

Advantages: Backend service, supports multiple languages, and allows introducing third-party SDKs.

Disadvantages: Requires publishing and deployment.

Therefore, when handling lightweight logic related to data models, it is recommended to use Custom Code for implementation; for other complex scenarios, Cloud Function is recommended.

Debugging and Error Troubleshooting​

Points to Note:

  1. After creating a new data model, the default permission is "Only the creator and administrators have read/write access". If data is not visible, it may be a permission issue; please check whether the data model permissions are correctly set.

  2. When encountering pop-up error messages similar to the following, the cause of the error is usually indicated. If the error cause is unclear, you can perform step-by-step troubleshooting based on the error chain of the triggering event.

As shown in the figure, the error was prompted when clicking the button1 component, indicating a failure in the event response of component button1. Therefore, we need to troubleshoot the click event chain of component button1 to check for any syntax errors.

  1. If encountering the following error, you can see the error cause is a syntax error in the property binding of component sideTab2.selectedValue; therefore, check the property binding of that component.

preview