Summary: What value can be demonstrated when two different technologies, Serverless and low code, intersect in the same business? This article takes “Blind box lucky draw”, a creative marketing activity done by Serverless Devs, as an example, and tells us how Serverless and low code are combined to meet a business demand.

The author | cold inclined & Jiang Yu

What value can be demonstrated when two different technologies, Serverless and low code, intersect in the same business? This article takes “Blind box lucky draw”, a creative marketing activity done by Serverless Devs, as an example, and tells us how Serverless and low code are combined to meet a business demand.

preface

Online H5 creative animation combined with offline physical rewards is a common means of Internet marketing campaigns. In order to grasp the critical time nodes, the cycle of activities from planning to landing is generally relatively short. Landing online service in a short time is not a small challenge for students who do technical development.

This is especially true when there are more requirements, such as adding back-end administration and critical front-end access to data hotspots. For development, in addition to completing core business demands, it is often necessary to pay attention to other conditions other than non-business demands, such as system access security, coping with high concurrent traffic, observable system operation indicators, etc.

In the past, such requirements often required the participation of multiple roles, such as product, front-end, back-end, design, testing, operation, operation and maintenance, which resulted in a relatively low input-output ratio and poor continuity of activities. Today with Serverless + low-code technology we can dramatically reduce the cost of doing such an activity and make it a continuous activity, thus greatly improving the performance of the operation.

In fact, Serverless Devs only invested 3.5 people in the blind box lottery, and then completed the activity planning, product design, front-end and back-end implementation, system deployment, operation and maintenance, etc. And with the service capability of Serverless, it can easily cope with the non-business challenges such as system access security, high concurrent traffic and system observability. The replenishment of functionality and improvement of efficiency made this operation achieve very good income, and the template precipitation of activity service laid a good foundation for the follow-up similar activities.

The overall process of the “Blind Box Lucky Draw” is as follows:

  1. Requirements design (including business logic and interaction logic)
  2. The design draft
  3. Low code implementation front-end
  4. Code to implement the Serverless service
  5. Alignment test
  6. The deployment of online
  7. Activity problem fix
  8. Resume after activity

Application preview:

The “1 Minute Serverless Deployment Blind Box” raffle is now over, but interested students can still try it:

Developer.aliyun.com/adc/series/…

Architecture Preview:

This deployment architecture does not use Ali Cloud API gateway, but directly uses the function to calculate the Custom Runtime as a hosting form, because of the particularity of this demand, we are ** “deploy their own” **, actually means that the end-to-end access is decentralized, the end-to-end access service is relatively thin, Only data processing interface calls and provides static rendering services, after a centralized logic background processing winning probability, management prize query database and so on.

If you are doing your own centralized activity background, it is recommended to refer to the following architectural pattern, using API gateway as the traffic entrance. Easy to do more security restrictions and more flexible extension

For the

Front-end interaction low code implementation

This front-end implementation uses low code to work hype4, hype4 specific use is not introduced in detail here, interested students can search.

In addition to the design draft will need to cut out the figure, and then with Flash to achieve the animation effect, the last is to add JS code interface access, scene switching ability. The whole process will be much faster than full coding, especially the dynamic effect of implementation than pure handwriting efficiency 2-3 times.

Data layer Serverless service

As shown in the architecture, the data layer here is actually what we understand as SSF, which only does data forwarding and static rendering. The code implementation is relatively simple, using the Express framework, and then in the form of function calculation Custom Runtime deployment.

The goal is that the service can host both static content and dynamic data forwarding. It is worth noting that the user’s information retrieval is also implemented in this layer.

Here we get the accountId of ali Cloud user, which is convenient to align the winning information to distribute prizes. This parameter doesn’t make much sense to the average developer.

We will deploy the lottery background in advance. Next, each user will visit the deployed service after deploying this layer of services, and then transfer uid and other basic information to the lottery background to initiate the lottery. Finally, the winning results are returned and passed to the front end for display. As an administrator, prizes and probabilities can be set through background operations.

Backstage lottery logic implementation

The back-end services are implemented using Python Web framework: Django. The main methods are as follows:

1. Obtain user UID information and verify the UID information to ensure that:

  • Accuracy of THE UID information
  • The client service is deployed using the Serverless Devs developer tools;

2. Construction of prize pool for the day;

3. Preliminary determination of users’ winning information;

4. Review the winning information of users;

5. Return the final result to the client.

The basic flow

1. Users locally deploy blind box lottery client services to their own accounts through Serverless Devs developer tools;

During the deployment, a temporary domain name needs to be delivered to a user (the temporary domain name requires the user’s UID). During the temporary domain name delivery, Serverless Devs generates some client tokens and records them in the Serverless Devs back-end service. This token is actually an important mark to identify the user’s identity;

(If users declare in Yaml that they do not use the domain name information automatically issued by the system, they may not be able to participate in this activity smoothly).

2. After the deployment is complete, a temporary domain name issued by Serverless Devs is returned for users to learn and test.

