Rewrite back-end

[timwis]

Background

So far we've been using PostgREST as the back end. Out of the box, it gets us reading and writing, along with auth, pagination, etc., and it's fast and deployable. We've had to add stored procedures to the database for additional functionality (like adding columns). That's fine, though I imagine at a certain number of stored procedures, you might as well write your own back-end.

We'd also like to create a database schema for each user to allow multiple users in a dataface instance. PostgREST won't really support this without forking it. We'd have to rely on table name prefixes and GRANTs.

Not to mention the fact that when we do eventually want to add real-time notifications (to be notified when another user modifies the table you're looking at), we'd need to build that separately anyway.

It may just be darn time to write our own back-end.

Functionality

Copied over from #1:

Reading

• Get list of tables
• Get table definition
  • Column names, types, order
  • Column validation (ie. email)
  • For foreign keys, foreign table key and display column names
• Get table rows
  • Paginate
  • Filter rows
  • Group/aggregate rows
  • Full-text search

Writing

(Also real-time notifications if other users do these things)

• Create new table
• Rename table
• Remove table
• Create new row
  • Validate values
• Modify a row
  • Multiple columns if user copies & pastes into multiple columns
  • Validate values (ideally performed by the database)
• Remove row
• Create new column
  • It will always be created as a generic text type until type is set
• Modify column name
• Modify column type or validation
• Modify column order
• Remove column

[timwis]

Okay, I've drafted an api spec using the api blueprint language, which I popped into apiary to generate a documentation page. It uses the same method for row filtering as postgres. Hooray for documentation-driven development...now for the development part.

[timwis]

Closed by #96