rosszurowski/micro-airtable-api

Quickly make an API from Airtable

micro-airtable-api's Issues

Demo API

Show what it looks like

Allow read-only APIs

By default, with the API key users get full write access. This is fine if you want a read-write API, but if you're looking to use Airtable as a CMS/DB, you'll likely want something read-only.

Allow specifying a column name mapping

It's nicer to access fields.sourceUrl rather than fields['Source Url'].

Hide fields in responses

One thing I've thought about implementing is a restriction on which fields can be seen by users.

For example, I have a table that has a column that's for my personal notes on each item, and I'd prefer not to have those personal notes publicly available.

I've thought about doing this by hijacking the fields option and basically removing any fields that clients request that are blacklisted.

This probably gets outside of our core library and into "nice-to-have" territory, but I figured I would file it for discussion anyway.

Add solution for rate limits

Airtable mentions in the docs that it limits API calls:

The API is limited to 5 requests per second. If you exceed this rate, you will receive a 429 status code and will need to wait 30 seconds before subsequent requests will succeed.

If you need a higher request rate, they suggest either using retry logic or a caching proxy.

I think it'd be easy enough to add a caching layer, especially seeing simple implementations like the micro-open-graph use of memory-cache. Maybe just cache results for 30 seconds by default, configurable via env variable?

Unit/integration tests?

I'd like to add some unit and/or integration tests to this project. For unit tests, I'm thinking I'll use Jest, unless you have another preference?

For integration tests, I think we'd need a shared Airtable base that any contributors could request access to. Is this something you've looked into or would be interested in doing? Otherwise, we could start with unit tests as they're more isolated.

Split out CLI and JS code

I wanted to make an issue to capture discussion about splitting this repo up into a core CLI library and a JS API as mentioned here: #9

It sounds like we want to build a core CLI library that can be used by the micro-airtable-api project so that there aren't breaking changes is the project. My thought would be an NPM package?

The big decisions that need to be made are around what belongs in the core CLI library and what features belong in the JS API. I'm going to make a PR just to demo a simple example, but this is all very lo-fi right now.

Don't redirect to https://airtable.com/api on server root

For a custom API, we probably want an error or warning thrown. How could it be more visible to the developer? Let's see what other REST APIs do?

Allow specific combinations of routes and methods

One thing I'd like to add is the ability to limit requests to specific combinations of routes and methods.

For example, I have a base with one table that is read-only and another table that is publicly writeable, but not editable.

I'm happy to work on a PR for this, but I don't know how easy it will be to accomplish without breaking some of the existing configs. Any thoughts?

Integration tests

Based on the nature of this library, we feel that integration tests would be a better fit than trying to unit test each small function in the handler.js file (read more: #16 (comment))

So, a couple questions:

• Should our integration tests connect to a real Airtable instance? If so, what's the best way to test authentication without giving away the API key?
• Or, should integration tests mock calls to the Airtable API?
• Or some combination of both of the above depending on the test?

Logging option

Another feature I'd like to help with is adding a configuration option to allow stdout/stderr logging. It helps me identify improper use by frontend clients, and is handy for analytics purposes so I can see where the most load is.

I'm thinking of adding a LOGGING=true option to the env options to enable it and using debug to implement it.

Feedback is welcome.