[HN Gopher] Show HN: We built a developer-first open-source Zapi...
___________________________________________________________________
Show HN: We built a developer-first open-source Zapier alternative
For the past few months we've been building Trigger.dev and can now
share our beta with you:
https://github.com/triggerdotdev/trigger.dev. Trigger.dev is an
open source platform that makes it easy for developers to create
event-driven background tasks directly in their code. You write
workflows using our SDK, and can view all the runs in our web app.
Why we built this: - We found current workflow / automation tools
like Zapier and n8n are good for simple tasks, but not for more
advanced use cases. - Dropping down into code in these tools is
just not a great experience. We prefer using our own IDEs, version
control, and having access to GitHub Copilot etc. - Sometimes, a
workflow requires us to query a database or handle some sensitive
information. It would be great if this data wasn't sent to a third
party. Our beta version lets you: - Trigger workflows from
webhooks, custom events or schedules (CRON) - Use API integrations
with Slack, GitHub, Shopify and Resend. We're adding more of these
each week. - Add delays of up to 1 year. Workflows will resume
where they left off, even if your server has gone down. - Support
for Fetch and subscribing to generic webhooks. - Observe every
workflow run in the app (great for debugging). - Open source MIT
license so anyone can self-host the platform. We're still early so
would love your feedback and opinions. Feel free to try us out for
free - and if you want a specific API integrated, just let us know.
Main website: https://trigger.dev Github:
https://github.com/triggerdotdev/trigger.dev
Author : eallam
Score : 428 points
Date : 2023-02-01 14:15 UTC (8 hours ago)
(HTM) web link (trigger.dev)
(TXT) w3m dump (trigger.dev)
| cube2222 wrote:
| Looking at the long delays, do I understand correctly that this
| is something similar to Temporal[0] or AWS Step Functions?
|
| My first sentiment was "when I'm already writing code, why not
| just use Lambda", but it looks like these delays are kind of the
| selling feature, and it looks like the UX is better than step
| functions.
|
| I'd be curious about your selling points over Temporal, as I
| can't seem to find any comparison.
|
| Good luck!
|
| [0]: https://temporal.io
| eallam wrote:
| 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!
| ElFitz wrote:
| > 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.
|
| Anyway, the point is: thanks for making this.
| rangledangle wrote:
| 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.
| mattaitken wrote:
| 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.
| debarshri wrote:
| For people who are building durable workflows. You should
| definitely checkout temporal [1]. It is production ready, you can
| implement pretty much same using the original SDK of the
| underline services.
|
| [1] https://temporal.io/
| revskill wrote:
| This is complicated with too many terminologies :(
| verdverm wrote:
| Their pricing model is much preferred:
| https://temporal.io/cloud
|
| i.e. pay for what resources you use instead of how many users
| you have. This is how we pay for AWS/GCP/Azure. I think a lot
| of dev SaaS could / should go this way.
| johtso wrote:
| Unfortunately there's currently a steep mandatory support
| charge of $200 a month, which makes it unviable for smaller
| operations. I think they're planning to offer the service
| without the support aspect, which would be fantastic and I'd
| be first in line for..
| vpol wrote:
| And if you don't store much inside the workflows themselves -
| it's quite cheap even if you have hundreds of thousands
| invocations.
| verdverm wrote:
| 1M invocations looks like $25, which is really cheap
| vpol wrote:
| Not sure why everyone says it's too complex, maybe people get
| scared by the word idempotence.
| eallam wrote:
| I forgot to mention in the original post we've built a bunch of
| example workflows here:
| https://github.com/triggerdotdev/trigger.dev-examples
| e28eta wrote:
| 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.
| d-k-p wrote:
| We have a few examples with descriptions in the docs here:
| https://docs.trigger.dev/examples/examples
|
| The example repo eallam shared has more though, we will be
| moving all of them to the docs soon!
| sigstoat wrote:
| i 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.
| farukaydin wrote:
| There is an open source Zapier alternative
| (https://automatisch.io) even though it's not a desktop app.
|
| Disclaimer: I'm a co-founder of Automatisch
| rubenfiszel wrote:
| We do not provide a desktop app, but we provide the FaaS and
| instructions to self-host wherever:
| https://github.com/windmill-labs/windmill
| mmcclure wrote:
| Just 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!
| d-k-p wrote:
| Thank you, really appreciate that comment. That's the bracket
| we see ourselves in, and for the same reasons (as product
| builders).
| tonyhb wrote:
| Looks like you signed up to us last year at
| https://www.inngest.com and took... a lot of inspiration!
|
| Good luck with the release - nice to see you adding features like
| keys, sleeps, etc.
| mattaitken wrote:
| Hey, Inngest looks impressive, congrats! We're tackling similar
| problems. Our actual inspiration to build this was Interval
| back in November. They make it easy to create internal
| dashboards inside your own codebase by using their SDK. We
| wanted to offer the same great developer experience but for
| creating workflows.
| yewenjie wrote:
| How does this compare to Pipedream and Windmill, both of which
| are also open-source?
| rubenfiszel wrote:
| Founder of Windmill here, and d-k-p answer is spot-on. If you
| want to manage your entire workflows as a typescript code, then
| trigger.dev would be preferable. Windmill supports typescript,
| python, go and bash, and handle all the advanced features such
| as retries, approval steps, pre-made integrations to hundreds
| of API at the workflow level in a UI-based editor. Then for the
| steps, themselves. you would use either your IDE and sync to
| Windmill, or use our web IDE.
| d-k-p wrote:
| In Trigger.dev workflows are created completely in your code
| rather than in a node-based UI (which to be fair does allow you
| to write code sometimes). We found developers could actually
| put together workflows faster if the whole thing was code
| rather than a hybrid of UI / code (because you get to use your
| own IDE + Copilot).
| cssanchez wrote:
| This sounds great and very much needed! If you need a
| contributor, I'm interested (currently looking for a good project
| to get into).
| eallam wrote:
| Contributions welcome! Hop in our Discord and we can chat:
| https://discord.gg/nkqV9xBYWy
| bambam24 wrote:
| [dead]
| kats wrote:
| Hey just giving you guys feedback. The emojis are really an
| issue. NocoDB has this issue as well. If I want to use this at
| work it's a lot harder sell because of the emojis and statements
| like "it's blazing fast!!"
|
| If you want it to be more adopted, at least for my job, it has to
| look super straight and serious, and give the impression that
| it's secure (which doesn't necessarily mean writing "we're
| secure!") Like copying the style of Microsoft Office would be the
| best. Google Docs or Zoho would be ok too. Of course it's great
| that you got through YCombinator and pitched, etc. But giving the
| impression of "Woo! We're a startup!" makes it seem like the
| company may be gone soon.
|
| To sell to a more generic established business, it might be
| better to look like a company that has been around and isn't
| going anywhere. Like for Microsoft Office, the assumption is that
| it's secure and your data never leaves your PC. They don't have
| to say that.
| runnr_az wrote:
| Missed an opportunity to call it Zapiest
| robertlagrant wrote:
| NotIfThisThenThatButUs
| ethbr0 wrote:
| TryThisCatchThat
| wizzwizz4 wrote:
| That would probably get them in trademark troubles.
| eallam wrote:
| Where were you 2 months ago!
| vladsanchez wrote:
| LOL Good one indeed!
| neogodless wrote:
| Keeping their Zapier wit to themself.
| CSMastermind wrote:
| I've spoken to many IT professionals over the years that have
| been frustrated with BetterCloud.
|
| I've just been waiting for someone to launch BestCloud as a
| competitor.
| qup wrote:
| Maybe BestCloud was the OG, usurped by BetterCloud.
| moltar wrote:
| I've been waiting for this for years. Love!
| cpursley wrote:
| Neat! This seems like it work be great paired with a low/no-code
| backend like Hasura or Supabase.
| paul1664 wrote:
| 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]
| mattaitken wrote:
| We are using Nango (formerly called Pizzly) for our OAuth
| integrations. It's a fantastic way of making it easier to do
| OAuth!
| [deleted]
| jonny_eh wrote:
| Are 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?
| eallam wrote:
| 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.
| jonny_eh wrote:
| 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?
| mattaitken wrote:
| 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!
| nirga wrote:
| 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.
| rubenfiszel wrote:
| Trigger.dev looks like amazing if you want a simplified
| temporal that is still 100% code based and exclusively in
| Typescript. If you are looking for a Zapier-for-developer
| experience, we took an alternative route at Windmill of
| allowing Python/Javascript/Go/Bash as steps but the workflows
| are still GUI based: https://github.com/windmill-
| labs/windmill/blob/main/imgs/win...
|
| Despite them being GUI based, you can do everything that
| temporal enable, approval steps/suspending workflows until
| being reactivated by a webhook, branching, etc, etc... It's
| 100% open-source and self-hostable.
| mike31fr wrote:
| You should try make.com. It is great!
| eightysixfour wrote:
| n8n is also great about this. It retains the visual "easy mode"
| environment but lets you drop in a JavaScript node whenever you
| need to do something more complex
| Jiger104 wrote:
| 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
| nirga wrote:
| 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).
| robbiemitchell wrote:
| You can connect code steps to other actions. For example,
| every Python code step has a reserved `output` variable
| which allows you to pass a list out to the next steps. It
| gets passed as stringified JSON: if it contains dicts,
| those values are made available automatically as inputs to
| other steps. You can also pass more complex, nested JSON
| and just json.loads it later.
| justin_oaks wrote:
| I have the same thoughts. I tried node-red and I got frustrated
| having to do all this drag and drop stuff for something I could
| code easily.
| rsstack wrote:
| Would love this self-hosted.
|
| The license says "All content that resides under any "ee/"
| directory of this repository, if such directories exists, are
| licensed under the license defined in "ee/LICENSE".", but there's
| no folder named ee? What is this referring to?
| eallam wrote:
| 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 :)
| danielvaughn wrote:
| 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.
| eallam wrote:
| 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
| mfrye0 wrote:
| This looks great. I'll have to play around with it.
|
| Related, we built a developer oriented Zapier clone for event
| scale automations awhile back for our internal product. We've
| since pivoted and have been debating on potentially open sourcing
| the engine as well.
|
| We built ours using Rust with a DSL for all the triggers,
| actions, and action inputs/outputs. The actions themselves are
| defined as APIs, which makes it easy to add functionality in any
| language. Most of our actions have been built in Typescript.
|
| Is there interest from anyone in potentially using it?
| ZephyrBlu wrote:
| Would love it if there was an email list I can subscribe to so I
| can keep up to date with development. I don't have a use for
| Trigger right now, but it seems like a cool tool that I want to
| keep up with.
| patchorang wrote:
| Why are there so many "Zapier alternatives"?
| dreadlordbone wrote:
| Zapier's UI is a hot mess. If you breathe on a zap it turns
| off. Default names for zaps are "Untitled Zap". Pricing is very
| high for any sort of serious traffic. The webapp runs very
| slow.
|
| But most important, no one knows how to say "Zapier". Is it
| ZAHpier or ZAYpier?
| sgarland wrote:
| Rhymes with happier.
| justin_oaks wrote:
| Then it should have been spelled Zappier.
| debarshri wrote:
| Zapier's UI might be a hot mess but their revenues indicate
| that the people are will to go with it and use it as is.
|
| All the points you mention, can be fixed by zapier. Then the
| alternatives do have a moat.
| debarshri wrote:
| Because Zapier is an established business and showcases that
| there is market for automation tools. It is a safe bet to make
| by creating an alternative.
|
| What people are missing is the fact that executing a GTM the
| way zapier did is more that just building the product and is
| actually very hard.
| Moto7451 wrote:
| My experience is that for some types of integrations you see
| about a 70% success rate. Eventually you need something that is
| more reliable. Maybe you need an all in one solution that has
| some ETL capabilities. Maybe it's a cost thing.
|
| Zapier seems to be the best way to get stuff done quickly and
| cheaply but not the best for long term high volume use as an
| integration platform. At my old job we migrated a from Zapier
| to Integrator.io, which fixed the reliability issues but broke
| the low barrier to entry.
| Benjamin_Dobell wrote:
| This 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. 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.
| eallam wrote:
| 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!
| vhanda wrote:
| 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
| 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/
|
| [4] - https://docs.dagger.io/1215/what-is-cue/
| rubenfiszel wrote:
| We support both typescript and python at windmill [1]. But our
| model is doing low-code for the workflows, and actual
| scripts/code for the steps themselves so it's quite different
| than trigger.dev. We handle OAuth, refresh tokens and secrets
| being managed by the platform. It's quite different from
| trigger.dev considering they are doing workflows entirely in
| code which has some pro and cons.
|
| [1]: https://github.com/windmill-labs/windmill
| mattaitken wrote:
| 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 server you can use environment variables (or your
| preferred alternative) to inject secure values.
|
| 2. When a workflow step that requires OAuth is hit, the
| workflow pauses and prompts you to sign in. After you've signed
| in the workflow continues where it left off. You only need to
| connect each service once per organization. You can sign
| optionally in multiple times to the same service and switch
| connections where needed, e.g. multiple separate Slack
| workspaces.
|
| GitHub star to Twitter follow is a great idea. You could
| achieve that right now by using our GitHub integration and our
| fetch call (which auto-retries with exponential back off and
| logging in the dashboard). We'll add a Twitter integration soon
| so this is really easy and publish it as an example :)
|
| 3. We have detailed error messages attached to the step that
| failed but don't currently have a way to hook into this like
| you describe. This is a great idea, I've added it to our task
| list.
|
| 4. Exactly right, each "step" is a block in the UI with clear
| inputs and outputs. We would really like to have a graph view.
| That'll be especially useful when you put loops in the code,
| and of course branching.
|
| 5. 100%, making this work well with AI code generation would be
| great.
|
| 6. This is a great idea, we'll investigate. Rather than just
| mapping 1:1 with an SDK we're trying to make the experience
| better. For example, with the normal Slack API you can't post
| to a channel name, you have to use an id. We make it so you can
| use the name and we deal with the hassle for you.
|
| 7. We'll look into this too. Integrations for interoperability
| could make this easier.
|
| 8. We're going to follow the GitLab/PostHog model. Like GitLab,
| the repository as a whole is MIT licensed but we can add some
| /ee folders in the future with enterprise features. We feel it
| gives us the right balance of being open source and gives us
| some protection from a competitor hijacking the project.
|
| 9. We will separate out the dashboard from the runners - this
| was a compromise so we could ship the first version faster.
|
| 10. We can relatively easily ship other languages SDKs and
| Python is probably where we'd start. Our core backend code will
| most likely remain in TypeScript.
|
| Thanks again for so much feedback!
| johtso wrote:
| "4. Exactly right, each "step" is a block in the UI with
| clear inputs and outputs. We would really like to have a
| graph view. That'll be especially useful when you put loops
| in the code, and of course branching."
|
| 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.
| r3trohack3r wrote:
| If you're looking for competitors in your space, it's worth
| checking out Autocode too: https://autocode.com
|
| They have a full in-browser editor that handles many-to-many API
| integrations with autocomplete and helpers. They also have a CLI
| that lets you work with your favorite editors.
| ArcaneMoose wrote:
| This 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 you mentioned
| workflow execution on customers' behalf in the future which is
| great!
|
| How does this compare to something like Prefect?
|
| If there are any other tools folks would suggest to achieve what
| I'm looking for, I'd love to hear about them!
| ashrafsam wrote:
| We do this at Activepieces (activepieces.com).
| ArcaneMoose wrote:
| Is there an API or SDK for creating/managing flows? I want
| the flexibility to programmatically wire these integrations
| together rather than a nocode UI
|
| Additionally, this seems to rely on you inputting your
| credentials. How would that work for a usecase where my
| customers are the ones who provide the credentials?
| udkl wrote:
| > 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 is an itch I'm waiting for someone to scratch
| rubenfiszel wrote:
| We also do this at windmill: https://github.com/windmill-
| labs/windmill
| UncleSam wrote:
| 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.
| imachine1980_ wrote:
| I'm not see the site blacklisted, I'm outside of usa btw, but
| inability asume is probably internal policy
| Meph504 wrote:
| Would be willing to bet your connection has an over aggressive
| blocking system going on
| mattaitken wrote:
| Ugh that sucks, sorry. We love the name but the only thing
| holding us back was the association with guns.
| robbiemitchell wrote:
| Speaking 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 activities elsewhere? Ehh...
| aliqot wrote:
| and suddenly at least one of us realizes why zapier costs
| money. the cycle continues.
| carrja99 wrote:
| Comes up all the time. There was another tool like this
| (huggin?).
|
| I think what often gets missed and what gives zapier great
| power is the developer platform that can let devs build
| anything! I have a lot of custom integrations with apps that
| support use cases that afaik only I have. It is incredible
| effective.
| eddieroger wrote:
| I had a lot of bots in Huginn, but the amount of tending
| that the garden required versus and the developer
| experience were never good enough that I kept them going. I
| found myself doing all the JS editing I needed in VSCode
| and coping it back and forth, which is a bad experience. It
| definitely saved my butt a few times over the last few
| years, but I am anxious and excited to swap it out for
| this.
| bluehatbrit wrote:
| Did you mean Huginn? (https://github.com/huginn/huginn)
| lolinder wrote:
| 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!
| robbiemitchell wrote:
| The first example on the homepage is "Create an email drip
| feed campaign in under 2 minutes"
|
| 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.
| mattaitken wrote:
| Thanks, this is great feedback. You're right that these
| examples don't highlight the real advantage of our platform
| vs no-code tools. We're going to add some new examples to
| our site based on what our customers are building.
|
| The three categories of problems you identified that are
| best solved with a code tool are what we're seeing with our
| early customers. Plus a lot of notification use cases like
| when developers want to be notified in Slack when something
| important/bad happens.
| bradgessler wrote:
| It's not hard to imagine a template library or code generator
| that sits on top of this code layer that's more approachable to
| non-technical users.
|
| If done well, that would be an advantage over Zapier since a
| non-technical user can start something basic, then have a dev
| look at it if they need to get more sophisticated.
|
| This is what has made Excel and Access so successful--a biz
| person can get it started and have something tangible to hand
| off to a dev.
| eallam wrote:
| Zapier is great for non-developers, and as developers we've
| even used Zapier in the past because in some simple cases it's
| actually easier and more reliable than writing the code
| yourself! It's not easy to write code that connects even just a
| few services together, and handles transient errors and server
| interruptions, usually it takes some kind of infrastructure and
| maintenance, and can no longer be written in the normal way
| (and good luck with delays!).
|
| We wanted to bring the convenience of Zapier (you describe the
| request you want to do, they figure out how to do it!) back
| into our codebases, without having to manage a bunch of
| infrastructure (that's where trigger.dev comes in).
|
| While we were at it we built this as a general purpose event-
| driven system, complete with AWS Event Bridge like event
| pattern filtering, and also added the ability to listen for
| webhooks reliably without having to use a tunnel to your local
| machine when testing locally.
| michaelmior wrote:
| > It's not easy to write code that connects even just a few
| services together, and handles transient errors and server
| interruptions, usually it takes some kind of infrastructure
| and maintenance, and can no longer be written in the normal
| way (and good luck with delays!).
|
| Based on the example shown, it looks like Trigger.dev handles
| all this while allowing you to write code pretty close to
| what I would call "in the normal way." I haven't tried it
| myself, but if the examples work as advertised, it looks
| pretty attractive to me.
| gsanderson wrote:
| I 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, Stripe calls a
| webhook. That could trigger an action.
| mattaitken wrote:
| "A simpler alternative to Temporal" is a good description for
| us. We'll get a self-hosting guide up soon for you. We're
| adding integrations that people ask for as fast as we can build
| them and Stripe is high on that list :)
| rubenfiszel wrote:
| We do this at windmill https://github.com/windmill-
| labs/windmill, including self-hosting instructions and pre-made
| integrations with stripe
| gsanderson wrote:
| Ah, ok. Thanks. I'll take a look at that too.
| sisve wrote:
| Does windmill have any way of going into code, without it
| basically becoming "code in a input box". The developer first
| solution trigger.dev have here is really scratching a real
| problem. But as they say they are not for the easiest
| workflows. I'm really looking for something that is gui first
| but as a drop down to code when you want. But inline code
| editor, let me save it to a git repo or similar. And don't
| have globals aka zapiers inputData and output.
| rubenfiszel wrote:
| > I'm really looking for something that is gui first but as
| a drop down to code when you want. But inline code editor,
| let me save it to a git repo or similar.
|
| That's like, exactly what we are, take a look at this
| screenshot for instance: https://github.com/windmill-
| labs/windmill/blob/main/imgs/win...
|
| As for syncing code to git, we do it as well through our
| CLI and Github Actions: https://github.com/windmill-
| labs/windmill-sync-example
| [deleted]
| gpuhacker wrote:
| I'm very unfamiliar with this family of tools, but if anyone
| knows a tool like this that can monitor arxiv or Google scholar
| for new papers matching a particular query, I'm very interested.
| I checked Zapier recently but I didn't see these among the
| support apps.
| stevekrouse wrote:
| This is definitely something you could build in
| https://val.town. Someone made a little daily query that checks
| for new citations on a particular paper:
|
| https://www.val.town/ernest.newCitationNotification
|
| I'm the founder of val.town, so email me if you'd like help
| setting this up. I'd be more than happy to pair program with
| you on it. My email is steve @ val.town
| daveguy wrote:
| In Google Scholar, after your search there will be a button at
| the end of the page (on mobile, maybe somewhere else on
| desktop). The button is "Create alert" with an email icon by
| it. Select this and there will be a form for where to send the
| alert and the query. Click "Create alert" to get automatically
| notified of new results.
| Fiahil wrote:
| For once, I'd love to have a nice UI around this so I don't need
| to search docs and write code for simple stuff like "await
| ctx.waitFor({ hours: 3 });".
|
| That would improve discoverability as well !
| elonmusk11 wrote:
| [flagged]
| elonmusk11 wrote:
| [flagged]
| ryan_jiang wrote:
| +1 to this problem space. Resonate a lot with the gaps with
| Zapier, particularly around the need for escape
| hatches/conditional logic when needed--one of the reasons we
| built Retool Workflows! https://retool.com/products/workflows/
| TheRealPomax wrote:
| Jumping from free to $50/mo feels like there's a 4.99/9.99 plan
| missing somewhere. Just because you have 3 people on your team
| doesn't mean you can casually spare $50 a month, that's a lot of
| money to the vast majority =(
|
| Especially 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)
| phphphphp wrote:
| You work for a billion dollar company, are you speaking from
| your perspective as a software engineer or... something else?
| Price sensitivity as an individual is understandable but when
| you're talking about a team I struggle to understand why
| there's a meaningful difference between $5 and $50. For a
| business, if software is valuable enough to use, it's valuable
| enough to spend $50 on. Plus, $50 is below the threshold most
| businesses have for discretionary purchases.
|
| I'd implore the OP not to get distracted by this sort of
| feedback: any serious business user will be more than happy to
| spend $50/month on a service like this. Trying to cater to
| people who are this price sensitive is a recipe for an
| unprofitable nightmare.
| TheRealPomax wrote:
| Maybe, and this might be confusing, folks didn't always work
| where they do today, and have experiences based on "I don't
| have money but I work on a project with 5 others that the
| world seems to use a ton, but no one's paying for". "A team"
| and "a business" are not the same. Running a business? Pay
| for team tier. Open source project that just has more than 2
| people organized in a team? I'll let you think of that one.
|
| And of course, "it's open source, just install it on your own
| host" is a perfectly valid response, but "you have money,
| what are you complaining about" is maybe a _little_
| ridiculous given that people can voice concerns for an entire
| class of folks, not just themselves. $50 is a lot of money
| for a lot of folks in open source.
| phphphphp wrote:
| The situation you're describing is exceptionally niche and
| one in which you can simply reach out to the company and
| ask for accommodation: there's thousands of open-source
| projects sponsored by for-profit companies by granting
| access to paid services for free (your employer is one of
| them, Fastly sponsor a bunch of projects by giving free
| CDN).
|
| Asking a company to sell their services to everyone at a
| huge loss because a minority of open-source projects can't
| afford their service is more ridiculous.
| TheRealPomax wrote:
| It's literally the situation I was in before so: why are
| you trying so hard to gaslight what is a perfectly valid
| question? They probably have a good reasons for there not
| to be a middle tier: if so, cool, but it feels missing so
| hopefully they read HN comments and can explain why the
| first paid plan jumps straight to $50.
| phphphphp wrote:
| A challenge many startups face is undervaluing their
| service. You started out by saying that their service was
| too expensive -- "that's a lot of money to the vast
| majority =(" -- which is the sort of complaint that
| induces founders to think they need to lower their
| prices. They don't. Most startups should be charging
| more. $50 is nothing to the customers that Trigger want
| to attract in order to succeed.
|
| I have no beef with your point about open-source
| developers having very limited budgets, but it's very
| important to contextual your feedback. You specifically
| talked about teams of multiple people, it was unclear you
| intended to describe a very niche situation.
| TheRealPomax wrote:
| Thanks for the clarification. I took your comment as a
| personal assault from the phrasing, accusing me of being
| a hypocrite because I happen to draw a paycheque these
| days. Thank you for explaining that wasn't the intention.
| armatav wrote:
| Honestly it just sounds like you don't need it that bad
| TheRealPomax wrote:
| What a weird reaction to someone voicing the question that
| open source devs will have, for a project that literally says
| it's dev-first.
| armatav wrote:
| Not really - three teammates and the issue is paying $50 a
| month?
| HatchedLake721 wrote:
| ^ this here is the reason why I never want to build SaaS
| products for developers.
|
| If you use and benefit from a product that saves time for 3
| (usually the most highest paid) employees in the business
| (developers), you either need re-evaluate how much value this
| product provides or re-evaluate your business plan.
| TheRealPomax wrote:
| Professionals drawing a paycheque, or folks working on a
| product? Sure. Open Source that no one pays for even if the
| users inclulde multimillion dollar companies because "it's
| open source, why should we pay anything"? No.
| angio wrote:
| You have to account that not everyone is working in the US.
| For someone earning 15k$ per year, 600$ is not little money.
| cpursley wrote:
| Please tell me where I can hire developers for $15k per
| year.
| kab0b wrote:
| Good/Fast/Cheap. You only get one.
| simonw wrote:
| The problem with $10/month plans is that replying to a single
| support email relating to them can swallow your margin for the
| month and result in a net loss on that customer.
|
| You have to sell SO many of those plans for them to become
| worthwhile.
|
| It's a lot easier to sell 100 $50 accounts than it is to sell
| 500 $10 accounts, and you end up with customers that are more
| likely to increase to even higher tiers in the future.
| TheRealPomax wrote:
| While true, the free tier already comes with email support
| [1] so I'm not sure a $10/mo tier would have any impact in
| that respect?
|
| [1] https://trigger.dev/pricing
| collyw wrote:
| Nice, Zapier is a pretty interesting solution but the pricing
| model is not.
| revskill wrote:
| Please make curl example on how to send custom event , instead of
| using nodejs sdk ?
| justin_oaks wrote:
| Yes, the best API documentation includes curl examples
| regardless of any other examples.
|
| With SDK examples you have to set up a code project, install
| the SDK, add some boilerplate code, make the API call, and
| figure out out to display/use the output. Ugh.
|
| With curl examples you can run the example with no set up, just
| a little customization. You just run a single command. Easy-
| peasy.
___________________________________________________________________
(page generated 2023-02-01 23:00 UTC)