Skip to content

Instantly share code, notes, and snippets.

@timwis timwis/dataface.md
Last active Feb 8, 2019

Embed
What would you like to do?
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
You can’t perform that action at this time.