Interestingly, we (Fieldbook) used handsontable for a long time, but eventually found it wasn't performant enough for the size of data we had (also we just needed to be able to do more customization than we could wrangle out of it)
We definitely intend to be in this for the long haul! We will always let your data out of Fieldbook, we already support CSV downloads of any sheet or view, and we are thinking about a wide variety of export and sync options to other services / data formats.
I understand being leary of business model changes. While we can't make any guarantees in the wild world of startups, we can say that we want a free tier to remain forever, and would give plenty of warning if it were ever to change. A little more information available here: http://docs.fieldbook.com/docs/security-and-privacy
We don't currently have any short term plans for a self-hosted version.
Yep! Definitely. We don't (yet) show cursors and who is connected like google docs does, but you do see changes replicated to all windows / users in real time. You can even see your own real-time changes from API calls in realtime while looking at your book.
Unfortunately we don't yet have that particular feature... But we definitely want to do something like that in the future. What are you thinking you'd use it for (we love to collect information like that for when we do implement the feature).
Obviously, using the API you could build a restricted interface on top of fieldbook, but that probably isn't what your looking for, I understand :).
We're also considering doing a mode where you can't change any of the metadata (sheets/fields) but can add/remove/change rows.
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.
What about offering a whitelabel product where I am the account owner and can spin up an independent database for each of my clients with their own login credentials while I still have master access to each?
I would literally sign up tonight and deploy this next week to my restaurant clients who want the ability to update their food menus at will and in complicated ways. Static site front end with a live menu API and Excel-style interface for them to edit in? That's the perfect solution for what these kinds of clients want/need.
* 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).
While it's nice that you have your own spreadsheet interface, how hard would it be to hook Excel in as a front end?
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.
Thanks! At some point I think we'll have an integration that allows data syncing to and/or from a spreadsheet like this.
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.
I've been shocked at the number of enterprises with workflows involving shared Excel docs (particularly in the eCommerce space). One of my (Magento) community members has a business which seems to tackle some of the issues around this: https://www.cobby.io/
I disagree strongly with an interdependence on Excel. Instead, it would make sense to ask what new functionality could be added - and start by looking at major applications of databases (you might be surprised to hear that scalibility and reliability are much more important than most think - and almost always beat other features for adoption by paying business customers). The Excel UI is a boat-anchor to innovation in the space (no reliability/scalibility or modern architecture). The Web is the new de-facto GUI, and it should be possible to start adding functionality that Excel would be hard-pressed to replicate.
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.
Hi, sheetsu.com creator here. If you are looking for an Excel as DB for your front-end give it a try. Paste link to your Google Spreadsheet and then you get an URL to the API. You can CRUD your Spreadsheet using that API.
Excel-as-a-front-end hooks in so nicely and easily to SQL Server Standard via standard ODBC/ConnectionStrings. You get audit tables, integration with Active Directory, SSRS, concurrent modifications, the ability to dynamically perform queries (i.e. [1], if you enable a filter clause on your projection from one of those DropDownLists, it will send it out to SQL Server and then return the resultset), audit trails, permissions, and most importantly you can set all of those NON NULL, FK, restraints at the database level, and use SQL Server Reporting Studio (comes with Standard) to perform your reporting. Priced out per CPU you can get it for under 10k. I've done it legally for free too[3] in my early years, but if your client won't pay 10k for a RDBMS, you've got a tire-kicker who won't respect net/90 much less net/30. I've done literally dozens of times for every type of industry you can imagine and I can count on my left hand the number of times those clients needed to later supplement their infrastructure with an actual data-warehouse. (Also the newer Excel versions allow data constraints to a certain degree, so you can avoid that unnecessary transaction/lock acquisition in an anticipatory fashion.) Combine SSAS/SSRS, and the free downloads of PowerPivot and PowerBI and you have a _very_ robust, flexible system that can handle millions of rows easily.
I've done it one of two ways - via VBA and via VSTO Add-ins. My VBA version has been carefully crafted to emulate a pseudo-ORM based off INFORMATION_SCHEMA and all, making it pretty portable. It works fairly well because what usually ends up happening is say Partner Foo will have his read-write to his schema and it will all be segmented up via catalog views and other rules. There are the standard concurrency issues (you have to discuss with your client whether you want him to take a mutex on the result set, or potentially allow stale data) so it's fairly naive in that regard. The upside of it it's all self-contained (i.e., not a pile) and portable because you effectively get "reflection" with any sufficiently decent RDBMS impl. Maybe 10-15% of that VBA has to be tweaked based on their business requirements (defining behavior like if pri_row gets deleted in table foo by user bar, do you offer a prompt to cascade delete[1]?)
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.
Thanks, I agree with him on that point! We've developed the conceptual model and the UI for Fieldbook through hundreds of usability tests with users from a variety of roles and backgrounds. The model we have has been tuned to match how people naturally think of working with data and how they can best understand it.
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.
Just a FYI, with uBlock on (mostly default settings except for a few specific sites of which yours isn't one) I couldn't sign up at all, the field for entering the email address just wasn't showing at all.
As most others have said, it looks great! Looking forward to playing more with it
This looks great! I've been on the hunt for a good CMS-as-a-service and have been a bit disappointed by the current options. Does fieldbook handle image uploads? Any other caveats for using this as a full-blown CMS?
We love using Fieldbook for CMS use cases. We think the public API coupled with public posts is a great fit for the API, too.
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 :)
The paid tier right now offers a couple of things, mainly focused on business administration. In particular, the ability to manage accounts in your organization (remove access once someone has left the company for instance) and priority support.
We want you to use Fieldbook as your database, so we don't limit the number of api calls or books you can have in Fieldbook! (we hate when you run up against an artificial limit and have to scramble to get your product back online). :)
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.
Glad to hear you folks are looking at scaling. I love the idea, and for small stuff the app so far is great. My book with around 2500 rows and 20 columns I find to be significantly slower than I prefer, though. Unclear how much of that is backend versus frontend, but definitely a limiting factor for my use right now. In an ideal world it would feel as snappy as Google Sheets.
Definitely hear you! We are working on some performance improvements right now, if you contact us in app, we might be able to figure out what is happening with your data. 2500 rows and 20 columns should still be snappy!
Any plans to support triggers & email notifications? I consult for several small businesses and this could be a quick & low budget alternative to the bigger SAAS' out there for HR, CRM & Asset Tracking.
Sorry it didn't make sense. Definitely something we need to iterate more on. If you want some specific help, we are definitely happy to provide us. We have an intercom/message us chat system that we love to help users with.
Thanks! We've tried to do a bunch of iteration on user experience, obviously more to do. Fast iteration and unit/automated tests have been key to being able to build this product.
Greetings fellow devs! I'm the CTO of Fieldbook, happy to talk about anything. We use a node backend stack, with mongodb, and a backbone based front end. We use socketio for realtime and rabbit for some back end messaging.
I'm also one of the authors of RecordStream which has been discussed on here before (https://github.com/benbernard/RecordStream). I see Fieldbook as an extension of RecordStream but for the web instead of JSON records on the command line.
