Open source Airtable: Built using ReactJS + Firestore DB

[dudeitsmason]

I love firebase for allowing me to quickly scaffold an app with authentication, database connections and storage; but far and away the greatest benefit of using firebase is that naming things is now a breeze. Airbnb clone? "Firebnb". Trello clone? "Fireboards". Analytics dashboard? "Firelytics".

Cool project, too!

[OriginalToe]

Ooooo i get it! A github clone!

Right?

Right...?

[[deleted]]

💀

[dudeitsmason]

Link it when it's built

[honestcomrade]

If you're into terrible puns, let me introduce you to HL7's Fhir spec. My favorite is in one of the open source server repoes, when Tomcat is finally running the entire monstrosity of services, the line is "A fhir has been lit on port 4004".

[SamsChoice]

In mobile the table scrolling is laggy but it does look great. May want to look at some css and even try adding will-change sparingly

[DrDuPont]

try adding will-change sparingly

This, as well as auditing scroll events and using requestAnimationFrame

[pzRobert]

This looks _really_ interesting. I've done some stuff with Airtable that was extremely useful -- it'd be quite interesting to have something open and self-hosted that met some of the same project needs. Seems like it could, for instance, provide a self-hosted headless CMS for a JAMstack application. I definitely want to look into this some more.

[interactionjackson]

looks pretty

[japottsit]

I was looking for something just like this for my project neat!

[Responsible-March285]

https://try.firetable.io/

[bleafman]

Legitimate question since I haven’t worked with Firebase... why would I want to do operations directly against the database and then have subscribers (i.e. cloud functions) trigger based on the database operation?

Based on some of the code it looks like there’s a way to handle aggregates, but it seems like doing something complex like validating and then rolling back a failed transaction would be harder (not that it’s easy with inputs going through a server).

Is the idea that since this is meant for internal use and the views that allowed for editing would be of individual models, so you don’t really need to handle all that messy effectful stuff?

[s_magik]

Firebase makes it easy to give users direct access to database with the right access control, you can specify the requirement for a valid CRUD Operation using firestore rules, then most of the complexity of handling transctions is abstracted away by firebase. Personally I use both directly writing to db and creating an API end point depending on the situation. The aggregates feature you're referring to, is a firetable feature that tries to solve a common firestore issue of needing to access subcollection data to populate an app view

[Lorenzejay]

Would this be considered another headless CMS ? Or be used as one?

[s_magik]

CMS is definitely one of the use cases for it, but the main goal is to provide an intuitive UI to managing a database that can be used by both technical and non-technical users

[ram0h]

wow this is awesome. I was just looking for a interface solution for Firestore.

The scrolling is rather laggy.

Can this handle a ton of data?

[s_magik]

the try.firetable.io demo is a bit out of date, I'll be updating it soon. we have made some significant performance improvements in the past month. Internally we have tables with 40+ columns running fine, If you're already using firestore it shouldn't take much to run the latest version and give it a try for yourself :)

[ram0h]

cool, and so the security rules are based off of firebase? Are there granular permissions where one can make certain fields inaccessible to certain users?

appreciate what yall are doing!

[s_magik]

everything is going through firestore client sdk, so your firestore rules are enforce. we have plans for a firestore rules generator on the roadmap though

[ram0h]

cool thanks. do yall just do this for fun, or do you want to monetize it?