Skip to content

Instantly share code, notes, and snippets.

@timwis
Last active February 8, 2019 12:12
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save timwis/05042bdd6503503ac4e8ea2affa3c172 to your computer and use it in GitHub Desktop.
Dataface

problem statement

  • enterprises will inevitably have more data being collected and maintained than their IT departments can keep up with, so business users resort to using spreadsheets or proprietary/incompatible tools.
  • hard to share or integrate this data with other systems
  • eventually the IT departments have to come in and build on top of or fix these tools (crazy formatting, having to reverse engineer the export)
  • there isn't really a great alternative
    • access: desktop software, outdated, not multi-user.
    • airtable: prioprietary, saas-only and could disappear/pivot.
    • salesforce: expensive, proprietary, easy to cross the line where it's very difficult to port (e.g. workflows, notifications).

goals

  • empower the business users of an enterprise with the ability to manage basic data in a way their IT departments support
  • should the use case outgrow our product, the IT department should be able to take the data with them to a new product, without having to export/clean-up/reverse engineer

approach

  • be as vanilla database as possible, using database features instead of custom things. application should be a light layer on top of the database.
    • e.g. ideally wouldn't even need tables for the application. just the data.
    • "should work with an existing db" is a good litmus test of this (necessary to "install"?)
  • work with the databases enterprise IT support/like
    • this means oracle and mssql :( in addition to pg
  • should work with an existing db (?)
  • should allow DB to be edited outside the application

decisions

  • what's the best way to store dataface-specific metadata for each column (e.g. the "display field" of a foreign/linked row, column order, formatting options)? Column comments, metadata table? (if the latter, how do we keep it in sync?)
  • how do we handle change notifications if DB is edited outside the application?
    • could do DB triggers, but that involves an "install"
    • could only promise change notifications if done by application
  • should email notifications, workflows, etc. be on the roadmap, or keep it strictly data editing?
  • is it reasonable to support row-level security?
    • maybe look at cross-db feature comparison
  • how should auth work?
    • database users, like postgrest/postgraphql?
    • ldap/AD/oauth?
    • auth0?
  • how should sharing work? (leveraging schemas and vanilla sharing?)
  • spreadsheet-like editing or one-record-at-a-time (djangoadmin style)?
    • if the latter, we'd have to design the form
      • store as table comment? or inside col comments
  • how do we track changes?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment