And, of course, this allows you to break things, a hallmark of a great development process. This helps reduce the likelihood that an end user will change data as you build. This means the data type of these fields is a black box, sort of like the any type in TypeScript.Īs a #protip to deal with Airtable's data flexibility, I highly recommend developing on a "staging" copy of the Airtable base you are working with. If it is summing numbers, then its result is a number. This makes sense given how Airtable works: if a formula is concatenating text, then its result is a string. However, two of these data types - lookups and formulas - can take the form of any other type. Most of these data types are familiar and predictable. Airtable is highly valuable because of this flexibility, but it also makes developing on Airtable a bit more unpredictable.Īdditionally, as a data store, Airtable supports all sorts of data types. Tables, columns, and field types can emerge, change, or disappear at anytime. This easy-to-use interface means the database schema is super flexible. It's worth touching on Airtable's data model.įrom a developer's perspective, Airtable is basically a hosted database fused to an easy interface for creating and managing data. When building in Airtable, you will face a couple constraints when working with 3rd party APIs, caching data, or manipulating the UI. ![]() Lastly, as your considering whether to build in or on Airtable, consider the functionality you need. The new name is slowly catching on but you'll still see the term blocks pop up here and there. Note: Airtable Apps were formerly known as Airtable Blocks. Meanwhile, scripts and custom apps are only available on pro and enterprise plans. Automations are available on every plan, but capped at different limits. The REST API is available on every plan to every Airtable user. In these use cases, you'll be using the Airtable REST API directly or using a tool like the one I helped build - Sequin.Īs you decide whether to build in on on Airtable, you should consider what Airtable plan your users are on as well. This might be a custom internal tool, a dashboard built in Google Data Studio, a public Next.js website, or inside another SaaS application all together. If you are building on Airtable, then you are building for users outside of Airtable. But by and large, the end user is in Airtable. Note: Yes, I know, automations can trigger actions outside of Airtable. For any code you want to run in Airtable you'll be using either scripts, automations, or the custom app SDK. When you are building in Airtable, the user is logged into Airtable and using your software within the Airtable interface. in Airtable) or outside Airtable in another app or tool (i.e. ![]() Who is your user and what do they need? This age-old question is still the first one to ask as you begin to consider which Airtable developer tools to use.Īt a high-level, you can classify Airtable's suite of developer tools as either supporting use cases that happen inside the Airtable interface (i.e. Read Part 1: Scripts, App SDK, REST API, Sequin □.The Complete Developer's Guide to Airtable (3 Part Series) This guide aims to help developers navigate Airtable and build great applications on this growing platform. In the span of a year, Airtable went from a simple REST API to now supporting scripting, a custom apps SDK, built in automations, and a small but growing ecosystem of third-party tools and services.Īs a developer looking to build on Airtable, where should you start? And what is the developer experience like? You might have missed the memo: Airtable is ready for developers. It's like having row-level access to your data in stripe_prod. We sync data from third-party APIs like Airtable and Stripe right to your Postgres database in real-time. We're Sequin and we help developers skip API integrations.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |