101–110 of 196 posts
Either "trigger" is a blacklisted word or your domain is on a list somewhere, because my company has this url blocked under the "weapons" category. That's unfortunate.
Earlier quoted context omitted.
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…
> 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 ini…
This is fascinating. It checks a lot of my boxes. I was recently looking at ActionsFlow [0] which is similar but runs on GitHub Actions. My thoughts - 1. I don't see proper secret storage being handled. You typically don't want your API keys in your code. What would you recommend instead? 2. "OAuth" based secrets. Many integrations require giving access to an App via OAuth, which involves a flow. I think that's being…
Thanks for such an amazing reply, I'll do my best to answer everything. I am also on the Trigger.dev team btw. 1. Your API key with us can either be passed into the Trigger constructor or you can use our TRIGGER_API_KEY environment variable. For the API integrations we provide, we handle API keys for you and they're added inside the dashboard UI. For everything else: as the workflows and files are just code on your s…
I can't help but think that you want a state machine here, rather than imperative code that's being analysed to try and get some kind of a graph out of it..
I'm personally looking forward to a cloud, state machine based service that offers the whole long running workflow thing. The closest I've seen so far was people using xstate within temporal.io workflows.. but would be amazing to have really nice observability out of the box, with all the clarity that state machines bring.
Is this any way related to the Nango & Pizzly projects? I see they're mentioned in the docker-compose file. https://www.nango.dev/ for reference. [Edit: Added link to Nango website]
Recently I needed some really infrequently executed background workers. Basically just generate a CSV from our DB, email it somewhere. Historically I'd setup a Redis backed worker queue for background jobs. However, right now the aforementioned job is my only background processing requirement and it's massively overkill since serverless is supposed to take care of the infra headache for me. What I found was a surprising amount of BS to get serverless runners doing what you want - there's execution limits, trigger limits, terrible developer experiences (depending on the platform) etc. If you're already invested in a serverless ecosystem, this isn't a huge deal, but for the odd one-off task, the current options are kind of terrible. Supabase edge workers for example are way too limited for this use case. Cloudflare Workers (with the queuing stuff in beta) are probably the best option. But your batteries included approach seems super appealing for this kind of stuff. That said, I think you're in for a hard time marketing this. It requires devs to have "learnt the hard way" before they understand your value proposition.
Earlier quoted context omitted.
Currently we are hosting, but we are going to be documenting how to self host in the near future so you can host it yourself.
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 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!
At first I thought that a code alternative for a no-code solution like zapier was counterintuitive. But as an engineer using Zapier (for the first time) these past few months I got so frustrated by the lack of an option to just write some "if" or just 2 lines of code to make things work the way I want them. I think trigger.dev nails it. This is exactly what I needed.
I forgot to mention in the original post we've built a bunch of example workflows here: https://github.com/triggerdotdev/trigger.dev-examples
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.
The example repo eallam shared has more though, we will be moving all of them to the docs soon!