This is awesome. It's very similar to something I've been wanting to make just for my own personal use, but better. Is the source currently available, I'd love to mess around.
Don't apologize for using a theme for your landing page. And don't apologize to a competitor who is throwing shade and linking to their competing product.
In all honesty, don't. Seriously, this is bad advice. Nobody is going to visit your website and say "woah, this looks like Attio's website - I'm out!" with, evidently, the exception of a few folks from Attio. The website looks good, you and the other company aren't truly direct competitors so branding conflicts are not much of a concern, and if you both truly just derived your designs from a root common theme then I don't know why this is even being brought up here, unless the other commenters were unaware that their design was derived from a template. There are undoubtedly things significantly more worth spending time on as a very early startup then redesigning your website to appease a few people on HN, who were (assuming the common template bit is true) in the wrong for raising this issue to begin with and and should be updating their comment with this context.
EDIT - apologies, the OP here is not from Attio which was my assumption and would've made the OP's post unnecessary but an understandable reflex to seeing a doppelganger of their own website. If you check the OP's profile to see which company they're _actually_ from you will certainly realize that this entire comment chain should be fully ignored. It's pretty shitty, actually.
I think I was pretty open in my comment (cofounder).
They copied Attio's SVG image and everything. My issue was not the aesthetics but the fact they copied another organization's work. Surely, you don't think that's right?
Are you serious, man? You edited your comment, twice. We both know your comment did not include "(cofounder)", but did include unnecessary jabs at your your competitor ("this makes me lose all faith in our credibility.") when you posted it. I've used Budibase and think it's a great product, and couldn't have anything but respect for the people behind it. You're above this.
EDIT - Apologies, you did indeed include "(cofounder)" in your original post, I just missed it (based on bing's cached page.) Regardless, this is not the way to deal with competitors, and frankly your product speaks for itself. And perhaps obscene amounts of torrenting in my teenage years has permanently skewed my moral compass for these things, but I really don't care about table cell background svg theft.
I think the answer is no but just to be sure: are you able to trigger step executions programmatically from within a step, even if you can't await their results?
Related, but separately: can you trigger a variable number of task executions from one step? If the answer to the previous question is yes then it would of course be trivial; if not, I'm wondering if you could i.e. have a task act as a generator and yield values, or just return a list, and have each individual item get passed off to its own execution of the next task(s) in the DAG.
For example some of the examples involve a load_docs step, but all loaded docs seem to be passed to the next step execution in the DAG together, unless I'm just misunderstanding something. How could we tweak such an example to have a separate task execution per document loaded? The benefits of durable execution and being able to resume an intensive workflow without repeating work is lessened if you can't naturally/easily control the size of the unit of work for task executions.
You can execute a new workflow programmatically, for example see [1]. So people have triggered, for example, 50 child workflows from a parent step. As you've identified the difficult part there is the "collect" or "gathering" step, we've had people hack around that by waiting for all the steps from a second workflow (and falling back to the list events method to get status), but this isn't an approach I'd recommend and it's not well documented. And there's no circuit breaker.
> I'm wondering if you could i.e. have a task act as a generator and yield values, or just return a list, and have each individual item get passed off to its own execution of the next task(s) in the DAG.
Yeah, we were having a conversation yesterday about this - there's probably a simple decorator we could add so that if a step returns an array, and a child step is dependent on that parent step, it fans out if a `fanout` key is set. If we can avoid unstructured trace diagrams in favor of a nice DAG-style workflow execution we'd prefer to support that.
The other thing we've started on is propagating a single "flow id" to each child workflow so we can provide the same visualization/tracing that we provide in each workflow execution. This is similar to AWS X-rays.
As I mentioned we're working on the durable workflow model, and we'll find a way to make child workflows durable in the same way activities (and child workflows) are durable on Temporal.
reply