Air Table API 사용하여 자동화 파이프라인 구축

원래라면 Air Table에 대한 포스팅이 먼저였어야 하지만..

Air Table Api에서 더 구현해야 할 부분이 남아있어서 구현이 완료된 지금 포스팅을 남깁니다 🤤

 

Air Table

Air Table은 데이터베이스 기능이 있는 스프레드 시트이다. (Feat. WIKI)

 

여러 줄의 설명이 필요 없다. 진짜 정확히 저 의미 그대로다.

 

사진을 보면 더 이해가 갈 것이다.

 

DB 같아 보이면서도 스프레드시트 같은 느낌? 그 어딘가?

 

하지만 기능은 DB를 사용하는 것처럼 다 사용할 수 있다. (ex. Table 결합, 레코드 정렬 등) 

 

혹시라도 더 궁금한 사람이라면 아래 링크에서 확인! (Zapier 측에서 정리해놓은 것인데 좋다.)

https://zapier.com/blog/what-is-airtable/

What is Airtable? And how it will change your view of databases | Zapier

 

 

Air Table API 사용

이제 본격적으로 Air Table을 사용해보자.

 

Air Table은 기본적으로 CRUD API를 제공한다. 

하지만 해당 API를 사용하려면 Private Token값을 사용해서 인증해야 한다.

 

이때 만약 Client단에서 이 값을 사용하게 만들면 보안 상 문제가 될 수 있기 때문에 Wrapper로 한 번 감싸줘야 된다. 

 

즉, 사용자가 호출하는 API 내에 Private Token이 없어야 된다는 것이다.

 

이때 나는 AWS API Gateway와 Lambda를 사용한 서버리스 아키텍처를 구현했다.

자세한 설명은 아래의 포스팅에..!

 

https://kimtaehyun98.tistory.com/143

AWS Lambda와 API Gateway 사용하여 메일링 코드 개발

 

그럼 아래와 같은 아키텍처가 나온다.

 

즉, 사용자는 Lambda 함수의 트리거인 API Gateway를 호출하고, Lambda 내부에서 다시 Air Table CRUD API를 호출한다.

 

지금 중요한 건 Air Table에 대한 포스팅이니까 넘어가자.

 

일단 Air Table 설정이 다 됐다고 가정한다.

(가입하고 로그인, Col 명 설정)

 

나는 프로젝트에서 "음악 관련 정보"를 찾아달라고 요청하는 API를 만들었고, 해당 요청에 대한 정보를 Air Table에 저장해서 관리하는 것이 목적이었기 때문에 아래와 같이 테이블을 구성하였다.

 

각자의 사용 목적에 따라 설정하면 된다.

 

설정이 다 됐다면 API Key를 발급받아야 한다.

(API Key는 API를 호출하려면 필수적이기 때문에 꼭 발급받기!! 🤗)

 

이제 Air Table API url을 확인해본다.

확인 방법 : https://airtable.com/api

 

(참고로 테이블 명에 " " 안 들어가는 게 좋음!! URL 만지려면 Encoding 시 복잡해짐!!)

 

위의 링크에 들어서 아래로 내려가다 보면 어떻게 List 불러오는지 알 수 있음

(너무 잘 설명되어 있어서 사용하기 어렵지 않음 👍👍👍)

 

 

 

PageNation도 가능하고 등등 다 가능함

(왼쪽 목록의 List records 등을 보면 CRUD 다 가능한 것을 확인할 수 있다.)

 

그냥 말 그대로 DB에 API 서버 하나 붙은 느낌이다!

 

이제 포스트맨 가서 해당 URL로 Get 요청해보자.

 

아마 안 될 것이다.

 

당연히 아까 저장해놓았던 Auth 인증해야지 호출이 된다.

Token 입력하고 다시 보내보면 정상적으로 리스트 호출된다

 

 

이제 새로운 데이터 입력도 어렵지 않다

 

아래 내려가 보면 또 예제 있음 🤗

 

POST롭 보낸 데이터가 Air Table에 잘 들어와 있는 거 확인할 수 있다.

 

이때 내가 하고 싶었던 작업은 

예를 들어 어떤 사용자가 한번 "취중고백"에 대한 데이터를 요청했으면 다른 사용자가 또 요청했을 시 count(테이블에서는 Calls)만 증가시키는 작업이다.

 

이런 걸 하는 것이 바로 PATCH 메서드이다.

 

이러한 서비스를 제공하는 API가 있으면 좋겠지만 아쉽게도 Air Table은 제공하고 있지는 않다.

(이거까지 바라면 너무 한 건가 ㅎㅎ... 🙃)

 

그래서 Lambda 내부에서 현재 데이터가 있는 데이터인지 확인해주어야 한다.

이럴 때 Lambda로 한번 감쌌기 때문에 굉장히 유용하다.

 

다행히도 Air Table이 위에서 언급했듯이 DB 같은 기능을 제공하기 때문에 Exist 같은 체크 기능을 GET Method를 통해서 확인 가능하다.

 

이렇게 GET Method를 통해 조건을 넣어 주는 것을 Fomula라고 하는데 다양한 Fomula가 있으니 아래 링크에서 현재 로직에 맞는 것을 찾아서 쓰면 된다.

https://support.airtable.com/hc/en-us/articles/203255215-Formula-Field-Reference

Formula field reference

링크 들어가 보면 알겠지만 정말 DB 예약어 같이 정말 많은 기능이 있다.

 

나는 노래가 이미 존재하는지 아닌지를 확인해야 했기 때문에 노래 번호로 == 비교를 했다.

 

아래는 Lambda 코드의 일부이다.

let getUrl = `${ApiEndpoint}/?filterByFormula=MusicNumberTj=${musicNumberTJ}`;

// Function : Get Row in Air Table
    const getRow = async() => {
        return await axios
          .get(
            getUrl,
            config
          )
          .then((res) => {
                getData = res.data.records;
                if(getData.length != 0) {
                    patchBodyParameters.records[0].fields.Calls = getData[0].fields.Calls + 1;
                    patchBodyParameters.records[0].id = getData[0].id;   
                }
          })
          .catch(error => {
            if (error.response) {
                console.log("get error!!");
            }
          });
    };

저렇게 = 비교로 하게 되면 MusicNumberTJ란 칼럼에 검색 값이 있다면 해당 데이터를 반환하고 없으면 아무것도 반환하지 않는다.

 

따라서 결과적으로 지금까지의 과정을 정리하면 다음과 같다.

 

1) 사용자가 Front에서 "추가 버튼"을 클릭

2) "추가 버튼" 이벤트로 API 호출

3) API Gateway 트리거 발동으로 Lambda 함수 실행

4) Lambda 함수 내부에서 Air Table GET API를 통해 현재 곡이 존재하는지 확인

5) 곡 정보가 이미 있다면 POST API, 없다면 PATCH API를 호출

6) Air Table 갱신 or 추가 완료

 

위의 과정을 통해 서버를 구축하지 않고도 자동화 파이프라인을 구축할 수 있게 되었다.

 

Air Table API가 처음에는 뭐가 좋은지 잘 몰랐지만, 사용하다 보면 정말 엄청 사기템인걸 알 수 있었다..! 🥴

 

정말 빠르고 저비용으로 저용량의 DB를 구축해야 한다면, Air Table을 한 번 사용해 보는 걸 강추한다!