Warning!
This is a legacy document. The features described below are only usable within the classic-generation environment.
Currently, Betty Blocks offers faster and more advanced options that are available in next-gen. Before you start working on some new features in your application, consider doing it using the next-gen version. Good luck!
After reading this article you’ll know:
Ways to improve the action workflow in your application
Obstacles you may encounter while building actions
How to minimize extra overhead while adding new action steps
Actions provide logic in your application. This logic is executed through actions and could be rather complex depending on the personal needs of a citizen developer. Although Betty Blocks constantly works on increasing the speed with which actions can be processed, there are still things you as a builder can do to minimize extra overhead being added to action steps that need to be fast. This article will describe ways and tips for building an efficient workflow in your application’s actions.
Note: Before we start, it’s worth mentioning that there is no single solution to guarantee your action is fast. Every variable or step you add to the action takes time to process and execute, slowing down the action flow. All features we discuss have a reason for being and are very valid solutions on their own. However, if you combine or stack them, things might get complex and slow very fast.
Also, if you have an access to the ‘Next Generation’ actions, it’s highly recommended that you build your application using these. There are several reasons for that: they are faster and will receive more support in the near future.
Analyzing actions
There are a few ways to analyze your Actions or your Application. The best way to analyze your app is to go https://<my-app>.bettyblocks.com/monitoring/background-jobs. From there you can get a quick overview of the performance of all your actions over time, as well as zoom in on specific Actions.
There are a few things that can take up a lot of time when executing an action, but most commonly are:
Accessing the database (e.g.: updating records, fetching collections)
Model callbacks (e.g.: after_save, after_update that trigger a new Action)
Expression properties
Calls to an external service (e.g.: HTTP requests)
Accessing the database
Actions would hardly be of any use if we couldn’t use them to access the data from the application’s models. Use Limit and Offset wisely to make sure you run Actions for predictable amounts of records. Otherwise, this can lead to actions that you didn't change for a long time and suddenly they work anymore, simply because the collection it processes grew too large.
Remember to combine saving and updating the same record as much as possible. It’s far more efficient to use a single update event with a few before_validate, before_save, and an assign event, than multiple after_save or after_update, etc.
Do not fetch data you are not going to use. Filter it accordingly.
Note: Running into ‘MySQL Timeout Error’ could be a sign of accessing your application database too often in a given time interval.
Model callbacks
Callbacks are triggered whenever a record is created, updated, etc. If you want to execute some logic after a record has been changed and you want to apply this logic once for all such cases, callbacks might come in handy. They allow executing an action whenever all background jobs of another action are done.
Generally, callbacks can trigger new callbacks and even expressions. All of these add to the total runtime of background actions. It’s relatively easy to lose sight of the bigger picture and create complex logic that chains callbacks and expressions.
Take into consideration these points while applying model callbacks:
Think twice before introducing any kind of callback. Do you want to add the overhead when the record is being saved/updated, etc?
Consider refactoring your callback actions into separate actions that you can later call in specific places if you find yourself using the ‘Skip actions’ options for a specific action.
Use a before_create or before_save callback combined with an assign event if you want always to set certain values for a record. These callbacks and events don't access the database, saving you a lot of precious time.
Do not add an after_update or after_create callback to a model in which you update the current record again. This can lead to infinite loops and crash your action.
Also don’t fetch associated records in a callback. This leads to very inefficient calls to the database. Especially loading collections for each record introduces longer callbacks.
Expression properties
Expression properties can pause the background queues, slowing down the throughput of your actions. Be mindful of updating records in large volumes where the model has expression properties.
Background actions
Betty Blocks offers the option to run an action in the background. The platform will then create a so-called “job” and place it on a queue. These “jobs” will be continuously taken out of the queue and the actions will be executed. This feature is beneficial when you want to process large amounts of records, or when you don't want the end user to wait until the action is done.
Running an action comes with a few limits that may be tuned down even more in the future. These limits pertain to the duration and the size of the payload for the job (read: the values of the input variables):
Duration limit: The total duration of a background action is currently capped at 1 hour. After that, the Action is aborted and will result in an error message in the Application logs.
Payload size limit: The total size of the payload cannot exceed 100kb. For reference, the average for almost all actions is well below 50kb. It's currently not possible to view the size of these job payloads, but following the points to consider listed below, it is almost guaranteed that you'll never hit those limits. If your application does try to run such a job, the job will be aborted and will result in an error message in the application logs.
Take into consideration these points while applying background actions:
Check the “Background” checkbox if the action is blocking for the end user
Create the background actions for individual records or batches of records when looping over large volumes of collections
Do not pass files as input variables to Background Actions. Instead, store files in a record and pass the record or record ID.
Also, don’t pass collections as input variables to Background Actions. Instead, pass just enough info to fetch the collection in the Background Action itself.