mattaitken

11 ms·

1.
by mattaitken 6mo ago
This is cool. I think for our use case this wouldn’t work. We’re dealing with billions of rows for some tenants. We’re about to introduce alerts where users can write their own TRQL queries and then define alerts from them. Which requires e
2.
by mattaitken 6mo ago
ClickHouse is a high performance OLAP database. It’s good for analytics and search. We use it (I’m the author or the article) so users can search every run they do and graph all sorts of metrics.
3.
by mattaitken 6mo ago
Yes it’s exactly this. There’s not a neat permission boundary when you have users, orgs, projects, environments. Let alone when you add RBAC too.
4.
by mattaitken 6mo ago
You’re right RLS can go a long way here. With complex RBAC rules it can get tricky though. The main advantages of a DSL are you can expose a nicer interface to users (table names, columns, virtual columns, automatic joins, query optimizatio
5.
by mattaitken 6mo ago
In a system with organizations, projects and advanced user access permissions having separate databases doesn’t full solve the problem. You still need access control inside each tenanted database. It also makes cross-cutting queries impossi
6.
by mattaitken 6mo ago
Yes, you can actually do this already because we expose a REST API and TypeScript SDK functions to execute the queries.
7.
by mattaitken 4y ago
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
8.
by mattaitken 4y ago
Really sorry about this – we are working on a guide and it will be released soon.
9.
by mattaitken 4y ago
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 buildi
10.
by mattaitken 4y ago
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 p
11.
by mattaitken 4y ago
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 ex
12.
by mattaitken 4y ago
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.
13.
by mattaitken 4y ago
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.
14.
by mattaitken 4y ago
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 s
15.
by mattaitken 4y ago
We are using Nango (formerly called Pizzly) for our OAuth integrations. It's a fantastic way of making it easier to do OAuth!
16.
by mattaitken 4y ago
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.
17.
by mattaitken 4y ago
Ugh that sucks, sorry. We love the name but the only thing holding us back was the association with guns.
18.
by mattaitken 4y ago
"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
19.
by mattaitken 4y ago
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 var