3. Next, the user opens the temporary domain name through the browser and can see the page related to the lottery. The user can click to carry out the lottery operation.

4. After the user clicks the lottery operation, it will initiate a request to the Serverless service under the user account. The service will process the request according to the user’s UID information and initiate a real lottery request to the back-end Serverless service of this activity.

5. When the back-end Serverless service of this activity receives the user’s lottery request, it will:

  1. Get the UID information transmitted when the Serverless service under the user account initiates the lottery request;
  2. The obtained UID information is used to match the data in the temporary domain name delivery system to determine that the user uses the temporary domain name delivery system and delivers the corresponding domain name.
  3. Realize lottery operation;

Lottery core implementation

In the process of lottery operation, it is also a preliminary evaluation of the current system, and set up a simple and easy to implement, which can be used for small-scale lottery activities:

For this part, the Django project is implemented as follows:

@csrf_exempt

def prize(request):

uid = request.POST.get(“uid”, None)

if not uid:

return JsonResponse({“Error”: “Uid is required.”})

Temp_url = “< validity and validity of uid >? uid=” + str(uid)

if json.loads(urllib.request.urlopen(temp_url).read().decode(“utf-8”))[“Response”] == ‘0’:

return JsonResponse({“Error”: “Uid is required.”})

token = randomStr(10)

# Get the day prize

prizes = {}

for eve_prize in PrizeModel.objects.filter(date=time.strftime(“%Y-%m-%d”, time.localtime())):

prizes[eve_prize.name] = {

“count”: eve_prize.count,

“rate”: eve_prize.rate

}

# Build a raffle pool

prize_list = []

for evePrize, eveInfo in prizes.items():

temp_prize_list = [evePrize, ] * int((100 * eveInfo[‘rate’]))

prize_list = prize_list + temp_prize_list

none_list = [None, ] * (100 – len(prize_list))

prize_list = prize_list + none_list

pre_prize = random.choice(prize_list)

# Data storage

try:

UserModel.objects.create(uid=uid,

token=token,

pre_prize=pre_prize,

result=False)

except:

try:

if not UserModel.objects.get(uid=uid).result:

return JsonResponse({“Result”: “0”})

except:

pass

return JsonResponse({“Error”: “Everyone can only participate once.”})

if not pre_prize:

return JsonResponse({“Result”: “0”})

user_id = UserModel.objects.get(uid=uid, token=token).id

users_count = UserModel.objects.filter(pre_prize=pre_prize, id__lt=user_id, date=time.strftime(“%Y-%m-%d”, time.localtime())).count()

# Final judgment on award or not

if users_count >= prizes.get(pre_prize, {}).get(“count”, 0):

return JsonResponse({“Result”: “0”})

UserModel.objects.filter(uid=uid, token=token).update(result=True)

return JsonResponse({“Result”: {

“token”: token,

“prize”: pre_prize

}})

System safety setting

When a user wins the lottery, the system will generate a token, and the combination of the token and uid is an important basis for judging whether the user wins the lottery. This may involve a question: why do you need to add a token to judge the combination with uid? In fact, the reason is very simple, submit the winning information and query the winning information, if is directly handled by the uid, then the user is likely to have passed the traversal, illegal access to other users to submit the information, and this part of the information are likely to involve the user submit the shipping address, etc., so for the sake of safety, added a token, To some extent, it increases the complexity of being traversed by violence. The method for this part is simple:

@csrf_exempt

def information(request):

uid = request.GET.get(“uid”, None)

token = request.GET.get(“token”, None)

if None in [uid, token]:

return JsonResponse({“Error”: “Uid and token are required.”})

userInfor = UserModel.objects.filter(uid=uid, token=token)

if userInfor.count() == 0:

return JsonResponse({“Error”: “No information found yet.”})

if not userInfor[0].result:

return JsonResponse({“Error”: “No winning information has been found yet.”})

if request.method == “GET”:

return JsonResponse({

“Result”: {

“prize”: userInfor[0].pre_prize,

“name”: userInfor[0].name,

“phone”: userInfor[0].phone,

“address”: userInfor[0].address

}

})

elif request.method == “POST”:

name = request.POST.get(“name”, None)

phone = request.POST.get(“phone”, None)

address = request.POST.get(“address”, None)

if None in [name, phone, address]:

return JsonResponse({“Error”: “Name, phone and address are required.”})

userInfor.update(name=name,

phone=phone,

address=address)

return JsonResponse({“Result”: “Saved successfully.”})

The whole process is:

  1. Obtain user information by user UID and token.
  2. If the request method is a GET method, then the user’s winning information (i.e., receiving information) is returned directly.
  3. If the request method is POST, the user is allowed to modify the winning information (i.e., the receiving information);

