[HN Gopher] Show HN: Trigger.dev V2 - a Temporal alternative for...
___________________________________________________________________
Show HN: Trigger.dev V2 - a Temporal alternative for TypeScript
devs
Back in February, we posted a Show HN about building a "developer-
first open source Zapier alternative"
(https://news.ycombinator.com/item?id=34610686). This was v1 of
Trigger.dev. During the months since, we've gathered a lot of
feedback from early users and realized that what developers
actually wanted was more like an easier-to-use Temporal with
integrations. Here's what we've learned so far: - Serverless
timeouts make it hard for anyone to write reliable background jobs.
So our current product makes that easy for Next.js and other full-
stack React frameworks. Long-running server support is coming soon.
- We simplified the architecture to make it far easier to self-
host. This was the most common comment in our previous Show HN. -
We made it much easier to contribute to. You can now add new API
integrations for any service we don't already support. Either
publicly (we appreciate PRs) or privately in your existing
codebase. We're open about what we're building
(https://trigger.dev/changelog) and what we're planning on doing
next (https://trigger.dev#roadmap) as we believe community feedback
ensures that we're solving real problems. So here's where we're
at, and where we're headed: [x] Easy self-hosting.
[x] Serverless. Long-running Jobs on your serverless backend.
[x] Integration kit. Build your own integrations, or use ours.
[x] Bring-Your-Own-Auth. You can now authenticate integrations as
your users. [x] Dashboard. View every Task in every
Run. [x] Cloud service. No deployment required.
[x] React hooks. Easily update your UI with Job progress.
[x] React frameworks. Support for Next.js, Astro, Remix, Express.
[ ] More frameworks. Support for SvelteKit, Nuxt.js, Fastify,
Redwood. [ ] Background functions. Offload long or
intense tasks to our infrastructure. [ ] Long-running
servers. Use Trigger.dev from your long-running backend.
[ ] Polling Triggers. Subscribe to changes without webhooks.
[ ] And lots more... I'd love to hear your thoughts on
background jobs. Have we missed anything off the list? What should
we be building next? https://github.com/triggerdotdev/trigger.dev
Author : eallam
Score : 136 points
Date : 2023-10-03 12:07 UTC (10 hours ago)
(HTM) web link (trigger.dev)
(TXT) w3m dump (trigger.dev)
| asselinpaul wrote:
| How does it compare to inngest.com?
| tonyhb wrote:
| Chiming in as a founder of Inngest.
|
| We released our TS SDK a year ago so had quite a head start in
| this area. The approach in their V2 release makes them more
| similar to us, though there are still some large differences,
| including the fundamental architecture, queueing technology,
| scale, etc. Some differences you'll notice as a developer:
|
| - Concurrency and parallelism. We allow you to run steps in
| parallel, configure concurrency (per function, or with sub-
| groups for custom concurrency limits), and automatically fan
| jobs in, eg https://www.inngest.com/docs/functions/concurrency
| and https://www.inngest.com/docs/guides/step-parallelism.
|
| This is a pretty big point, as you often don't want to run
| functions sequentially. We're also fully event-driven, allowing
| you to pause workflows and automatically resume when specific
| events are received
| (https://www.inngest.com/docs/reference/functions/step-
| wait-f...).
|
| We also handle a lot of complexity for you that you'd have to
| build yourself:
|
| - Rate limiting
|
| - Batching, allowing one function to run from eg. 100 events,
| instead of 1:1 matching of event->function
|
| - Streaming, for long-running responses
|
| - Auto-cancellation, based off of matching events
|
| - Branch deploys for all workflows, regardless of platform
|
| - Debounce
|
| - And a bunch more such as middleware, error handlers, multi-
| language support (including zero-downtime live-migrations of
| long running workflows), fully-offline local development, etc.
|
| In general, I think we're tackling a similar problem with
| fundamentally different approaches in events and architecture.
| Trigger definitely have more in the space of integrations,
| while our approach is: send us anything, no matter the event or
| source, and we'll work with it.
|
| While I don't know the Trigger folks I'm assuming they've seen
| similar problems as us and it's fun to tackle this area, so I'm
| looking forward to seeing how they build out their platform in
| the future and this area evolves :)
| matt-aitken wrote:
| Inngest is also an easier to use version of Temporal, for
| serverless.
|
| Currently the major differences are:
|
| - Open source: we're fully open source and self-hostable with
| Apache 2 license.
|
| - API Integrations: we're building first class support for
| popular APIs. That makes it really easy to subscribe to
| webhooks, and when you do API calls you get good retrying
| behaviour, automatically dealing with rate limits, and a great
| logging experience. You can write your own integrations and
| contribute them (that would be awesome), or keep them private
| to your own codebase.
|
| - React hooks: often background jobs are related to an action a
| person has done in your app (end-user or an admin tool). We
| have hooks so you can very easily show the live status of a run
| exactly how you want.
|
| Very soon
|
| - Support for Background Functions - we deploy your code so you
| can run any length of task. You write the code like any other
| job in your codebase. Discussion here:
| https://github.com/triggerdotdev/trigger.dev/discussions/400
|
| - Support for long-running servers (so you can use if you're
| not deploying to serverless). Issue here:
| https://github.com/triggerdotdev/trigger.dev/issues/244
| madarco wrote:
| Well done for being completely open source!
|
| I'll suggest this to my employer and we'll probably choose
| the managed solution, but having the freedom to choose is a
| great bonus!
| [deleted]
| reion wrote:
| I moved from n8n to trigger.dev a month ago. Maintaining all the
| workflows in GUI was just too time consuming and difficult. I
| already use NextJS for my app, so switch to trigger.dev was easy,
| not maintaining and making changes my workflows in IDE takes
| about 80% less time. So far I am very happy with my decision to
| switch.
| nevodavid10 wrote:
| I have been using it for my new project. it's really gold,
| because I don't need to run another instance of NestJS for the
| background jobs.
| bilalq wrote:
| Would love to see an article or post from you guys on how this
| compares to AWS Step Functions.
| adamkaz wrote:
| Coming to Next.js from Laravel, being able to hand things off to
| a long running worker is one of the things I missed the most.
| We're currently handling this with a non-ideal solution and will
| definitely check Trigger.dev out when you launch that feature.
| matt-aitken wrote:
| Great, you can subscribe to updates on our discussion here:
| https://github.com/triggerdotdev/trigger.dev/discussions/400
|
| We'll be updating it as we make progress and open it up for
| early testers.
| Kalpeshbhalekar wrote:
| Super interesting tool! Glad to know you folks use SDK to write
| Jobs to avoid any deployment blockers.
| KRAKRISMOTT wrote:
| You need stronger support for state management and scheduling
| across long running tasks.
|
| This is your competitor:
|
| https://www.inngest.com/
| [deleted]
| louis-lau wrote:
| My initial thought when opening your website was that this was a
| job queue, like BullMQ. Not a "link things together like
| IFTT/Zapier/N8N but in code" platform. I don't think I'd use
| "Background Jobs framework" to describe what you're building, as
| that term has very different associations. Am I right in saying
| this is like BullMQ, except with integrations? If so, I'd focus
| more on the integration part of your marketing.
| matt-aitken wrote:
| That's really interesting. What associations do you have with
| "Background Jobs framework"?
|
| Quite a lot of our customers are using us instead of Temporal.
| Not for linking stuff together use cases.
| nsonha wrote:
| Temporal calls itself a "Durable execution platform", which I
| think emphases the persistence aspect of a message queue. I
| remember Cadence which is Temporal's predecessor called
| itself a "workflow orchestration framework". I think it's a
| better term.
| tedspare wrote:
| The hooks are great for returning multiple values/progress
| updates to the UI. I've been using it for chained and/or long
| calls to the OpenAI API.
| zubairov wrote:
| Trigger.dev is awesome, use it every day. A feature list is quite
| impressive and complete, the only thing on my wish-list is a
| `wait/resume` for long running jobs
| matt-aitken wrote:
| Thanks! Do you want the ability to call a Job from inside
| another Job and wait for the result?
|
| We have a discussion about that here, would love to get your
| input:
| https://github.com/triggerdotdev/trigger.dev/discussions/516
| mikaeln wrote:
| Really excited for this!
| knowsuchagency wrote:
| How does it compare to windmill.dev?
| matt-aitken wrote:
| Our focus is on writing jobs in your existing codebase. That
| means you use your existing development workflow (code editor,
| version control, etc) and can access your database and existing
| code easily.
|
| I'd also say that Windmill, and other similar tools like
| Airplane, are more focused on internal tools. Building internal
| admin tools and related workflows.
|
| Our users are building some internal tools but also core parts
| of their product that involve user interaction.
| rubenfiszel wrote:
| Founder of windmill here.
|
| You can, and that's the main workflow for most users, use
| your code editor and version control with windmill, and you
| can access your database and existing code easily. It works
| exactly the same way as trigger where you sync and deploy
| from your existing code repo.
|
| Inngest and trigger are event-driven workflow engines while
| windmill is a more traditional workflow engine (think modern
| airflow) where the flow/graph is defined statically in a low-
| code UI (although can be generated dynamically) while the
| steps are code-centric. We also include a UI builder (similar
| to Retool) and have an heavy focus on running on your own
| infrastructure (k8s with helm or docker-compose) and include
| complete observability for heavy jobs (streaming logs in real
| time) as well as the ability to use hardware acceleration
| since we use your raw nodes. Windmill also include workers
| management and is polyglot, You can run typescript, but also
| go, bash, and python, and write queries for bigquery,
| snowflake, and postgresql without having to wrap them in
| typescript.
|
| So I would say we are less focused on integration to external
| APIs and more focused on enterprise use cases, for critical
| and heavy background jobs that require long and complex
| workflows (for instance that may require approval steps). But
| I think you guys are also working on background jobs and I
| haven't seen it so hard to say.
|
| Good luck to you all. I think for the people that know well
| both frameworks, it would be easy to discern when windmill or
| trigger is a better fit and I agree the use-cases are
| different.
| alecfong wrote:
| I think this really hits the sweet spot. Been looking for a
| product just in this space for a while!
|
| - Types + IDE > UI/WYSIWYG
|
| - Integrations
|
| - Long running workflows
|
| - "Serverless"
| revskill wrote:
| I won't use this because of the weird way of framework
| integration.
|
| Just give pure api call, instead of forced convention on file
| system level.
|
| Because i don't use any of "popular" frameworks, that means i
| have no integration ? No.
| jusonchan81 wrote:
| You could also use Netflix Conductor which has typescript support
| and all the features listed here and more.
| corba_v2 wrote:
| +1 to this. Conductor is a far better experience.
| chrisesplin wrote:
| I've been using Firebase functions and Firebase function cron
| jobs for this purpose... but it's definitely a roll-your-own
| situation.
|
| This project could go so many different ways and solve a bunch of
| my problems.
| matt-aitken wrote:
| Part of the inspiration for this was Firebase functions. We
| used them extensively on a previous project with their
| Firestore triggers. There's a lot to like about them but it was
| a messy development experience, especially the deployment
| process (although this was a few years ago).
___________________________________________________________________
(page generated 2023-10-03 23:01 UTC)