Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: I built an open-source SwiftUI app with an Airtable back end (github.com)
108 points by kine 56 days ago | hide | past | web | favorite | 45 comments

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.

From TFA:

> 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

I've always wondered why there's no HTTP tunneling for misc RDBMS protocols. For example, a MIME-Type for MS SQL Server Tabular Data Stream (TDS).

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.

[0]: https://climatescape.org/ [1]: https://github.com/climatescape/climatescape.org

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.

If you want more: https://linkedin.com/in/zackshapiro

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.

I still don't see why he said "real developer" and not "developer"

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!

bit of a hack

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.

Perhaps you should look into Forest Admin? (for the GUI) They have a free open-source tool.

Never got to use it because I'm mainly running on DynamoDB, but heard lots of good things about it

I didn't know about this tool. Looks pretty nice. Thanks for sharing.

P.S: Saving a Google search for people who come across this thread: https://www.forestadmin.com/

100%. I love Firebase's speed but digging into the data and modifying it through their console is a total pain.

Their console is a pain, and some of other aspects too.

Remember getting an error because a document was getting updated too fast (four or five times in less than a second).

Heck, their own documentation states a document can only be updated about once (1) per second[0]

[0]: https://firebase.google.com/docs/firestore/solutions/counter...

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.

Django + DRF is pretty amazing in terms of productivity

Was using Firebase for a small project to store non-relational Data. Switching to JSON was much more easier.

What does Airtable give you over gsheets for you? I use gsheets but I am interested.

I see a lot of people talking about SQL or Airtable. But there's a third middle ground here - Graphql based headless CMS.

For example Graphcms, Prismic, etc. You get the standardization of Graphql (which means no lock-in) and pretty much as powerful as SQL really.

You also get the admin/dashboardy/WYSIWYG aspects of a CMS - https://prismic.io/feature/custom-type-builder

Very easy integration - https://medium.com/better-programming/graphql-combine-and-sw...

(of course this works just as well on Android, React Native/Web,etc)

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.

What does Airtable give you over gsheets for you? I use gsheets but I am interested.

The primary feature is true table-to-table relationships that mimic an RDMS.

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.

Very interesting. Current Swift capabilities make this extremely easy to implement in an iOS app.

You might wanna consider FaunaDB if you want to make the backend a bit more database-like but still serverless.

Their GraphQL API is neat.

I think the main advantage of Airtable is the GUI, does faunadb have anything like that?

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.

This is really cool! I’ll definitely take a look at this and maybe fork it when we get onto looking at native apps.

We have built a web app (https://stacker.app) for people who want to use an Airtable backend.

Hi davyson - is Staker responsive on mobile?

Nice! I'll check Stacker out!

Just an FYI, if anyone doesn't realize, any images or files you upload to Airtable, aren't protected in any way, if you happen to get the URL.

It's been like this for years, and recently confirmed it's still the case.

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.

I run my life on an Airtable GTD framework. I'd totally skin a iOS build to improve on the experience.

Nice work!

I've been exploring using AirTable as a potential back-end for read-sometimes/write-rarely data.

Thanks! It's fun and definitely useful as long as you're not trying to us it as Redis ;)

What is Airtable? Seems like something that should’ve been mentioned.

Impressive work.

Thank you

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact