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?
Show HN: I built an open-source SwiftUI app with an Airtable back end
11–20 of 47 posts
Re: Show HN: I built an open-source SwiftUI app with an Airtable back end
#12Oh 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.
Re: Show HN: I built an open-source SwiftUI app with an Airtable back end
#13I 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.
Django + DRF is pretty amazing in terms of productivity
Re: Show HN: I built an open-source SwiftUI app with an Airtable back end
#14I 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.
Was using Firebase for a small project to store non-relational Data. Switching to JSON was much more easier.
Re: Show HN: I built an open-source SwiftUI app with an Airtable back end
#15Impressive work.
Thank you
Re: Show HN: I built an open-source SwiftUI app with an Airtable back end
#16I 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.
Re: Show HN: I built an open-source SwiftUI app with an Airtable back end
#17This 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
Re: Show HN: I built an open-source SwiftUI app with an Airtable back end
#18Airtable-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.
Re: Show HN: I built an open-source SwiftUI app with an Airtable back end
#19I 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.
Re: Show HN: I built an open-source SwiftUI app with an Airtable back end
#20This 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…
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