Other safety supplements:

  1. The uniqueness of the information such as how to ensure the user’s token and not fake, this part is not very easy to implement in the browser, because the user may change the browser, but for the user in the functions of computing platform service is relatively easy to implement, so the domain name issued by stages, to the specified time period issued by the recording of information to the domain name, A later comparison is made to ensure that the user actually deployed the project through the Serverless Devs developer tools, issued a temporary domain name, and participated in the event within the specified time; (Of course, if users register multiple Aliyun accounts to participate in this activity, this time is allowed)
  2. How to ensure that the prize will not be super hair, this part in the system, adopted a more “stupid” approach, but also for small platform are easier to implement the method, namely the tag to give users a first prize, and then according to user’s prizes in the database sequence position, determine the final winning information, for example, a user winning a mechanical keyboard, In the database, it is the sixth position of the mechanical keyboard, but there are only five mechanical keyboards in total, so the user’s winning information will be checked twice and marked as not winning. (Of course, this is fine for small events, but not for large events, because it is unreasonable to read and write multiple database operations to some extent.)
  3. After winning the prize, the user submitted the mailing information of the prize, how to ensure the security of the information, not to be violent traversal by others is also worth paying attention to the problem, here a random token is added to increase the complexity of violent traversal, further guarantee security;

Deployment Preparations

For this deployment, no domain name is required. You can use the custom domain name generated by function calculation. Serverless Devs tool still needs to be installed.

steps

Part of the lottery backend template is still in preparation, demonstrating only the deployment of front-end and data layer services.

Step 1: Configure the key

For details, see Serverless Devs Ali cloud key configuration

Step 2: Initialization

Use the Serverless Devs command line tool to execute:

s init blindbox-game

Enter the guided operation:

Step 3: Build deployment

To modify the configuration information, run s deploy

See the effect

Function deployment:

Page effect:

The application template of the lottery prize is being prepared and will be displayed in this application template in the future.

conclusion

After the above practice, I would like to expand the topic of low code and Serverless with you again. The following part will mainly be theoretical, hoping to bring different harvest to readers.

Developer perspective Serverless + low code

As far as I am concerned, the clear conclusion is that I do not reject the compatibility of the two, but rather look forward to the combination of the two to further make my work more efficient and safe.

My biggest feeling in this activity is that it would be nice if the low-code platform could seamlessly connect with Serverless. For example, I can only test the interface when I call the low-code platform after the construction is sent online. This advantage of the platform with natural integration will be obvious. In addition, after the release of a good front end, we have to go to the back-end interface assembly, this if it is a unified platform to complete the requirements can be released, will save a lot of things. However, this is a bit of a paradox, because I also worry that once the low-code front end is coupled to the Serverless back end, it will become inflexible and locked by the service providers.

Vendor perspective Serverless + low code

You can see the convergence of Serverless from cloud providers and low-code providers. For example, low-code platform leader OutSystem has been using AWS services, such as Lambda, to build native APP services for their customers since 2016.

Trillo, a low code platform with Serverless & Model-driven Application as its main service, helps its users build Serverless services and front-end applications based on Google Cloud Service architecture. Of course, various cloud manufacturers at home and abroad have not been idle Azure will own low code products Power Apps into the Serverless ability to form Serverless Power Apps, the advantages of the two do full integration.

Aws has left front-end integration to its partners, focusing more on Serverless integration on the service side, and has launched a Step Functions Workflow Studio product that connects Serverless with almost all of its products.

Domestic Tencent launched a micro low code platform, which is also the flagship Serverless + low code, in the small program scene, the follow up of various manufacturers also shows the importance of this field.

Vision to build Serverless + low code platform

The value of the Serverless + low code platform is fairly clear, efficiency, security and cost are its key words. So what are the considerations that we need to take into account if we want to build such a platform?

The first is from the platform capabilities, should be able to cover an application development from front to back. Such as:

  • Data modeling
  • Data model API
  • Use Serverless to build back-end application logic
  • Support for deploying long-runing back-end services
  • Extensible integration of external services
  • File storage
  • The logical layout
  • Various security capabilities such as authentication, permission control, etc
  • The UI layout
  • CI/CD
  • Applied observability

Here’s a quick look at the functional design of the platform, building on the capabilities of the cloud vendor’s infrastructure.

There are some open source products that can be shared here:

  • UI page construction github.com/alibaba/des…
  • Database modeling gitee.com/robergroup/…
  • Process Choreography github.com/i5ting/imov…

In addition, the Iac capability of Serverless Devs can be used to connect with cloud infrastructure. Especially, the current integration maturity with FC is relatively high, which can facilitate the management of the whole life cycle of functions.

Of course, the above is only some of the author’s assumptions, I know that the realization of such a system is not easy, here is just to throw jade.

The pursuit of the improvement of production efficiency has always been an important topic of enterprise production. Serverless and low code have independent division of labor in their respective technical fields, but also share the same characteristics of improving production efficiency. It may be an important competitiveness for students engaged in information industry to master and make good use of these two productivity tools at the same time.

The original link

This article is the original content of Aliyun and shall not be reproduced without permission.