Duck typing으로 API를 만들어 보자

이것은 어떤 동물일까?

꽥꽥 소리 내어 울고, 노란색 부리에, 뒤뚱뒤뚱 걸으며, 물갈퀴가 있다.

그렇다. 이건 분명 오리다.

 

Duck typing은 인터페이스를 만들 때 많이 사용하는 방법이다.

인터페이스란 구현 부가 없는 기능에 대해서만 선언한 설계도 같은 것이다.

API의 “I”도 interface의 약자이다.

 

누가 봐도…

나를 어렵게 만드는 말이 하나 있다.

누가 봐도 이해할 수 있는 변수/함수명

개발을 하는 사람이라면 누구나 공감하는 말이 아닐까 싶다.

개발을 잘하는 방법을 다룬 관련 서적에는 항상 등장하는 말이고, 상급자로부터 매번 듣던 말이다.

위문장에서 제일 어려운 부분은 “누가 봐도 ~” 다.

 

실제로 개발할 때 가장 많이 하는 실수가

• 기능과 이름이 맞지 않다던지, 
• 어려운 영어 이름을 지어서

혼란을 줄 때이다. 이로 인해 커뮤니케이션 비용이 많이 발생한다.

 

기능과 이름이 맞지 않는 경우에는 프런트/백엔드 모두 수정을 해야 하는 상황까지 이르게 된다.

이런 문제들을 해결하고자 쉽고, 직관적인 모델을 고민을 하게 되었다.

 

사용자 테이블 예시.

• subject
• description
• email
• password

 

지도 POI 테이블 예시.

• subject
• description
• lat

 

구체적인 모델 설명

위 사용자, 지도의 테이블에 기본이 되는 2개의 필드가 있다.

• subject = 제목
• description = 내용

사용자 테이블인 경우에는 subject가 사용자 이름이고,

지도 테이블인 경우는 subject가 매장 이름이다.

그 외 여러 가지가 있지만, 기본적인 모델을 가지고 필드를 채워 나간다에 초점을 맞추었다.

 

대부분의 웹사이트가 리스트를 먼저 보여 주고,

클릭 시 해당 내용을 보여 주기 때문에 리스트 모델의 경우는 크게 바뀌는 일이 없다.

 

이렇게 필드를 붙여 내가 사용하고 있는 Post의 모델이다.

• subject : string = 제목
• description : string = 내용
• media : array = 파일 리스트
• thumbnail : int = 등록된 파일 중 하나의 아이디
• relation : array = 이 글과 관련 있는 Post
• properties : object = 글 성격에 따른 설정값
• created_at : timestamp = 작성한 날짜
• updated_at : timestamp = 수정한 날짜

properties의 경우에는 index가 필요 없는, json형태의 데이터를 문자 타입 저장.

user, role, media 등 대부분의 테이블이 Post 모델과 비슷하다.

 

Metadata

metadata는 배열 타입으로 키와 값으로 이루어진 object 리스트를 반환한다.

주로 사용자의 추가 입력 사항이나 환경 변수를 저장하는 용도로 사용한다.

• post_id : int = 포스트의 아이디
• slug : string = 프런트에 노출시킬 이름
• subject : 키
• description : 값

 

마무리

모든 개발자가 즐겁게 일하기를 바라는 마음으로 유연하고, 확장이 가능한 모델을 계속 고민하고 있다.