AWS Startups Blog

Creating Customized Business Applications with Clappia’s No Code Platform

September 8, 2021: Amazon Elasticsearch Service has been renamed to Amazon OpenSearch Service. See details.

Guest post by Ashutosh Kumar, Co-Founder and CEO, Sarthak Jain, Co-Founder and CTO, Clappia

Clappia is a no code platform where creating customized business applications is as easy as working with Excel sheets. Apps built on Clappia range from elementary to very complex, involving master data, automation workflows, and integrations with external systems.

The Business Problem

Businesses need applications to manage their processes. But procuring these applications can be expensive and time consuming. Some businesses hire developers to build the applications and set up an IT team to manage the life cycle of the applications. Others outsource the application development to freelancers and agencies. There are a few problems with these approaches:

●  Both approaches consume time and money and are potentially unreliable.
●  Business users need to decide where to host the applications, how to publish the apps on app stores, etc.
●  Once applications are developed, any change in the functionality takes time to develop and release.
●  Scale is not generally not considered during the initial phases, which leads to increased costs in the long term.

To overcome these problems, we created a platform where business users can create apps by themselves without the knowledge of any coding and without worrying about deployment, hosting, storage, change management, and scaling.

Our Approach

Business users come to Clappia and design apps per their understanding of the processes. They are presented with simple drag and drop blocks to design their apps, which consist of basic data input blocks to capture text, gps location, images, and barcodes as well as advanced blocks to consume data from other Clappia apps or external APIs. They can also configure multiple workflows like sending emails and sms, hierarchical approvals, sending data to external APIs. These apps are distributed to end users who submit data via the app. Upon submission, all the workflows are triggered and the admins get to see the submissions by all the users.

flow chart of no code flow on white background

Our Challenges

  • The definitions of our apps can be very dynamic and very different from one another. App admins can change the definitions at any time, and the changes need to propagate to all the end-users immediately.
  • Users can distribute each app to thousands of users, and the number of submissions made per day by one user can range from 1 to 50,000, which means that the system should be capable of handling varying amounts of load in terms of requests per second.
  • There can be a lot of asynchronous processing required once a user submits an app, and the processing logic can be very dynamic. For simple use cases, it might involve sending emails or SMS. It might include fetching data from or pushing data to other Clappia apps and making external API calls for complex use cases.
  • Users of the app need real-time analysis of their data interactively.

Why Serverless?

Starting with a few Amazon EC2 servers was a quick option for us to go live. Given the complexity of apps and the amount of data we had to handle, we knew that the servers would become unmanageable very soon. We wanted to invest our time in building something scalable rather than being burdened by operational overhead. So we decided to go with the serverless model of deployment using various products that AWS offers.

Which AWS products helped us address these challenges and go serverless?

  • AWS Lambda: We developed multiple microservices as part of our architecture. Lambda makes our life easy; push your code, and one is sorted. After that, we don’t need to worry about managing servers, up-scaling or down- scaling servers. AWS Lambda takes care of all that.
  • API Gateway: All the business logic is exposed to clients using API Gateway, which serves as a proxy to the Lambda functions. It acts as a layer to provide RESTful API functionality.
  • Amazon DynamoDB with streams: DynamoDB Streams capture time-ordered sequence of item-level modifications in a DynamoDB table and durably store the information for up to 24 hours. Applications can access a series of stream records, which contain an item change, from a DynamoDB stream in near real time.
  • NoSQL database to store the definitions of our apps and workflows, as these definitions are very dynamic. Also, as our submissions data grew from a few hundred per month to a million per month, DynamoDB got auto-scaled to handle the load.
  • AWS Step Functions: Step Functions allow us to orchestrate multiple small business functions like sending emails, SMS, and making external API calls.
  • SNS/EventBridge: Amazon SNS provides pub/sub functionality provides topics for high-throughput, push-based, many-to-many messaging between distributed systems, microservices, and event-driven serverless applications. Another service for application integration is Amazon EventBridge. It connects applications using events. An event is a signal that a system’s state has changed, like a change in the status of a customer support ticket. Customers can integrate their own AWS applications with microservices. We do a lot of asynchronous processing on our data, publishing events to AWS SNS and EventBridge and then handling these events independently. This ensures that we don’t impact the latencies of our core functions.
  • AWS OpenSearch Service (successor to Amazon Elasticsearch Service): Amazon OpenSearch Service lets you deploy your Amazon OpenSearch Service cluster in minutes to provide a fast, personalized search experience for applications, websites, and data lake catalogs, and to quickly find relevant data.

We send our app submissions data to ElasticSearch from where it is queried to get summary and aggregations. Following is the high-level architectural diagram of our system.

full AWS service icon architecture diagram on white background

There are four major components of the architecture.

    1. App Definitions: Admins of the end consumer organization are presented with an app designer to create apps for their users. The designer is a single page web application developed on Angular, hosted on Amazon s3 and served through Amazon CloudFront. It offers simple drag and drop blocks for the admins to design the apps. The calls to save the app definitions are sent to the Definitions Microservice Lambda Functions via API Gateway, and these definitions are stored in a DynamoDB Table. This DynamoDB Table has Streams enabled, which triggers a Lambda that maintains versioning of these apps in another DynamoDB table.
    2. App Submissions: Users of the apps access their apps on the web or mobile. The data submitted by these users come to the Submissions Microservice Lambda Function, again via API Gateway and stored in DynamoDB. In some cases, users upload images, videos and documents as well. These are stored in Amazon S3.
    3. Workflows: Once the data is submitted and stored, asynchronous events are published on SNS and EventBridge, picked up by the Workflows Execution Microservice and sent to AWS Step Functions. Step Functions perform the tasks for sending notifications, making external API calls, running schedules/loops etc.
    4. Analytics Engine: All the data is also sent to ElasticSearch Service. The Analytics Microservice queries ElasticSearch to perform aggregations on the data and present the admin users with simple interactive charts and data visualisations on a custom built application.

What benefits do we get by using the Serverless products from AWS?

1. Cost

By going serverless, cost is the most obvious advantage in the early days of the product. We pay only for the requests that we serve. This means that we need to pay almost nothing when we have a small customer base. Additionally, AWS Lambda gives 1 million free executions every month forever, which is a significant cost advantage for a B2B product. This helped us save a lot of money in the initial few months, and we spent it on our product development.

2. Serverless

If we manage our servers, too many operational tasks come up – monitoring CPU/memory utilization, restarting processes in case of any issues, fixing OutOfMemory exceptions, fixing networking issues, etc. This creates a 20-40% operational overhead on the developers. With the serverless model, we seldom have to bother with these issues. Developers can focus only on developing the core business logic.

3. Scale

The serverless model is inherently scalable. It takes zero hours of effort to scale a serverless application up or down. If customer requests went up from a few hundred per day to thousands or even millions per day, the serverless model would take care of provisioning infrastructure for application.

Conclusion

Overall, going with the serverless model helped us build and release our platform much faster. It is continuously proving to be beneficial in terms of maintenance, speed of development. and ease of scaling. We shall continue to leverage services from AWS platform to build our future applications and continue to publish on Clappia marketplace. As we are currently targeting more and more enterprise customers, we are expecting the number of users and the amount of data and users to grow by more than 5,000% over the next year, and we are confident that with the serverless model, we’ll be able to easily handle the increased amount of load.