arash-khazaei

I appreciate it - it is an important distinction!

> is this made for a specific context of APIs, like connecting all of “your company’s” email and messaging APIs?

Correct - our product is for connecting your internal systems.

If I understood the problem correctly, your client can choose not to rely on the "minimum implementation" Company 2 has built to connect to Company 1. Instead if it is possible, your client could use our platform to directly build a better integration between Company 2 and Company 1. Of course, we would need to understand the specifics, but in general our product can be used to build whatever business logic is necessary to connect systems within an organization/company.

Happy to chat more specifics if you reach out to founders at getstrada.com

Thank you!

Thank you!

Thanks!!

Thanks! We got feedback on the speed (we had sped it up) and reset it to the original speed, but it seems it still may be too fast.

We are going to record a slower, more in-depth video and host it on our docs.

Windmill looks cool and you guys have built a lot! Our focus is more on enterprise integrations for teams typically outside of engineering - we will continue building with this focus in mind.

At the end of the day we care about our customers and want them to solve their problems with whichever tools best suit their needs. We are on mission to build our version, but this isn’t a zero-sum game.

We've grown attached to "Strada", so for now no plans on changing.

I do have friends/colleagues forward me the occasional DHH tweet from time to time, whenever he mentions Strada :)

Very fair!

Thanks for the feedback!

- We'll take look to address this.

- We actually did slightly speed up the video. We will re-upload the video with the original speed. Thanks for calling this out!

Thanks - this was one of the main inspirations for building Strada! We had many conversations with integration developers and when we asked to see their workflows, we saw a lot of complexity in their low-code platforms that could have been made simpler with a more code-first approach.

One particular conversation that stood out was a developer that had to chain 6 layers of low-code blocks, just to flatten a JSON response. In this case he wished that he could write a simple recursive function to solve the same task.

1. Currently, we expose the status of actions (success/failure boolean), plus any additional metadata (status code, any http response header) so that you can retry (that's the nice thing about it being fully in Python - an `if` or `for` loop is easy to write). We are working on allowing you to configure the retry mechanism within the action, so we handle it on your behalf. However, for now we didn't want to be too prescriptive on what should happen on failure.

2. You do not have to worry about rate limiting calls to our service. We enqueue each request and respond with a HTTP status `201`, and our worker cluster will start processing the job. Within the workflow, 3rd party API calls can be rate limited, but for now we leave that to the discretion of the workflow author (see 1.)

3. I may need a bit of clarification on this one. Is the question whether you can provide idempotency key when making a request to a 3rd party endpoint? If so, yes you can. We have simple abstractions of common actions (for example sending a message in slack, or creating contact). However, you can always build your own custom action that sits on top of the underlying HTTP request, and therefore you can pass any additional parameter (idempotency key) in this case.