Technical : Request life cycle

There are two types of interactions between the Slack servers and your aido application :

• Slash : This happens when the user types /somecommand in their Slack client
• Action : This happens when the user interacts with one of your application's views, be it by clicking on a button, or submitting a Dialog form.

When one of these happens the Slack servers will send a request to your aido application, which will be interpreted by the aido library and execute the relevant code. The life-cycles of Slash and Action are slightly distinct. Please refer to the Slash reference page for additional informations on Slash class properties and methods / hooks.

Slash

• User types /somecommand in their Slack client
• Slack sends a POST query to your aido application
• Aido verifies that the query does indeed come from your Slack application, using the provided signingSecret or slackVerificationToken
• Because Slack queries contain snake_cased parameters, the payload is normalized in camelCase
• Aido identifies the slash command that was used, along with any text accompanying it (/somecommand some text) and informations on the Team and Channel where the command was invoked
• Aido creates an instance of your Slash class and executes these hooks in order : initDb, init
• Aido identifies the user invoking your command
• Aido responds to the Slack query with an empty response ⁽¹⁾.
• Aido creates an empty session for the user, or retrieves one from the database if it exists
• Aido executes the handleText hook.
• Aido persists the user session in database
• Aido renders the view and transports it to the user's Slack client

(1) This is important because after a few seconds the Slack servers will consider that your application is inaccessible and display a "time out" message to the user. Please note that this does not preclude your application from functioning, as the response URL provided by Slack can be used for around 30 minutes after invokation.

Action

• User clicks a button in one of your views, or submits a Dialog form
• Slack sends a POST query to your aido application
• Aido verifies that the query does indeed come from your Slack application, using the provided signingSecret or slackVerificationToken
• Because Slack queries contain snake_cased parameters, the payload is normalized in camelCase
• Aido identifies the Slash which contains this Action
• Aido creates an instance of your Slash class and executes these hooks in order : initDb, init
• Aido identifies the user invoking your command
• Aido identifies the action executed and its parameters
• Aido responds to the Slack query with an empty response ⁽¹⁾.
• Aido creates an empty session for the user, or retrieves one from the database if it exists
• Aido executes the preAction hook, followed by the method for your action, and finally the postAction hook ⁽²⁾
• Aido persists the user session in database
• Aido renders the view and transports it to the user's Slack client

(2) The method for your action is determined by the button's name attribute, or the form's action attribute. Please see the examples folder for insight.

A word about sessions

A session is a record in your aido database, storing informations on the interactions between a user and a Slash command. It is updated with the state of your Slash after each execution, and is basically an arbitrary Javascript object stored in a JSON column. Sessions are also cached in memory for better performance, although this cache is of course reset each time your application restarts.

When a user executes a Slash or Action, aido will create or retrieve the corresponding session through the following steps :

• First try to find it in the memory cache
• Then try to find it in the database
• If no session was found, then this is the first interaction between this user and this command : we create an empty state using the initState hook