[joshma]

(Appreciate the feedback! We clearly need to continue to improve how we explain the product. :))

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).

[0] https://docs.airplane.dev/getting-started/views

[1] https://docs.airplane.dev/self-hosting/agents

[ayewo]

I thought I understood what you do but with your itemized example, I'm somewhat confused.

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.

[raviparikh]

To add on to what Josh said, the main value of Airplane is that we automate a lot of things that would normally require you to write a lot more additional code. So for example, if you build an admin panel using Airplane instead of doing so from scratch, we'll provide the following for you:

* 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.

[sjcoles]

Part of what bothers me with the current webdev approach is irreducible complexity.

How many layers of 'magic' to facilitate devs deploying do we really need and is it wise to depend on so many?

[joshma]

2 - correct, depending on the task type we still call through to node etc. But the CLI also provides a dev UI and other niceties specific to 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!

[yawnxyz]

Airplane is so cool!

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..

[Gormo]

So it's an an alternative to e.g. AWS lambdas or GCP cloud functions?