How to build apps in less than a month using No-Code&Low-Code

**Are you looking for a way to create internal tools for your company without putting dozens of engineers per quarter? **

Or maybe you have a great idea to build a startup, but you want to ‘be lean’ and validate your idea first?

If the answer is yes, fasten your seatbelts as this article will take you on the journey without (or with little) code and give you an insight into how to build economically and quickly, with the help of The Three No-Code&Low-Code Musketeers – Airtable, Stacker, and Slack*.

Our heroes and their weapons

Airtable is an easy-to-use tool that has some of the power of relational databases with much more. It combines the functionality of tools like Google Sheets, Asana, Trello, Pipedrive, Survey Monkey, and Calendly with the storage capacity. Along with unlimited possibilities to display data and perform certain operations, it also offers Automations, Scripting, and REST API, which is adjusted to the database schema in real-time. This means you can adapt and create your workflows.

Stacker turns spreadsheets and databases into functional apps, providing a good-looking UI and allowing the creation of various roles so that different types of users have multiple permissions. Authentication, connection with the database, and security are provided, so all you need to do is manage permissions and filter the data.

Slack* is not a low-code/no-code tool on its own. Instead, it is a well-known collaboration and communication platform that is used more and more nowadays. It connects well to Airtable to smoothly send notifications about anything right off the bat.

How can we use them to build an app – Case study

Our goal was to create a Time Tracker – the app that would be small, extensive, with a simple design without any bells and whistles. The main task is to track time reliably, without the need to generate reports and management oversight.

Airtable as a ‘musketeer-brain’ with its possibilities to use scripts and being triggered by specific events was an obvious choice to make calculations and more complicated operations that require code and logic, working with API, and customization. In our case, it was validation, creating bulk logs, and managing procedures related to the field of tracking time.

Stacker is natively integrated with the tool above and replicates the view of the Airtable base without any additional work. It is swift, and with the usage of roles, we can set up the database with selected access in a day or two.

The whole work there is based on filtering – At the beginning, you have all of our data, and your job is to display only the information you want for the specified type of users.

Unfortunately, as with every tool Stacker has its downsides – even though being the prettiest musketeer is also the slowest – it has up to 15 minutes delay for actions pulled from Airtable. Anything that is not directly connected to the record that you changed in Stacker and is not the one table you changed in this app will be displayed up to 15 minutes later (in the worst case), and related records won’t be updated in real-time).

And here, Slack comes into play. For our humble needs, we don’t need on-time information displayed on Stacker. As a user, you just want to know your activity: adding log, absence, or submitting your timesheet is correctly registered and processed.

**Notifications **

To ensure that our colleagues know what happened, or what will happen in the next 15 minutes, we had to figure out how to send notifications quickly and about every activity.

Because all of our actions trigger scripts, we are able to do everything we want, including creating a message with the result of the action.

Let’s take a look at bulk logging.

When a new record is created in the Stacker, the record is added in Airtable immediately. This triggers a script that is responsible for taking care of the new records. If the action didn’t fail, we would add a new record in Notifications – which has the data about the employee (email is needed) and the content of the action.

Here, one more time – Automation is triggered by a new record that will send generated messages to the user whenever it fails or succeeds.

Because of having only one table, we sparingly use only one automation (pro tip, Airtable has a limit for automation which equals 25)

Error handling in Airtable*

The previous idea covers delay, but there is also one important thing – operations errors.

How to inform given users about unexpected failure, e.g. in the script?

Airtable by default sends us messages about failure in automations. Whenever automations fail (script or any part of it), every member of the Airtable database receives an email with a short description of the problem.

But how can we notify the user only that the process failed but send detailed information to the developer to fix the problem quickly?

We can draw inspiration (copy) from the exact mechanism that we use for notifications. The only difference is that the trigger here is an error. Catching errors is familiar for every developer on the planet, and that is not a secret that the best solution is try-catch!

We put almost the whole code in a try-catch block. Even though it is considered to be an anti-pattern, the rules and principles of Low-code&No-code are sometimes quite different. In our case, every bug that happened during the execution of the code and created new records in the Errors table would send Slack notifications to the developers and users. This, at first glance, is the wrong approach and a cardinal blunder but enables us to leverage the ease and speed of Airtable’s messages and create a readable error log.

Whenever the error happens, both the user and developer know that something went wrong.

• Handling errors in this manner operates perfectly fine for projects created entirely on Airtable, not only for our Musketeers' combo.

Summary

No-Code&Low-Code revolution is here and conquering the software world (proof of this seen in Airtable with a value of almost $ six billion) thanks to a robust ecosystem that allows writing code there. Following the trend could be a good idea, provided that the apps have no complex programming requirements and require little or no customization.

The clear and obvious fact is that you can create apps much faster than in the case of the classic, technical approach. The entry barrier is much lower because only basic technical knowledge is needed to write useful tools that can automate and drastically reduce our efforts on doing repetitive tasks.

However, if your goals are flexible, or you want to create a complex system, which means multiple environments and a full-fledged test environment, the classic approach may be a better idea.

Anyway, this trend is definitely worth watching, because improvements are released almost every month, and the usage and possibilities are bigger and bigger. With a bit of cunning and acceptance that some features cannot be done, we get the potential to create apps that create value and can be adjusted to the fast pace of the current world. 

Author: Damian Naglak, Junior Software Engineer @ Appliscale LinkedIn: https://www.linkedin.com/in/damian-naglak/