4 ms·

Sure, what kinds of questions do you have? We're still pretty early in the process and I think we made a few mistakes that we'll need to correct. But we made a

Sure, what kinds of questions do you have? We're still pretty early in the process and I think we made a few mistakes that we'll need to correct. But we made a number of choices that have worked out really well despite the fears of some of the team. A few notables: - Written in Rust. This caused some early struggles, but has been paying dividends ever since we got it working. The thing is rock solid and easily handles tens of thousands automation runs per second. Also, Pest is awesome and writing complex lexer/parser implementation is really easy these days. - We're currently triggering automations with HTTP calls, but we want to move to primarily triggering with some sort of work queue. - We didn't consider aggregates in the first iteration of the product and now we're feeling that pain and looking at solutions. - Tracking the types of all data through every step of the automations was a lot of work to setup, but is hugely valuable. Being able to suggest what values/operations are available to users in the UI as well as doing AOT type checks when saving automations means a lot fewer errors at runtime.

porker 8y ago
My questions are around the usage of it: - How have users taken to the tool? Have they needed ongoing support, or once trained they understand what to do? - Were alternatives considered? Or was the complexity such that a workflow was the only way users could control this? - Do people ever manage to design impossible flows? - Anything about the use-case you're able to say, for where the tool is needed by users (and not just as an easier way for developers to adjust the system)
- curun1r 8y ago
  Sorry I missed your reply...I stopped following the thread. But in case you're still reading, here's some responses: > How have users taken to the tool? Have they needed ongoing support, or once trained they understand what to do? It's been a bit of a struggle. Once people understand how to use the UI, they go to town and get a lot of value out of it. But we've found it's not approachable and basically requires us to teach them how to use it. We're continuing to experiment with it. The good part is that everything we're trying is supported by the underlying DSL and workflow engine and we really haven't had to make more than a couple of tweaks to that. > Were alternatives considered? Or was the complexity such that a workflow was the only way users could control this? We looked into off-the-shelf options, but we didn't think they'd give us the level of control we wanted to build a product around it. As mentioned above, the hardest part is the UI, and if we're building this as a product, we need to build that anyways. > Do people ever manage to design impossible flows? No, that's impossible through the UI. Since we're tracking the types of all data throughout the execution of the flow, we're able to analyze the flow statically before it's saved to the database and give users an error. But they basically can't even get that because our UI prevents them from choosing illegal values or setting up infinite dependency chains. > Anything about the use-case you're able to say, for where the tool is needed by users It's designed to be kinda like Zapier, but for a much more specific audience who are generally less technically adventurous. In talking with these users, many of whom use Zapier, we've identified that they find it difficult to use and not really suited to their use case, so we're hoping that something that's purpose built for that use case will make their lives easier and convince them to switch.

porker 8y ago

My questions are around the usage of it: - How have users taken to the tool? Have they needed ongoing support, or once trained they understand what to do? - Were alternatives considered? Or was the complexity such that a workflow was the only way users could control this? - Do people ever manage to design impossible flows? - Anything about the use-case you're able to say, for where the tool is needed by users (and not just as an easier way for developers to adjust the system)

curun1r 8y ago
Sorry I missed your reply...I stopped following the thread. But in case you're still reading, here's some responses: > How have users taken to the tool? Have they needed ongoing support, or once trained they understand what to do? It's been a bit of a struggle. Once people understand how to use the UI, they go to town and get a lot of value out of it. But we've found it's not approachable and basically requires us to teach them how to use it. We're continuing to experiment with it. The good part is that everything we're trying is supported by the underlying DSL and workflow engine and we really haven't had to make more than a couple of tweaks to that. > Were alternatives considered? Or was the complexity such that a workflow was the only way users could control this? We looked into off-the-shelf options, but we didn't think they'd give us the level of control we wanted to build a product around it. As mentioned above, the hardest part is the UI, and if we're building this as a product, we need to build that anyways. > Do people ever manage to design impossible flows? No, that's impossible through the UI. Since we're tracking the types of all data throughout the execution of the flow, we're able to analyze the flow statically before it's saved to the database and give users an error. But they basically can't even get that because our UI prevents them from choosing illegal values or setting up infinite dependency chains. > Anything about the use-case you're able to say, for where the tool is needed by users It's designed to be kinda like Zapier, but for a much more specific audience who are generally less technically adventurous. In talking with these users, many of whom use Zapier, we've identified that they find it difficult to use and not really suited to their use case, so we're hoping that something that's purpose built for that use case will make their lives easier and convince them to switch.