Missed an opportunity to call it Zapiest
Show HN: We built a developer-first open-source Zapier alternative
21–30 of 196 posts
Re: Show HN: We built a developer-first open-source Zapier alternative
#22Re: Show HN: We built a developer-first open-source Zapier alternative
#23My 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 handled internally from the video [1] and from this project [2], but it's not clear. How is that handled?
A common use case I'd automated once is that when a GitHub project gets starred, the developers public information is scrapped and they are then followed on Twitter, if their twitter handle is found. With Trigger.dev, the twitter part isn't clear.
3. Error Handling - What about when some job fails to run? I understand there is a delay mechanism. But what about injecting custom error handling? Sending a message on slack, for example.
4. Dashboards - They look awesome. And I get the impression that each "action" in the code is mapped to individual blocks in the dashboard. I'd love to be able to see a proper graph of the flow.
I love that I can see the json request / response for each. It'll make debugging easier when some API changes or fails.
5. No Code solutions - In the long run, I can easily picture writing the integration I want in plain text, and having Github CoPilot or ChatGPT generate the code for me, and then I can quickly modify it.
6. Incentive for integrations - As with most automation tools, entering the market is challenging as you're lacking integrations. The awesome thing about ActionsFlow [0] was that it was re-using an existing community of GitHub Actions, and therefore you don't start from scratch. Have you thought about reusing workflows from n8n or other projects?
7. Integrating with existing Automations - I think a bit more focus should be made on integrating with IFTTT / Zapier / n8n. I see you provide webhooks, but I think some easy wrappers + documentation would be better. This way, I can try out newer workflows in Trigger, and easily just extend my existing system. And then if Trigger.dev works for me, I can think about migrating away from my existing automation solution.
8. Open Source Longevity - Trigger.dev is MIT licensed. Could you please explain the rationale? How do you plan to combat someone launching a competitor using your code? N8n is deliberately "Soure Code Available" and not "Open source", which I thought was a decent compromise. Will you be following a more Open Core model similar to GitLab (which is also MIT licensed)?
9. De-coupling runners and the dashboard - I'd love to not have the pain of maintaining the dashboard / event listeners, but being able to control the running of the jobs. Similar to a CI or Airflow.
10. Support for other languages - This is something that Dagger CI [3] now allows. Letting you use whatever programming language. With Github Actions, I can just package it as a container. Do you plan to support anything else?
After moving from using HCL to Typescript for my Terraform code, the advantage is so great, that I can't seem myself going back to using a custom language such as Dagger's CUE [4]. Trigger.dev targeting Typescript is already a big win. However, I do have a number of automations in Python.
Overall, I'm super optimistic. Congratulations on the launch.
[0] - https://actionsflow.github.io/
[1] - https://www.youtube.com/watch?v=aFlwD0frvnQ
[2] - https://github.com/triggerdotdev/Pizzly
[3] - https://dagger.io/
Re: Show HN: We built a developer-first open-source Zapier alternative
#24Are you hosting or am I? The marketing implies that I’m hosting but your FAQ, at the bottom, says you are. Can you please clear up?
Re: Show HN: We built a developer-first open-source Zapier alternative
#25i think an open source zapier alternative would be a desktop app that had a nice UI, and synthesized terraform/FaaS code/API gateway-equivalent stuff behind the scenes and then ran it against my preferred cloud provider account. not this, as convenient for some as it may be.
Disclaimer: I'm a co-founder of Automatisch
Re: Show HN: We built a developer-first open-source Zapier alternative
#26Re: Show HN: We built a developer-first open-source Zapier alternative
#27That would improve discoverability as well !
Re: Show HN: We built a developer-first open-source Zapier alternative
#28Especially since a project going from one to three, and in the rare case four or five, folks is pretty common, but hitting 10 team members is a serious project milestone. At 10, you're probably also starting to look at funding. These plans are missing a tier =S
(people seem to be falling over themselves trying to read this as someone who works for a company that can afford this service complaining there should be a plan that lets them pay less for it. Instead, take a moment and remember there's an entire unpaid open source ecosystem out there, with devs who can't afford Zapier, don't have 50/mo to spend on automation for a project that gets used, sometimes by billion dollar copmanies, but no one is paying them for, and who might still want to pay for a service like this at a tier above "free". Does that mean "trigger.dev must add a tier"? no of course not, but it would be great to understand why there's nothing between free and business plan pricing)
Re: Show HN: We built a developer-first open-source Zapier alternative
#29Missed an opportunity to call it Zapiest