An investor in Airtable aftermarket products asked me …
“Is there a feature or process where solution builders can work together on schema changes and be informed of each other’s changes? There must be some good methodologies for scaling a tech team using Airtable.”
He’s so cute; he assumes " methodologies " must be available. He doesn’t know Airtable well.
Here’s my assessment, but I’m curious about what y’all do to mitigate the risks of concurrent schema editing, which can ultimately lead to catastrophic solution failures.
As I see it, there are three ways a design team can shit the bed:
Table Data - (ex: modification of the actual information of a table where that table is integral to the design of the application)
Table Fields - (ex: modification to field names that represent dependencies in the solution)
Table Metadata - (ex: changing a table name that is dependent on the solution)
Luckily, all three of these events can be caught and notified upon.
Unluckily, there are no webhooks into the Airtable UI such that we could prevent two users from editing the same schema concurrently and in separate ways. Furthermore, there’s no easy way to inform designer (a) that designer (b) has modified common table structure (c).
One remedy is to use a common push notifications approach that runs in the browser (like this one). Since Airtable designers are in the browser, we need only create a common toaster popup-like feature to keep the design team aware of changes as they happen.
Similar (even redundant) automated processes could be handled in Google Chat or Slack, thus providing the team with heads-up messages when changes have actually occurred. The Airtable events notification architecture is fast, and messaging is equally fast, so this could be implemented as a truly real-time watchdog to mitigate risk.
But even with this communications layer, there remain possible changes to schemas that impact dependencies which may not be obvious. That part requires a diligent change management process that uses the Schema API to create exception reports when dependencies are impacted.
It is possible, but non-trivial, to blend real-time notifications against the backdrop of automated processes that perform relatively fast impact assessments, which would do far more than notify designers that something important has been modified. Indeed, the popups could say what has changed and where this change impacts the entire solution.
Thoughts? Remedies? Best practices for defending solutions from those flash-bang grenades that light up your support lines?