How to combine Low Code with AWS to build any product

The perfect match

Yes, you can combine your Low Code application with Amazon Web Service. This gives you endless possibilities for features and helps you to overcome the scalability issue. Read more about how I combined those two to create a podcast transcription service product.

‍

Why should I combine Amazon Web Services with Low Code tools?

In order to answer these questions, you can consider two of the main issues that are associated with Low Code. Both issues can be solved, when you combine Low Code tools with AWS or other cloud services. Let’s have a look at them.

First, Low Code is often considered not to be scalable. I do share this perception partially. In many cases, Low Code builders are missing basic software architecture skills, which makes them create inefficient workflows. That’s not the issue I am talking about in terms of scalability. That is totally solvable with appropriate skills. Rather, I am talking about the heavy workload here. Those workloads can be image processing, storage and processing of large amounts of files or data analysis. I guess, that you would not be thinking about those in terms of Low Code, would you?

The second issue is the lack of possibilities or the lack of features in Low Code tools. It’s clear to me that you cannot implement an endless number of features as a Low Code tool provider. So, we do certainly have a lack of features. However, we don’t have a lack of possibilities to extend Low Code tools. You can leverage AWS or other cloud services to implement those features by yourself. If you do so, this opens up a whole new universe of possibilities to extend your Low Code application.

Let me sum that up for you. Here is why you should combine AWS with Low Code:

1. You will see cost advantages when you use a lot of storage capacity (think of large files)
2. Clear separation between heavy workload (AWS) and User Experience in Low Code
3. Scalability for AWS-based workloads
4. Endless possibilities through extension of Low Code tools

Practice what you preach: Online podcast transcription as an example

It’s always easy and fun to talk about something in theory. I am more into really doing what I talk about. That’s why I want to introduce Product P as an example of the perfect match. I’ve developed the initial version of Product P in a couple of days as a side project. It’s the blueprint for everything I will explain in the following paragraphs. You can go check it out at product-p.com. It is a fully functional product. Product P is built with bubble.io and integrates with Amazons Audio Transcribe Service.

With Product P, you can transcribe podcasts and other audio recordings online. You upload your recordings and the service will automatically convert the spoken word into text. You can then retrieve the text and publish it as an interview on your website, for example.

Now, let’s have a look at how the four whys apply to Product P as an example.

Cost advantage for storage

In theory
When you use Low Code tools like bubble.io, you typically see plans with different amounts of database or file storage. It can get expensive quickly if you reach the limits of gigabytes or rows in a database. You can leverage databases and file storage provided by cloud provides to escape those high costs.

Another advantage of integrating with storage or a database that is under your control is related to data privacy and hosting. You might need your data stored in your home country or being encrypted with your personally owned key. That’s something you can do on AWS.

In practice
When you upload your .wav or .mp3 file to Product P, we do store it in AWS S3 (Simple Storage Service). Just one file can have a size of 50 MB easily. With the personal plan in bubble, you do get 10 GB of file storage. So, we could store 200 audio files, which is not sufficient at all. For the user experience in bubble, we only store a reference to the file in S3. The user doesn’t even notice, that the file is not stored with bubble.

The S3 file storage only saves us more than $400 in Low Code operation fees. Furthermore, we can use AWS’ retention policies, which do clean up dangling files after a couple of days.

Clear separation between workloads and user experience

In theory
The separation between workloads and user experience is a key contributor to development speed. The traditional software development activities (coding, testing, etc.) happen on the workload-side. With AWS Server Application Model (short SAM, will be explained below) the developers can focus on business logic only. Even if the business logic takes a little longer, the user experience can be tested and iterated on already. This is due to decoupling both.

The user experience like registration, login, payment, upload of files, orders, bookings or whatever you want to do are done with Low Code tools. Here, we don’t need any bootstrapping at all. The login or payment (just examples) don't need to be implemented with traditional coding. You can focus on the parts that deliver customer value. The actual interactions that the user does with your product.

In practice
Let’s look at an example to make the point. The main feature of Product P is the transcription of audio into text (this is the workload). That is done in AWS. The code that executes the transcription is done as traditional software development, although kept to a minimum of two days of work for one person (myself ;-)).

While I write the code for the transcription, a Low Coder can already build the user experience. For Product P, you need to sign up, upload a file and pay for the transcription. All that is done with Low Code in bubble and could be iterated on already before the actual code for the transcription is ready.

Scaleability for workloads

In theory
Scalability is one of the major buzzword around cloud computing like it’s done by AWS. When using cloud services, I do build software on a paradigm that is called serverless. It means that you don't run servers, but only execute some code in a very atomic manner. It’s like moving in a city full of taxis. You don’t own a car (server). You just pick a taxi (serverless execution of code) when you need it. It’s easy, because the taxis work well, and you don’t need to maintain your car.

The AWS Serverless Application Model does exactly that. As a developer, you can keep your coding effort at a minimum. Even better than that: AWS does the scaling for you. So if you need 2000 taxis at once, they just show up around the corner. Your code gets executed fast, no matter how many users do the same thing at the same time.

In practice
The transcription in Product P runs serverless. When the users hit the transcribe button, the code gets executed in AWS and the transcription is returned. In case, 5000 users hit the button at the same time. AWS scales the execution up automatically and easily returns 5000 transcriptions at once. How cool is that?

Now let’s consider what the 5000 transcription mean for our Low Code application. In Product P, this means only 5000 clicks on a button. Those clicks send 5000 requests to AWS. In the scale of the internet, that is almost nothing. So, we don’t need to worry about the scalability of our Low Code application. Here, AWS does the heavy lifting for me.

Endless possibilities

In theory
This is one of my favorite arguments. It’s so important to recognize, that you are not limited to the feature set of your Low Code provider like bubble. Most of the providers provide APIs to integrate cloud services. And the same applies the other way round - cloud services like AWS provide APIs. In fact, everything in AWS is an API. That opens up the integration in both directions.

Having said that, you can start to think of your Low Code application as an application that can provide any functionality you can get from some cloud provider. You can do data science, you can do object recognition on images and videos, or you can build products around IoT-Devices. There are no limits. It is so cool!

In practice
For Product P, I set up an API Gateway in AWS. That API Gateway is secured and provides the bubble application with my functionality. It provides API Endpoints to upload files, to do the transcription or to analyze the file that the user is uploading.

I am already thinking of integrating Algolia as a search engine. That would be done through an API as well and could bring first-class search to the application. As you can see: There are endless possibilities.

Conclusion

I gave you a very practical example of how to combine Low Code tools with cloud services to build any SaaS application you can think of. Now it’s up to you to apply your knowledge and build the next cool product.

If you are more interested in how this all works, I’ve got something else. You can check out the second article from a technical point of view. Click here to read more details.

‍