Kiwicode startup story(10): Create the backend of your app.
This article is one of the articles in a series ‘Kiwicode startup stories’, and you can read the last article ‘Kiwicode startup story(9): Customers need to build complex apps, not simple ones.’.
In December 2019, Adrian and I have completed a lot of work in the last year, from business model analysis to product design, technical implementation, and so on. Kiwicode has completed its original “shape” over time. Users can create applications and generate codes, but a real application requires the development of a database and service behind it so that users can use your application normally. As a result, creating a product that enables customers to quickly create their own database and service has become an essential part of Kiwicode’s overall user experience.
The database is a collection of data that customers must store and process for an extended period of time. Customers have complete control over their data. They can choose which information should be stored in the database. The service, as far as I can tell, is responsible for creating, reading, updating, and deleting the database. These operations are completed through the use of APIs. The customer requires a product that can create a custom API and set up the data structure in the Database. Kiwicode Service Builder is how we refer to it.
Soon after, I finished the Service Builder prototype design. The principle remains the same: create an easy-to-use product while ensuring the execution of complex functions. Both Adrian and I are satisfied with the design of dealing with the database. Customers can easily click to implement a completely customized data table.
We’ll develop a NoSQL database for our customers and wait for them to create APIs to make changes to it. However, when it came to designing and developing custom API functions, I ran into some issues. Since the Restful API is very standard, in addition to submitting a large amount of necessary information about path, parameters, body, headers, validation, etc., users also need to write a custom handler to implement the functions of this API. The entire procedure takes a long time. Yes, and it’s been over-engineered. Except for the handler, all the information can be processed with a simple click. The handler necessitates a significant amount of code to support it, which is both inefficient and not customer-friendly for customers.
Adrian and I are still very busy at work, but we are constantly thinking about how to solve this problem. Adrian had a brilliant suggestion: “The Query section of the API handler is where the bulk of the work is done. We can only let the user specify the Query effect he wants, such as reading data from a data table, and then we can finish it ourselves. Error handling and other components are included. This editing mode is known as One-liner because he is only allowed to write and define the most important line.”
This is a fantastic concept. Team members will occasionally come up with a brilliant idea that you hadn’t considered. People always use the same incorrect method to solve a problem due to their own cognitive limitations. All you have to do now is pay attention to everyone. You must sincerely thank each other and accept suggestions if other members of the team bring up a good idea.
This is a fact: when creating handlers, a lot of engineers write a lot of repetitive code. Adrian admitted that he dreaded having to write these tedious documents, but that he had no choice. The development efficiency can be greatly improved by using the One-liner mode. Customers can reduce the time it takes to build a complete API by more than 90%. Because our automatic machine can replace a lot of repetitive work at once, this is also the machine that helps the customer generate the code, but you can’t see it.
The database, services, and API created in Service Builder can be used directly. We will automatically deploy the user’s services for the customer if they wish. Users can use our services and make API calls from anywhere at any time. What we need to do now is provide users with a reasonable pricing model, and once they accept it, customers can deploy their created services on our cloud.
The next article ‘Kiwicode startup story(11): Pay by usage = Grow with customers.’ is published. Simply send me some claps and feedback if you enjoyed my story.
If you want to join our product — Kiwicode (a code generation SaaS)’s waitlist, click here.
