31–40 of 63 posts
Could I use this to embed inside my app to allow my customers create integrations flows to other products, from my app ?
Earlier quoted context omitted.
The development began two months ago and we have not encountered any scaling issues yet, as the majority of users self-host. Therefore, our priority was focused on building apps. Is there anything you believe we should consider? You are correct, repeating the same index twice is a mistake. Thanks for hinting at that We are using nano id ( https://www.npmjs.com/package/nanoid ) for all entities, It's stored as varchar…
> nano id There are pros and cons to using random IDs as a PK. For RDBMS clustering on the PK (InnoDB), it's a terrible idea. If you're going to sort by the PK, it's usually a terrible idea (UUIDv1 isn't as bad since it includes the timestamp, but that assumes your access pattern is based on insertion time). There is ULID [0] if you'd like something that's sortable. You could also just have a secondary index. An adva…
In which use cases you want to sort by PK? Isn't sorting by fields like created_at sufficient?
Very cool and congrats on the launch! Love the MIT license as well. Can you talk about some of the differences with n8n except for the license?
Considering that another open source alternative [0][1] was posted just a few days ago, how does this compare? [0] https://news.ycombinator.com/item?id=34610686 [1] https://trigger.dev/
Earlier quoted context omitted.
> nano id There are pros and cons to using random IDs as a PK. For RDBMS clustering on the PK (InnoDB), it's a terrible idea. If you're going to sort by the PK, it's usually a terrible idea (UUIDv1 isn't as bad since it includes the timestamp, but that assumes your access pattern is based on insertion time). There is ULID [0] if you'd like something that's sortable. You could also just have a secondary index. An adva…
> There are pros and cons to using random IDs as a PK. For RDBMS clustering on the PK (InnoDB), it's a terrible idea. If you're going to sort by the PK, it's usually a terrible idea (UUIDv1 isn't as bad since it includes the timestamp, but that assumes your access pattern is based on insertion time). In which use cases you want to sort by PK? Isn't sorting by fields like created_at sufficient?
Related, PG15 has an improved sort algorithm for some data types. Most integers, timestamps, and a few others. So the column type could matter here.
Earlier quoted context omitted.
I believe trigger is more focused on devs while this is more focused on others
Yes, this! Trigger.dev lives in your code, we offer a visual flow builder, more like Zapier.
As a zapier alternativ this looks great. Congratulations with the launch and good luck. A lot of things is happening in this space now.
Congrats on the launch! Huge TAM so there’s lots of room for a healthy ecosystem of competitors in no code low code. My suggestions for succeeding in this ecosystem: * The value is in the long tail. Major services will integrate with other major services on their own. Make it easy to integrate with the smaller services. * Enterprise features is where the rev is at, you want to be able to get into Corp customers who a…
I've considered sourcing open API specs, like APIsguru.com, to scan for changes, but I was wondering if you have any other suggestions.
Congrats on the launch! Huge TAM so there’s lots of room for a healthy ecosystem of competitors in no code low code. My suggestions for succeeding in this ecosystem: * The value is in the long tail. Major services will integrate with other major services on their own. Make it easy to integrate with the smaller services. * Enterprise features is where the rev is at, you want to be able to get into Corp customers who a…
Are there any programmatic methods to detect integration breakages? Simply relying on unit/integration testing with mock endpoint is not effective, as it cannot capture changes made by third parties. Being notified of breakages is a solution, but not the most ideal one. I've considered sourcing open API specs, like APIsguru.com, to scan for changes, but I was wondering if you have any other suggestions.
1. Exception handling. Whatever code you have polling API endpoints or processing inbound webhooks is likely to throw an exception if the structure of the API it's consuming or inbound webhook message formats have changed materially. I recommend handling via Sentry or a similar application error reporting mechanism for triage by your SRE or platform team.
2. API responses. There is some peril here, as every API is different. Some APIs will behave as you'd expect with respect to error codes, error messages, and request allowances, while some APIs will reply with code 200 with the error message in the body. Again, this is the value incumbents offer; they know what failure looks like for each API, and they also have a good idea of what success and health looks like at steady state. Build relationships with API partners (do you have a partner team? you eventually should) so that you have open comms with them with regards to breaking changes, and code defensively in general. Tangentially, ensure you have robust logic around deduplication of polling data.
3. User reporting. If your unit tests didn't catch something, nor did your application error mechanisms, your users will absolutely let you know if a piece of JSON element landed where it shouldn't have in a target integration.
I'd encourage you to ask around to others in this space, as their recent knowledge will be more relevant for avoiding sharp edges. Also, once you've built whatever you're building, you'll be able to (or, at least, you should if you've approached this from a systems thinking perspective and wrapped the necessary telemetry and observation tools around the machine) observe at scale what optimal and suboptimal looks like.
Very cool and congrats on the launch! Love the MIT license as well. Can you talk about some of the differences with n8n except for the license?
We have a cloud auth service, that even if you self-host us, you have the option to automatically connect your account with our predefine OAuth 2.0 app which makes the experience seamless if you don't want to take care of auth. We found that this is a very important feature to simplify the UX!