Building chatbots at Haptik is our Forte & we try to follow the best practices available out there to solve complex problems in hand. Recently, we were facing a problem where our conversation flows have become very complex over a period of time and the code that is written was getting hard to manage and understand.
When we started digging deeper we noticed that most of our flows follow a simple state machine where based on a decision of the previous steps the next step is decided.
So What Is A Finite State Machine?
“A finite state machine (FSM) or finite state automaton (FSA, plural: automata), finite automaton, or simply a state machine, is a mathematical model of computation. It is an abstract machine that can be in exactly one of a finite number of states at any given time”.
Finite state machines come handy for state management. This design pattern is quite common with programmers in the gaming world. You can represent your data in a variety of state machines. You need to choose the one that best fits the use-case in hand. This programming pattern forces you to expose your data and think about different scenarios and evolutions thereby making your code concise and readable. Anyhow, this is “not a one-size fit all approach“.
How Do We Use Finite State Machines At Haptik?
Let’s take a simple problem and define its scope first. At Haptik, we have a feature where a user can set a reminder for their daily tasks and we call them to remind them about it. In this flow, one of the major requirements is that a user should be able to update a reminder that they have set previously. For example: If a user has set a reminder for 25th September at 7:00 am they should be able to change the date and time of the reminder at any given point in time.
What Does It Take To Update A Reminder Flow?
- 1. User comes to the app and says I want to update my reminder
- 2. Then we check whether the reminder exists or not
- 3. If it exists, we check if updated date & time is provided
- 4. If we have the updated date & time, we check if it is valid or not
- 5. If it is valid, we go ahead and update the reminder
The above is a basic happy flow but if you look at the flow diagram there are a lot of negative cases that we need to handle as well. That’s where things start getting complex and if the code is not written well, it becomes hard to understand.
First, you start to think about different entities/states for the given use case; these become the states of your finite machine. Next, you start to think about transitions/events that can be triggered which allows you to move from one state to the other.
Implementation Without Using State Machines
Let’s try to implement the above use-case without using state machines. First of all, we would start modeling our data and then we would start to think about the functionality. Later, we would need to map each functionality to a function which deals with a single responsibility pretty well:
You can see where this is going. One has no idea about the current state and has to deal with various conditions. This gets messier as the code base becomes larger. For someone having a look at the code for the first time, it would be a nightmare. Also, when any new change has to be made, the code has to be touched at multiple places and the possibilities of missing out edge cases and making mistakes is very likely.
Implementation Using State Machines
Now, let’s get our hands dirty and learn how simple it is to create a finite machine to solve the above problem. A great module called state_machine is available as a pip package. It’s a simple well-written Python Framework to create customizable finite state machines (FSMs). You can read more about it here.
Let’s start with the Reminder class. Each update will have its own state machine. The first step to create a state machine using the state_machine module using the @acts_as_state_machine decorator:
Next, we define the states of our FSM (Finite State Machine). We need to mention the initial state of the machine; we can do that by passing initial=True in the constructor call of State:
We continue defining the transitions. It is normal to execute one or more actions before or after a transition occurs. In the state_machine module, a transition has the name Event. We define the possible transitions using the arguments from_states (can be either a single state or a group of states) and to_state like in the below example:
Now, that we have an understanding of how the flow looks, we can go ahead with the finer implementations. For the sake of simplicity, a reminder can be modeled based on the below attributes:
Transitions are not very useful if nothing happens when they occur. The state_machine module provides us with the @before and @after decorators that can be used to execute actions before or after a transition occurs.
Let’s define transition() function which accepts two arguments:
Wow! This is amazing. We eliminated a lot of conditional logic from the codebase. There’s no need to use long and error-prone if-else statements that check for every state transition and reacts upon them. The implementation is python specific but the pattern is code agnostic and can be abstracted to any relevant use case.
Hope this blog helps you understand how we can effectively use the state pattern.
Do let us know your valuable feedbacks & do come back for more such blogs. Also, we are hiring for various positions at Haptik, so if interested, do get in touch with us at firstname.lastname@example.org. More details here.