Laf product introduction
Self introduction
Hello everyone, I am Wang Zijun from the Laf team . I am very happy to share with you our Laf cloud development platform and its implementation principles here today . I originally wanted to start by saying something about the weather, but the host has finished speaking, so I won’t say more. Let’s just start today’s sharing.
product description
When preparing the PPT, I thought of many ways to introduce what kind of product we are, but then I found that these two sentences in our documents and official website can completely explain what kind of product we are:
The first is that we are like writing a blog, writing code can be online anytime and anywhere .
The second is to focus on the business itself, allowing developers to quickly release their creativity .
Original link: https://forum.laf.run/d/1030
Why is it like writing a blog? Because when writing a blog, you may open a blog platform, open a browser on your computer, then after you finish coding, click publish, and your blog can be seen by others.
When we develop, can we also say that as long as I have a computer that can open the browser, and then I can directly write code after entering it, after writing the code, I click to publish, one of my interfaces, one of my applications may That’s it.
The second is to focus on the business itself. Many of you here are developers. As developers, we often have the idea of making a gadget or an application.
But when we deploy the environment and prepare it, this environment refers to the environment in our computer, such as databases and other resources. It may also be the environment around us, such as going out without bringing our own computer.
But if our product exists, you may only need to get a computer that can open a browser to start your coding work.
Then in the next session, I plan to demonstrate our product to everyone.
Product Demo
Originally I prepared a video, but I think the video was made a little early, and many functions were not displayed on our official website, so I still communicated with the organizer and prepared a live demonstration, which I will use later. I will give you a demonstration on the computer. Please wait for me a moment.
Here is a product demonstration, you can visit laf.run or laf.dev to experience it.
Summary of product features
Okay, that’s the end of the demo session. Let me summarize it for you in three points, which are the characteristics of our project:
Out-of-the-box application resources include all resources needed to provide computing resources, database resources, log network storage and other applications. There is no need to prepare any environment, including computer environment and physical environment.
The goal is to shorten the development process as much as possible and lower the development threshold. If it takes a day to deploy an application to an environment, we may have made a demo in one day and sent it online to users or group friends for testing.
Open source and open attitude , all the source code of Laf is open source, and the components we use are also open source. They do not contain any manufacturer bindings and can run on any cloud without worries.
Introduction to technical implementation
Technology selection
Then we will introduce our overall technology selection. In terms of programming language, we chose Node. The biggest reason is to lower the development threshold, because in a project you will use the front end, and when using the front end you may use JS. You write JS on the front end and JS on the back end, so development is easy. It will not be fragmented and can cover more users.
Then we chose MinIO for storage. The most important thing about MinIO is that it is open source. In addition to being open source, it provides very good horizontal expansion capabilities. We can increase its storage capacity and processing power by adding nodes.
As for the database, we chose MongoDB. MongoDB has one of the biggest advantages. For us, it is a non-relational database. So if a relational database is used, the developer's threshold may be higher. He needs to design the table and design the table structure before making the application. If you use MongoDB, you may not need to design tables. Write business logic first, and then use MongoDB database when you feel you need to store data.
The gateway we chose is APISIX, which can seamlessly modify dynamic routing and has a wealth of plug-ins. The most important thing is its ability to be open source and open. Each of our cloud functions, applications, and buckets will be assigned a second-level domain name. Different mappings will be achieved through the modification of its dynamic routing. When we create cloud functions and create buckets, we can seamlessly give everyone a second-level domain name, so that when your application does not have a domain name, you can go online directly. for a visit.
Implementation flow chart
Then the following is a specific implementation flow chart. What we look at from the left is a developer's perspective. We can develop locally through an external IDE, or the CLI we provide, and then create an application and connect to Laf 's server. Then it will store our application information in the database. , then prepare the corresponding resources, create an application instance through Kubernetes, and then put a Node runtime in it, then allocate a database, allocate a storage, and the entire application is successfully created from creation to startup.
Then starting from the lower right, this is the process of our users calling one of our cloud functions or calling an interface. Our traffic first hits our gateway, and then the gateway finds a certain runtime based on the APPID. Then in the runtime, the name of our cloud function is unique, so we can determine which piece of function code to execute, and then directly respond and return to the external network.
Serverless implementation solutions comparison
Speaking of Serverless, it has a traditional solution, which means that a request will correspond to a process, which means that every time we request, it will create a runtime for you, create a pod, and then perform such a schedule.
Its advantages are relatively obvious. When it comes to seamless elastic scaling, because it will recreate one every time, there is no concept of elastic scaling. Because each of them is a new pod. The technical selection is also quite sexy, it is a very beautiful model.
But its shortcomings are also obvious. There will be cold start problems that many developers are concerned about, and long links cannot be perfectly supported, resulting in a fragmentation of development habits.
What does this separation of development habits mean? Because if we use a cloud database for traditional development, it will always run there. It will not restart every time we request it. Just like many AI projects now, it will Access the OpenAI interface of ChatGPT. If we use our long connection memory solution, we only need to save a session ID to support context calls. If there is no global cache, you need to save all chat records to the database and then enter them again each time, so that a contextual association can be made.
Then our technology selection is a long-term connection memory solution. It naturally does not have a cold start problem. Our container is always running there, just like a cloud server. Every time you make a request, it can respond in time. Of course, we naturally support long links. With the same memory, we can load more requests, because we do not have such a process of resource preparation, resource creation, and resource destruction. Our resources are always running there.
Regarding elastic scaling, we use Kubernetes' HPA to implement it. You enter your expected value, and it will add a different number of pods according to whether your load is too high. If your traffic is very low, it may help you reduce the number of different pods. Of course, this is a little more complicated to implement.
But we leave the complexity to ourselves and the simplicity to the users . This is our technology selection, which is driven by users rather than technology . Users need long links, so we support long links. Users don’t like cold starts, so we will get rid of cold starts. In this way, we can achieve that the more calls you make, the more traffic you have, and the lower your cost.
Cloud function scheduling process
Then here is a rough flow chart showing the scheduling plan. The left side is the traditional way. When a function request comes in, it will create a new runtime to process the function and process the request.
If we use our solution, all functions are sent to the Laf server, and then there is a task queue, and a runtime is used to process all these requests. If the load we set is reached, it may create a new pod to disperse the traffic processing.
Then I will briefly summarize the resource utilization of the two methods with pictures here. In the traditional way, when there is no request, the resource utilization is indeed zero, without any consumption. But if there are more and more requests, there will be a process of resource creation and destruction, which will cause the requests to increase linearly with the resource utilization.
Then Laf can still maintain very low resource usage when the load is relatively high. Again, we don't need to go through the process of creation and destruction. We are always running, no different from a server. We only need to prepare the context required for the code segment.
Cloud function development experience
Then there are some details about how we implement this solution, that is, what processes a cloud function goes through from dynamic release to execution to make our cloud function much faster than others.
After a user writes a cloud function, he clicks Publish. Because our TS supports type hints, we need to compile it into JS and then save it into the database. At the same time, we also publish the compiled function to the corresponding runtime of the application, and then We will also use the Node VM module to process it into a VM script object and cache it in a map in memory. In this case, every time we call the cloud function, we can directly fetch the script object of the VM from the memory and execute it directly.
We don't have a compilation process, so the response is a little faster every time. The process of calling through HTTP is to take out our compiled object from the memory, prepare the context, such as the incoming parameters, etc., pass it in as parameters, then directly execute the code, and then return the execution result via HTTP. . This is the process of our cloud function from writing to warehousing, publishing and executing calls.
So our team believes that the most important experience of writing code is like writing a blog. We need to have a complete web IDE, because if this IDE is very inconvenient to use and no one wants to use it, we will lose it. The experience of writing code is like writing a blog. We believe that a complete online editor needs to be supported by the following capabilities:
- Complete code type hints, if the code size is slightly larger, without type hints, it will be very painful to write. We will analyze the list of dependencies we need on the cloud function client, and then request the runtime to recursively traverse the dependent node_modules, find the type files it depends on, and then throw it back for front-end compilation The editor we use is VS Code, which is more friendly to TS support.
- It can be run and debugged online, because we can just grab a computer and write code.
- You can install npm dependencies that users need.
- There is a record of changes and you can roll back the specified version.
- The bottom is the AI automatic generation of cloud functions we just demonstrated. This function is based on another product of our company called FastGPT . It can input your own company's database into GPT for fine-tuning, and then it can master the information you provide. The knowledge of the knowledge base helps you answer questions based on your knowledge base.
I will also share the specific implementation principles of FastGPT later.
Cloud function is the most basic unit of code, so some logic needs to be reused, or when you write some libraries, you need to call each other. Here we hack node require. If we reference a cloud function and we determine that it is a cloud function, we will process it into a node module and return it directly, just like we introduce a node package. , it’s very natural.
Multi-tenant isolation
Regarding MinIO, how do we implement multi-tenant isolation strategy. In fact, for each of our MinIO storage buckets, we will force it to add its APPID before its bucket name.
Then we use the APPID as a MinIO user name. We will create a user for each application. Then we only need to set an access policy for s3 so that it can only access the bucket starting with its own user name. Then with some permissions, multi-tenant isolation can be achieved. Because MinIO is a cluster, everyone can only access their own bucket, which is the protection of files.
Then the database will also encounter the problem of multi-tenant isolation, but fortunately MongoDB has its own user management mechanism, so we only need to create a user for each application, and then use its own management mechanism to achieve permission isolation. alright.
But there is a more important issue here. If we use multi-tenancy, we will need to limit it, or design a request frequency for each tenant, because if there are such malicious requests, they will hit the entire machine. , may affect other users on the platform.
We will unpack all the traffic connected to MongoDB, and then see if its request frequency exceeds our limit. If it exceeds, we will discard it, and then if it is not discarded, we will enter it, and then From now on, we can make some statistics and realize the metering and billing of the database.
Gateways and routing
The APISIX we chose as the gateway has just been briefly introduced. It can seamlessly modify dynamic routing, and it has a wealth of plug-ins. The most important thing is its ability to be open source and open. Each of our cloud functions, applications, and buckets will be assigned a second-level domain name. Then it will be mapped differently through the modification of its dynamic routing, so that when we create a cloud function and create a bucket, we can seamlessly give everyone a second-level domain name.
AI writing code implementation
Then here is an implementation sharing of AI's coding ability just now. Looking from top to bottom is the data processing part. We will use the template market and our technical content, which is the document, and then vectorize the data and store it in the vector database.
Then when users ask questions, the questions may be divided into three categories, one is about writing business code, the other is about the use of our basic documents, and there are other questions.
If it's other questions, just reply to us directly. That means we won't answer irrelevant questions. If it is a code problem, it will search for similar content in the code database as knowledge of the large model, and then throw it to the large model. For example, let me tell you, the code of our product is implemented like this. The three functions about login are Like this, then you can re-write me a login function that the user needs and return it to the user. Specifically, it is a function achieved by splitting the problem and pre-training.
Product Outlook
Then it’s about scalability, because the capabilities we provide you, such as MongoDB, cloud storage, etc., are all fixed by us.
If there are some users, I need Redis, message queue, etc., some other cloud services, or even our own business system. Our Laf runs on Sealos, and Sealos is another product. In one sentence, it is a cloud operating system. On the cloud operating system, any other services can be run, including Redis and so on. If they all run on the same bottom layer, they can be called through the intranet, which means that our scalability is very strong. If you need support for other scenarios, we only need to run one.
After talking about the basic implementation, our product has some things that need to be done in the next step, which means our future planning. As we just said, the programming language we currently support is Node because we want to make Node better and cover more users. Next we can consider extensions to other languages, such as Python, Go or even Java, etc., because our implementation principles have just been explained, they are very simple, just plug in a runtime.
Then there is stronger AI capability. Now our AI can only write code and has limited value, so our next step may be to enable it to debug and go online by itself.
I roughly drew a simple diagram below. After AI coding, it will generate a test case by itself, test the results by itself, give feedback, and then go for acceptance. If the acceptance fails, it will throw it back to fix the bug by itself, and then Go to test, and then go to acceptance, just use this repeated logic to get through, write the code yourself and go online. We may still need to change the code now, but after our function is completed, we may not need to change it.
Then there is a richer function template market. We have now launched the function template. In the function market, there are many common business logics that we repeat, such as login, payment, etc., so we don’t need to write them all again. Because everyone writes the same thing using our products, we only need to click and load it into our own application.
Function templates and AI capabilities are actually related to each other. Because AI can write code, it can create more function template markets. With more function templates, more and more data can be used for AI training, and the answers it gives will become more and more accurate.
But although we have now solved the environmental problem and the problem of reinventing the wheel, it is not fast enough.
The fastest development is no development . The next step is for us to launch an application market. Many applications are overlapping, such as the class appointment system in our gym downstairs, etc. Some systems are duplicated. It can be developed by one person, and there is no need for everyone to develop it. . We will launch an application market. You only need to click on the application market to deploy this application. If this app fits your scenario, all you have to do is click on it. This is our ultimate goal, which is the fastest development without development.
Case introduction
Then I would like to share with you some of the more interesting cases we currently have on Laf . The first three above are some plug-ins contributed by our community students, such as VS Code plug-ins. Some people still don't like our IDE. They can use this plug-in to develop VS Code or other editors locally. Then there are two rapid development platforms for backend management.
The first one should be emphasized a little. This is a project written by two junior students in one night using our product. It is called Chat Mind . It is an AI-generated mind map tool. You can tell For example, he will help me generate a travel guide, etc. He will draw a mind map for you, or summarize a support point. This project has been acquired by XMind. It was probably acquired more than a month after it went online. It was written by two junior students in one night. If our product had not existed, he might have taken longer to write it, or even said that they had forgotten about it and given up.
Then here are some of our cases about education systems and e-commerce systems. The middle one is more interesting to mention. It is a cat profile written by a student of the Chinese University of Hong Kong. It collects stray cats on their campus and uses cat face recognition to scan out the cat’s information. What is it, what is its name. We are also doing this support activity now, that is, for all colleges and universities, if they deploy this Maopu project, we will provide them with it for free for one year, and they will not be charged for using our product. Then part of our Laf income will be used to rescue stray cats. This is a project that we think is quite interesting.
Ecological introduction
And because we are an open source project, the current ecosystem is to show you STAR 5.3K. Our 1.0 version has been online in less than three months. Our number of online users is already 14,000, and the total number of applications is close to 10,000. There are around 2,300 active applications, including our overseas version.
This ends my sharing with you. In fact, it is not that difficult to implement our products. It just means that we are not driven by technology. We are driven by user needs. Whatever users need, we will implement it in the fastest way. , the simplest way for users to achieve this, this is our product goal. thank you all.
