I'm the CTO of Fieldbook, we're really proud of what we've built here. In particular, I really like our API explorer that allows you to run real node code right in the browser to explore our API. (And see our realtime updates in action on the same page). That feature is powered by Tonic (https://tonicdev.com)
Its mad fast to setup a database with a REST api with Fieldbook, and we'd love to hear what you think / what could be better / etc.
* Create a template book for yourself * For each client, make a copy for them and share it with them so they can edit it in Fieldbook * Read from each book via the API for the live app
It's not whitelabel, but it would give you an independent database (book) for each client, they would each have their own login credentials (to Fieldbook), and you would have access to each (in the UI and in the API).
I deal with large enterprises primarily and I've been looking for a nice relational backend for Excel for years.
So breaking out the roles of a consumer vs. a creator, I would like end users to consume without knowing that there is a different backend to the Excel sheet they are using while still freeing up the creator to do what is needed on the backend.
For example, we have extremely complex pricing spreadsheets that we use to estimate projects, it would be fantastic to be able to collate and manipulate data on the backend as well as data sources while being able to tell an end user to keep using Excel as the front end as before.
Maybe this is a fit, maybe it isn't but any insight/feedback would be welcome. Thanks.
The spreadsheet isn't ideal as the primary UI for a number of reasons. That's why we built our own UI, inspired by spreadsheets but fundamentally breaking from the model to be more like a relational database.
But a spreadsheet connection could be great for reporting, modeling scenarios, etc. – basically, all the things that spreadsheets are actually good for.
Might be worth having a chat with him.
[1]https://www.ablebits.com/_img-blog/find-duplicates-excel/sel... [2] https://www.microsoft.com/en-us/server-cloud/products/sql-se... [3] SQL Server Express + the Express version of the Business Intelligence Suite was free for production use up to 4 GB and 2(?) processors [things might have changed since then, SQL Server 2008]. A few hundred lines of SP's to dump stale data out and the client was golden.
In some situations [such as a cascade delete], the business requirements need the Stakeholder or PM or TL or whomever to authorize certain events due to internal corporate governance policies. At that point, the VSTO add-in route is taken because usually there has to be integration with other governance/workflow software (one of the subsidiaries for Blue Cross/Blue Shield I worked with was notoriously bad re: pushing the buck and over-complicating workflows). Anyways, the MSVS sln I use with that is pretty much the opposite of a VBA pile.
[1] There's almost never any destructive DELETE's taken, rather a boolean active flag is toggled, and a new row is inserted with a more recent timestamp so you can '...order by timestamp desc limit 1'. That way if auditors come in, not only do they have the full audit log but we can reconstruct state at any given time.
Either way, a naive VBA implementation that doesn't appeal to system tables for all the schema info can easily be written (in a maintainable fashion, as maintainable as VBA goes at least) in under a week.
This is the most detailed explanation I found regarding the VBA method: http://www.toadworld.com/platforms/sql-server/w/wiki/10392.e...
And the company you linked originally gives away a generic VSTO add-in: https://www.ablebits.com/excel-addins.php#sql-server
The part I was missing was when you said 'audit tables [and] audit trails' (etc.)... it sounds like this would all be build-it-yourself.
I should add that I was once a Product Manager for core database at Oracle. We had constant requests for an Excel front-end to Oracle. I don't know if we had any major customers who didn't ask for a spreadsheet front-end at some point. But we were busy making money on other things, and it just wasn't a priority (though consulting routinely built hooks.) So I think that this has the potential to be a huge product - especially if it can leverage new technology in ways which Excel can't. Don't let Excel and Microsoft drag this product down.
More info here - https://sheetsu.com/docs/beta
Apparently so far he thinks that data structure you have in your app is most approachable for non-programmers:
I can imagine using this as a way to get users to build simple prototypes. They can chuck data at it for a few weeks, then hand the data off to developers to build a first cut of a web app. If said developers could easily click a button and get a gzipped SQL file compatible with, say, Postgres, that'd be a really useful feature.
We don't handle image uploads yet. Definitely something we want to support in the future. Of course, you can put urls in the cells and build things that way... Definitely something we want to improve in the future :)
We don't scale as far as we want to right now. For a good experience, we're limited to about 10k rows in a book. Definitely something we want to improve a LOT in the future.
More info here: http://docs.fieldbook.com/docs/data-size-limits