STATEWIZE Documentation

Flows ("state machines"), as a service

Before we met

You were sitting in meetings, listening to the requirements for the next feature that just has to be implemented.

Someone, on the massive TV monitor in the meeting room (or just your lappie, during pandemic) outlined all the aspects of that feature, and drew the user journey on the whiteboard. You sipped on your coffee and thought to yourself "Great, 2 more meetings to go and then I'm done". Wishful thinking. In the following meetings, the company's architect used another whiteboard, and drew once more the business flow, only this time it was technical; She used UML diagrams and JSON objects to present an architecture that has to be translated into code. All the team members took pictures of the whiteboard using their phones, and a few days later started to write code that tried to simulate what had already been drawn on the board at least twice. 4 months later, you've completely forgot about that feature

You investigated a production issue, trying to understand how on earth that one user got an extra $50 of credit. Grinding through thousands of lines of logs, you realize that the logs do not go far enough to the past, and so you have no idea what is going on. Helpless, you are trying to reverse-engineer the whole thing based on the deployment history, CI logs and the repository's commits history. "Thanks God we are not using microservices", you think, as you realize that performing this horrible ritual for every single service would take you hours. You did not sign up for this. Eventually you realize that there's nothing you can do to resolve the issue, so you do what any other good engineer would; add a bunch of logs to the codebase, commit and push it, and ask the customer services to tell the end user to retry their operation, this time hoping to gain some clarity. Fingers crossed! Unfortunately the customer is already gone, the FCA enquiry will be starting in a week, and no one can provide any answers to the question "how did we just lose $2 million across 150k customers?".

The Issues

Oh the things poor old you had to endure, and all due to a faulty outdated process:

  • Too many layers of abstraction between business requirements and code, meaning there are plenty of places for things to go wrong or simply missed.

  • The inevitable need to manually add logs where required, trying not to make it too verbose.

  • Time traveling to the past executions requires hours and hours spent diving through commits, history, tickets, comments, cups of coffee and despair.

  • Tracing bugs and fixing them is a mission impossible, especially when using external resources

The separation between business and code is imperative, when using the old development tools. One has to use about 10 or more different tools just to be able to do one simple thing - write some lines that do what we want! A code editor A ticketing and tasks system. A code repository. A design tool. And whiteboards. So many whiteboards. This 'divide and conquer' also exists between the code written and the code executed; Devs will ALWAYS be forced to manually reverse-engineer the code in order to understand what happened at a given time for a specific customer.

And now we're all here. Yes, we're happy to see you too.

STATEWIZE

One single ecosystem where you implement business logic by "drawing" it. Where you see exactly what has happened in past executions just by clicking on a link. Where the "lost in translation" issue - is simply nonexistent.

  • Business flows are represented visually, instead of lines and lines of code that you need to "imagine" in order to visualize what they look like in terms of execution flow.

  • History is saved; Every execution will be saved so that you can always look back and see what happened, when, why and how. Say eyB to reverse engineering.

  • Real time execution monitoring allows you to make decisions, fast.

  • Re-executing from any point of the state machine is possible with a single click. Something failed? Don't bother your customers and ask them to retry; just do it for them.

  • Testing is easy; The ecosystem includes environments for development, testing, staging and production.

  • Secrets are part of the game; Store secret values per environment, and use them as you need them.

  • Plug-and-play; Choose the logic for a certain state from our pre-designed list, or implement your own using the embedded code editor (fully functional, with external libraries support and intellisense, all in the same place).

Let's Get Started!

Alternatively, you can look at our guides for: