Speaking only for us (trigger.dev founder here): In our last X products we've used two different solutions for accomplishing two tasks together: event-driven architecture and integrating 3rd party APIs. We noticed that these two concerns were intertwined, and weren't happy with how the existing solutions only solved for just 1 (leaving us to build the other). We also noticed how well tools like n8n and Zapier solved these problems, but at the UI layer, and we wanted something like those tools but in code. Hence the creation of trigger.dev.
That's a good point regarding the marketing, although we're hoping to save a few poor souls from ever know the painful bits you so eloquently wrote about!
In the meantime, maybe remove "Your workflows run on your servers, not ours. We only receive the data you choose to send to us." from your front page marketing?
The website is correct, it's just a bit confusing so I'll explain more here:
The workflow code is in your codebase and runs on your servers, we don't host that.
We host the service that triggers your code (using events like scheduled, webhooks, customEvents) and that you can call using our SDK to do requests, logging and delays inside the workflow (e.g. using our Slack integration or using our fetch that auto-retries with exponential back-off). We also host the web app that you use to authenticate with APIs, show all of your runs with associated data and any errors.
Soon we will add a self-hosted guide so that you can also choose to host the Trigger.dev service yourself too. It's a bit hard to explain, hopefully this clears things up!
Is there a brief description of what each example is? After following that link, I was just looking for one or two sentences, without having to look through each script.
We haven't done any ee features yet, which is why we stuck that "if such directories exists" line in there. We're following the playbook from some other OSS companies such as PostHog and Cal.com. Features that will go in ee (off the top of my head) are the teams and billing features of our hosted option.
We'll be working on self-hosting instructions soon as well :)
A little while back, I was working with a startup that built an AI note taking app. They offered several integrations for their customers, and at the time I wished that there was a Zapier alternative that allowed for a multi-tenant approach (i.e. build a pipeline that each customer could independently hook into with their own external accounts).
I haven't had a chance to go through your site yet, but that would be a killer feature to have.
Indeed we've had a few people who've requested this type of thing (they want to make requests authenticated as their customers, not as theirselves). Currently we only support making requests as yourself (e.g. post into your own slack channel), but our architecture will support making requests as your customers, and something we are very interested in doing eventually
When you look at self-hosting instructions then it would be great if it would be one that does not require Docker in your stack. Installation shell script would be even better.
Yup I've done the AWS Step Functions thing in the past, and it usually was about 90% wrangling with AWS and 10% writing code... we wanted to flip that ratio around (that's the goal at least!)
As for temporal, we are pretty similar to them, although I think we have more of a focus on making it easy to trigger (sorry) the workflows from third party events (webhooks, etc.) and then making reliable requests once you are in a workflow.
Thanks for the feedback though, we'll try and add service comparison docs soon!
> Yup I've done the AWS Step Functions thing in the past, and it usually was about 90% wrangling with AWS and 10% writing code... we wanted to flip that ratio around (that's the goal at least!)
That was the final straw what led a friend and me to try to do what you’ve done.
We had started off using Zapier, and it’s horrendous objects & arrays handling, then moved on to Step Functions, then gave up on what we were initially doing to try and build a workable alternative.
With a cumulated grand total of 6 months of experience, we had no idea what we were getting into.
Now that AWS App Composer is a thing is this still an issue though? I felt that pain in the beginning, but once you get the hang of Step Functions it doesn't seem so bad. I never found a good alternative. My company is using Workato and it's a nightmare.
I should have mentioned this was more than 4 years ago. I remember having to use a Choice State to hack together my own looping mechanism.
Considering how much progress has been made since, and even though I haven’t gotten around to try App Composer for myself yet, I would tend to agree on both, with two caveats.
First, after Amplify, I am wary of any and all AWS "It just works™" claims.
It seems they have a hard time figuring out what "easy", "simple" and "straightforward" mean. And I say that as someone who very much appreciates Lambda, DynamoDB, EventBridge & co, and really wanted to like using Amplify.
Second, considering how expensive those can be to run, I would think twice before using them in a "high"-throughput and low margins scenario, and definitely appreciate there being alternatives.
Regarding Workato… I’d never heard of it. But the description they picked for Google and their landing page makes it clear who they’re appealing to and on what grounds. Sorry you have to deal with that.
Thanks! That's been our experience exactly and is the reason we're building it. The experience of AWS step functions on one extreme and Zapier on the other.
Oh, no. The other extreme wasn’t Step Functions. It was AWS Lambdas stringed together through DynamoDB Streams, SQS, SNS and S3 triggers, all obscurely tied together in a murky single-file yaml template deployed by JAWS (now the serverless framework, which has definitely made some much-appreciated improvements).
But something
- offering a clear visualisation
- and allowing to simply integrate with third-party APIs
- without having to deal with some’s quite obscure documentation
while at the same time
- easy to monitor & debug
- offering versioning
- allowing to just write a few lines instead of going through pointy-clicky drag-and-droppy mess
Yes, that was lacking. Reminds me of Zenaton (https://zenaton.com/). I can only wish you to be more successful than they were.
