I went through something like this. I was thinking oh... airtable saves me from having to develop the crud aspects of my app! Boy was I wrong.
For super super basic stuff, Airtable is fine to code against their API. But as soon as you get into anything more complicated, you are going to get screwed.
They have a 5 concurrent connection limit and no real transactions. Want to insert 6 rows quickly across two tables? Nope. I guarantee that despite all your best effort, you will have inconsistent data. At a high level, their api is nice and simple, but that is it. It doesn't go deeper than that.
You are VASTLY better off building against a real SQL database. If you want to visualize the data in Airtable, then export it there from your SQL database.
> I wouldn't recommend using Airtable to store fast-moving data but as a means of storing strings, images, positions of views, and general data that won't get updated very often, Airtable could be a potential option for you.
Certainly, I knew what I was getting into and my application actually fell under that category. But even storing glacier data is difficult if you can't store more than 5 things a second.
At the end of the day, I knowingly made the decision to experiment with it. I learned a bunch from it. Glad I did it.
The way to use it in my experience is if you have a good data set that will be edited by non-engineers, periodically pull it into a more appropriate application database. Then you’re enabling others to manage the data but still get the performance and scalability the app needs. This will suit only certain kinds of apps, of course
This is a great concept! I'm not surprised to see you getting flak for building on Airtable, but as a "real developer" leaning heavily on low/no code lately I wanted to share how well it's worked for our open source team over the last few months.
In terms of scale, it has supported dozens of editors, hundreds of public submissions, and several thousand rows of data. We have also successfully scripted a number of use cases using the API for workflows that can be automated.
The biggest benefits from my perspective are:
1. Minimal overhead for schema changes. We have been able to overhaul our schema on more than one occasion with no intervention from developers up front. We let the content team shape the data in a way that makes sense then update our client code to fit
2. The UI is obvious to technical and non-technical users alike. Who doesn't know how to use a spreadsheet?
3. No-code workflows are trivial to prototype and launch with blocks and forms.
Is it going to work forever? No, we're already moving the more stable+dynamic tables into a SQL database. But I'm sure that we've saved dozens if not hundreds of hours of time in our frequent iterations these first few months. I'm sure we'll keep using Airtable for new features.
lol "real developer." I was the Director of Engineering for Bump, a YCW18 company. I've run mobile teams as well. I just wanted to mix two tools together, no need to hop into who's real and who's not a real developer here.
You realise that GP's "real developer" wasn't a challenge to your pride, yes? It wasn't to denigrate you or your skills, just to give context for the remainder of their own post about their own experiences — as an experienced developer using tools that may not necessarily be aimed at experienced developers.
By the context it's clearly in response to others giving OP flak. That's why he put "real developer" in quotes, as a dig at anyone who might presume a "real developer" would have no use for this kind of solution.
To make much more explicit the differentiation between traditional developers, using programming languages, and the sorts of people at which things like PowerApps, Google App Maker, or this AirTable are aimed — usually more database-y, business/data analyst types.
(Not to say developers don't use them as well, of course they do.)
Apologies if I wasn't clear, but I was trying to defend you not offend you. In my experience, a lot of people hate on Airtable for being a toy, but I've had a great experience with it. I really like what you built!
I already use Airtable as a backend for some small internal tools. It definitely does the job but there are some moments where I feel it might be easier and more flexible just to create something on Firebase. From an API perspective storing and retrieving objects in both is equally as easy.
The only reason I went with Airtable is because I needed a GUI to add data manually.
Currently migrating a data-heavy Firebase project to plain boring Django. We didn't need the realtime and offline features of Firebase and it's a massive pain to work with.
A regular SQL database and a good ORM is so much more productive. Servers have terabytes of RAM these days.
We're in the middle of a similar transition, except that we were using the realtime features of firebase (but we needed better querying).
We've found that Hasura offers us the best of both worlds. It doesn't actually store any data itself, it's "just" an API layer on top of postgres. So we can do most things with bog-standard SQL-backed REST APIs, and with a couple of clicks to set up relations and permissions in Hasura we also access any of that same data through realtime-capable GraphQL api.
Airtable-as-a-Database is absolutely delightful. It comes with an advanced admin back-end for other team members to view and manage data. For many apps, instead of starting with RDBMS tables, I consider Airtable and strategically move to an RDBMS where Airtable doesn't scale (organizationally, latency, security, row-count, etc.)
I've most recently built https://design.org using Airtable. I think it's performant and rock solid. It saved some initial development time, but the benefits have kept coming.
Oh very cool! Love the idea of using a third-party service to store data for simple projects, mobile apps included!
If anyone is looking for a similar solution, a place to dump data for personal projects, check out Pantry (https://getpantry.cloud/). It lets you store JSON and has a simple API.
I built an ERP-like application for a small production company entirely with Airtable as the backend, but wrapped in a GraphQL schema. The Airtable app fetches the schema of a base when you load it, complete with all type columns, data types, select options, lookup ids, etc. You can use that to generate a GraphQL schema and fetch the data from Airtable in your resolvers. The rate-limiting and general speed when fetching a lot of data makes it unsuited for things that need to scale, but having the excellent Airtable UI for raw data entry and a custom application for everything else (complex data entry, reporting, kpis and such) was very nice.
That said, if I were to do it again today I'd probably go with Hasura or something more suited as an actual backend.
Something I haven't seen mentioned is how great their API documentation is. Each database (AKA "base" in Airtable parlance) gets a generated set of docs that uses the actual names of the tables and fields (and the field types), as well as javascript examples that use your real data as sample output values.
This is really cool. I've used google sheets as a backend/UI for a client project once. Worked really well. People know how to use it and it scales for "most" use cases.
This is VERY useful to build a MVP FAST / TEST the market. I would love to try it for an idea I am about to test. Instead of using WP i can use this method.
For super super basic stuff, Airtable is fine to code against their API. But as soon as you get into anything more complicated, you are going to get screwed.
They have a 5 concurrent connection limit and no real transactions. Want to insert 6 rows quickly across two tables? Nope. I guarantee that despite all your best effort, you will have inconsistent data. At a high level, their api is nice and simple, but that is it. It doesn't go deeper than that.
You are VASTLY better off building against a real SQL database. If you want to visualize the data in Airtable, then export it there from your SQL database.