Airtable API integration #22
Conversation
chrisdevereux
force-pushed
the
airtable
branch
from
f46fa7c
to
a96c306
Compare
|
Exciting! I'll have a look now. |
There was a problem hiding this comment.
Looks good, simple. It looks like there's no official Airtable python package, but there are a few unofficial ones. Was there a reason you didn't lean on one of those?
| resource_type=MyResource, | ||
| api_key=settings.EXAMPLE_AIRTABLE_API_KEY, | ||
| base_id=settings.EXAMPLE_AIRTABLE_BASE, | ||
| table_name="Table 1", |
There was a problem hiding this comment.
table_name could also go on the env as settings.EXAMPLE_AIRTABLE_TABLE_NAME? Appreciate that it is the default table name, but it can be changed by the user of course.
There was a problem hiding this comment.
Main reason is that it introduces another environmental variable that needs to be shifted between different environments that this needs to run in (local dev machines, ci etc). Secondary reason – we might plausably introduce an integration test for multiple tables (if we wanted to test relationships, for example) so making it explicit in the code which table is being referenced in a test is useful.
Didn't really seem like there's any point introducing a third-party dependency given that it'd just be a very slim wrapper around the REST api anyway (and Airtable has quite a simple API with good documentation). An unecessary additional moving part. Most of the general 'rest client' stuff we have in hand via our own |
Description
Adds an Airtable datasource. Adapts the existing RestDatasource to Airtable's API conventions and some conveniences for getting at a base API via its id and table name.
Motivation and Context
Closes #18
How Can It Be Tested?
Types of changes
Checklist: