I'm having a hard time figuring out what this is and what it does. Is it sort of a modern Visual Basic with lots of data source connectors?
It's probably easiest to explain in terms of what a developer does on Airplane:
1. Dev writes code (e.g. see our Getting Started for views[0]) - this can be simple Python scripts, JS views, shell scripts, etc.
2. Dev uses the `airplane` CLI locally to run and test the code
3. Dev runs `airplane deploy` or pushes to GitHub to deploy the code to Airplane
4. Dev's teammate (or dev) can now visit app.airplane.dev to run the code (views, tasks, runbooks) - the execution defaults to Airplane's servers, but you can also use our self-hosted agents[1] to move the execution (data plane) to your own cloud environment.
It's similar to GitHub actions in architecture (but for a different domain).
1. OK
2. Dev uses the `airplane` CLI as opposed to running `npm`, `python` etc locally?
3. Dev runs `airplane deploy` as opposed to deploying to Heroku?
I think it would be nicer for us if you explained your value proposition in terms of what tools/steps I'd be replacing if I choose to adopt Airplane.
3 - correct, the code is built and pushed to us, similar to Heroku.
Our value prop ultimately is that 1) you can build tools like admin dashboards, data migration scripts, one off devops operations, etc, into production grade web apps and 2) you can do this using code!
* A rich React component library that's optimized for internal tooling (tables, charts, etc) * Permissions, audit logs, and approval flows that are easily configurable * Integrations into various systems that an internal tool would normally have to integrate with (e.g. identity providers like Okta, Slack for notifications, etc)
So if you'd expect building that admin panel to take a few days or weeks of work, ideally with Airplane we can reduce that down to a few hours instead.
How many layers of 'magic' to facilitate devs deploying do we really need and is it wise to depend on so many?
Is there a way to trigger the tasks via webhooks?
E.g. I'm using a signup flow w/ Airtable to check off / approve new sign ups. Person signs up, we see the profile, sometimes fix some details, and move it into the official Airtable of profiles — but would love to use Airplane instead since I'm trying to move off of Airtable for these sorts of things and use a "real" database. Using Views and a webhooks/triggers would be nice for the future when we just want to "auto approve" or move to db and airtable in parallel, etc..