This sounds great and very much needed! If you need a contributor, I’m interested (currently looking for a good project to get into).
Show HN: We built a developer-first open-source Zapier alternative
111–120 of 196 posts
Re: Show HN: We built a developer-first open-source Zapier alternative
#112Re: Show HN: We built a developer-first open-source Zapier alternative
#113This looks interesting. 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. Wh…
Re: Show HN: We built a developer-first open-source Zapier alternative
#114Re: Show HN: We built a developer-first open-source Zapier alternative
#115Speaking as a tech-forward "business user" who uses Zapier _a lot_: a key benefit of Zapier is that it enables business users to work independently. Moving triggers and actions behind "developer-friendly" (i.e., developer-required) tooling caps how fast an organization can move on anything outside the critical path for product and strategy. - Core transactional email flow? Great. - Alerting Slack for non-critical act…
They already address that specifically: > We found current workflow / automation tools like Zapier and n8n are good for simple tasks, but not for more advanced use cases. This isn't intended to replace Zapier for your use case. Speaking as a developer who's been asked to set up integrations before, I'm glad to see more competition in this space with a developer focus!
This is not an advanced use case to be developed in house and owned by developers. This is bread and butter marketing or product engagement email flows using anything from Mailchimp to customer.io to HubSpot.
The developer side would involve capturing the identities and events from your system and sending them (typically via something like Segment) to the downstream tools, where business users will manage those campaigns: flows, templates, content, integration with other flows, and reporting.
The next example is "Sync GitHub issues to Linear". Again, this is a fairly simple Zapier use case, probably using built-in integrations, or falling back to Python if needed. Zapier would store the credentials to both security and use a trigger/action flow.
I can see trigger.dev being more useful for things like:
- Schedule-based tasks, or super high-volume tasks. (These are expensive on platforms)
- That are driven primarily by code, not pre-built integrations
- Using private data (such as authorization tokens) you don't want to expose in plain text
Given there is undoubtedly a market of developers who want to bring things back into their standard codebase and code release practices, I suggest targeting the examples to situations to those more typically owned by developers.
Re: Show HN: We built a developer-first open-source Zapier alternative
#116I was recently looking for a simpler alternative to Temporal ( https://temporal.io/ ) so this could be ideal. If you could add instructions for self-hosting it (_sounds_ like you just need an Express server, but I would guess some backend persistent store/database/queue too) that would be great. The Webhook catalog only lists Github: I think integrating with Stripe would be neat. Like, when someone pays an invoice, S…
We do this at windmill https://github.com/windmill-labs/windmill , including self-hosting instructions and pre-made integrations with stripe
Re: Show HN: We built a developer-first open-source Zapier alternative
#117Good luck with the release - nice to see you adding features like keys, sleeps, etc.
Re: Show HN: We built a developer-first open-source Zapier alternative
#118Just reiterating what a lot of other folks have said in this thread already, but this scratches a pretty real itch for some stuff we (and our customers) have been thinking about at Mux. Zapier (and similar) is just a little too high level for a lot of our needs, but Temporal feels like overkill. Extremely excited to play around, congrats on the launch!
Re: Show HN: We built a developer-first open-source Zapier alternative
#119Earlier quoted context omitted.
Zapier has a python / JS code step (basically a AWS lambda) you can use to do something like this. Downside is that it has a timeout of 10s
Huh cool thanks I didn’t know that! I guess it’s just another action and not something “native” to Zapier (so if you want to later connect it to some off-the-shelf action you can’t).
Re: Show HN: We built a developer-first open-source Zapier alternative
#120This looks great, congrats on the launch! I am interested in a platform that bundles many pre-built integrations to various services that I could wire up through code and execute on my customers' behalf. Essentially, a way for me to present my customers with a plethora of integrations out of the box without having to build them all myself. This seems like it's moving in that direction and I saw another comment where…
This is an itch I'm waiting for someone to scratch