13 Case Study 3- Building a Scalable Web API in Ten Minutes #

Basic Concepts #

The common architecture of a Web API, as shown in the above figure, mainly consists of the client (browser), server, and database. The Web API is provided by the server, which is responsible for load balancing and login authentication.

When the client traffic rapidly increases, the server can only increase its service capacity by scaling horizontally, i.e., adding more machines.

However, this conventional approach has two limitations:

• Apart from developing business code, technical personnel have to incur a lot of server maintenance costs to ensure service stability and availability. Technical personnel have to spend a lot of time on operations, which reduces the efficiency of project development.
• When the traffic suddenly increases, horizontal scaling by adding machines is not elastic enough and may take tens of minutes to scale, making it impossible to achieve instant scalability. This results in insufficient service capacity for a period of time. Similarly, it is difficult to timely scale down when the traffic decreases, resulting in wastage of machine resources.

The architecture of Web APIs based on Function Compute (Serverless) is shown in the above figure. Compared with the traditional Web API architecture, the client and database remain unchanged, but the server undergoes significant changes, mainly in the following aspects:

• The routing module and authentication module previously maintained by the development team are integrated into the API Gateway system and authentication system provided by the service provider. The development team no longer needs to maintain these two parts of the business code and only needs to continuously maintain the relevant rules.
• In this structure, the business code is also divided into function granularity, where each function represents a different functionality.
• We can no longer see the existence of servers because Serverless aims to let users focus only on their own business logic. Therefore, certain security issues and resource scheduling problems (such as a sudden increase in users and how to achieve automatic scaling) are all the responsibility of the cloud service provider.
• Compared to traditional projects, traditional projects run continuously regardless of whether there are user visits, resulting in ongoing costs. In contrast, with Serverless, functions are only activated and executed when requests are made, and they are charged on a pay-as-you-go basis. This allows for support only when there is traffic and no expenditure when there is no traffic, which further reduces costs.

Development Workflow #

1. Log in to the Function Compute console and create an application #

There are two ways to create an application. If it is an existing web project, you can choose the first option in the above image: “Common Web Application”. For new projects, it is recommended to use the second option: “Create an application based on a template”. Here, we are using the template method and selecting a web application based on Python.

Templates serve as application scaffolding, and by selecting the appropriate template, you can automatically create the relevant dependent resources, such as roles, OSS, domain gateway, etc., which reduces development costs.

2. Create a function #

Under the application, create a function. Since we are developing a Web API, select the “HTTP” function. This type of function will use the specified HTTP request as a trigger to schedule the execution of the corresponding function.

Once the function is created, it will return a demo of “helloWorld”. We will develop our business logic based on this.

First, let’s introduce the handler function in the above code. This function serves as the entry point, and when the HTTP trigger receives a call, it will start the entire function through this entry. The function has two parameters, environ and start_response:

• environ

environ mainly contains two parts of content: the input of the HTTP request and the function execution context fcContext. The function context parameters contain some runtime information (such as request ID, temporary AK, etc.) that can be used in your code. The information type is FCContext.

• start_response

This parameter is mainly used to generate the response of the HTTP request.

3. Configure the trigger and bind a domain #

When creating a new function, an HTTP trigger is automatically created. This trigger has a test path of “aliyun.com” and can only be used for testing. In a real application, you need to bind a real domain to the function through a custom domain name. This way, when the specified domain name is accessed, the corresponding function will be triggered and executed.

4. Logs and Monitoring #

On each function editing page, there are log and monitoring services. Each function execution generates a unique requestId, and you can query all the logs of a function execution using this requestId.

Operation Demo #

Click the link to watch the demo video: https://developer.aliyun.com/lesson_2024_18999