We think Zapier is a fantastic product and we've used it ourselves many times. But it's more focused on simpler use cases and we found ourselves hitting the wall and then being frustrated that there wasn't a good alternative that could live in our code.
You can use JavaScript and will have a great experience – all of our code is in TypeScript which means you get a really nice experience as either a JS or TS developer.
We're using the open core model that Gitlab use. It's popular because it mean 95% of the code is MIT (good for everyone) and a small number of enterprise features are under a different license. This puts off bad actors from building a commercial competitor with zero effort. The alternative we considered was AGPL but that felt worse for our open source users.
All the code that has been pushed so far is under MIT and we currently have no enterprise features (/ee folders). The majority of future code will fall into this same bracket.
Some features that are for "enterprise" will be put in /ee folders – ideally we will put all of that in a single /ee folder in the root but we wanted to cover the case where that's non-trivial to implement.
This open core model (that Gitlab use) is popular because it strikes a nice balance between having an open source project (good for everyone) and it puts off bad actors from building a commercial competitor with zero effort.
First off, thanks for this feedback – it makes it clear that we need to do a better job.
We're following the GitLab open core model. Our licensing is the same as their's (and many other open core companies).
This means that all existing code and the vast majority of future code will be under the MIT license. At some point, we will add some enterprise features that are in /ee folders and they will be licensed differently. This is to protect us against a competitor taking the code and launching an alternative hosted service without any effort on their part. We felt that this was a friendlier option than going with something like AGPL.
Sorry that our self-hosting guide isn't available yet, we will get it up really soon. We want people to use Trigger.dev and that includes self-hosting.
There are lots of open core companies that have a cloud version and the ability to self-host. I don't think that our business model conflicts with being open source – anyone contributing will make the experience better for everyone (cloud or self-hosted).
Hopefully this answers your questions and helps to alleviate your worries about the project. We are big believers in open source and have thought hard about how we can create something valuable for everyone.
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.
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.
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!
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.
Oh, no. The other extreme wasn’t Step Functions. It was AWS Lambdas stringed together through DynamoDB Streams, SQS, SNS and S3 triggers, all obscurely tied together in a murky single-file yaml template deployed by JAWS (now the serverless framework, which has definitely made some much-appreciated improvements).
But something
- offering a clear visualisation
- and allowing to simply integrate with third-party APIs
- without having to deal with some’s quite obscure documentation
while at the same time
- easy to monitor & debug
- offering versioning
- allowing to just write a few lines instead of going through pointy-clicky drag-and-droppy mess
Yes, that was lacking. Reminds me of Zenaton (https://zenaton.com/). I can only wish you to be more successful than they were.
You can use JavaScript and will have a great experience – all of our code is in TypeScript which means you get a really nice experience as either a JS or TS developer.