|
|
|
|
|
by rubenfiszel
1108 days ago
|
|
Founder of windmill.dev here, airplane is not backed by YC but the founder is an alumni. Aside from the obvious open-source aspect, here is one notable difference.
We explicitly do not provide an integrated DB but offer simply a K/V store api, and recommend to use some dedicated services for persistence storage like supabase/neon.tech/aurora/s3: https://docs.windmill.dev/docs/core_concepts/persistent_stor.... We do not believe we can build both the fastest workflow engine at scale and the best DB so we leave the last bit to others. From what I can see, the assumption of the userbase look a bit difference. Although we have a hub (hub.windmill.dev) where users can share premade actions, we focus on script/code in typescript/python/go/bash as the unit for workflows. From there, we focus on building workflows with most of the same primitive as temporal (suspend/resume also called reactivity, error handlers, retry, etc, and some others like caching of step results) and running arbitrary code on your own infra and being able to use your full nodes without overhead. The code for the steps can also be developed locally and deployed from your github repo. Last we have a retool-like + react app capability which seems to be out-of-scope. So to summarize, although you can use windmill to do backend prototyping or as your product backend given that we generate per script/workflow webhooks, we focus on workflows with code and internal tools with enterprise scale requirements such as complex permission per-user/groups. |
|