배경
지금까지의 개발프레스는 다음과 같다
- notion으로 백엔드와 프론드가 api명세를 정의
- 개발진행
- 프론트엔드: msw등 자체 mocking 환경 구성
- 백엔드: Postman으로 api개발 후 swagger에 배포
- 개발 url에서 정상동작 확인
- 배포
여기서 겪었던 문제점으로
- 개발과정에서 api명세가 수정되었을 때 특정 툴에만 수정사항이 반영됨
- 동일한 작업을 내가아닌 다른 동료가 해야하는 상황이 발생하였을때 명세가 수정되어있지않음
- 결국 개발서버에서 테스트를 할 때까지 모르다가 확인 후 수정하여 다시 배포하는 번거로움이 발생
- 구두로 소통 후 각자의 개발환경에서만 수정하고 개발을 진행하게 됨
- 시간이 지나면서 개개인마다 주로 참고하는 툴들이 달라짐
- 개발팀 내 일관성이 떨어져 불필요한 소통비용이 발생함
- notion 같은 경우 정해진 양식이 없다 보니 작성하는 사람마다 작성 스타일이 달라 일관성이 떨어짐
- 프론트입장에서 api명세를 보고 mock데이터를 만들고 api 요청, 응답 인터페이스를 만드는 일련의 보일러플레이트 코드 작업이 귀찮음
→ 개발하는 과정에서 api명세에 수정사항이 발생했을 때마다 관련된 모든 툴들을 계속 수정하는 것이 귀찮고 시간이 오래 걸리는데 좀 더 효율적으로 api를 관리할 수 있는 방법은 없을까?
Apidog을 고려하게 된 이유
Apidog은 API 설계, 개발, 테스트, 관리, 문서화 및 모킹을 위해 설계된 포괄적인 api협업 플랫폼이다.
- api를 개발하는 과정에서 명세를 동시에 수정할 수 있어, api에 대한 single source of truth를 지킬 수 있음(프론트엔드,백엔드)
- 코드레벨단에서 모킹환경을 세팅해 줄 필요 없음(프론트엔드)
- 데이터모델을 재사용할 수 있어 특정 api의 응답 스키마를 빠르게 작성할 수 있음(백엔드)
- 응답 목데이터 json파일을 일일이 작성할 필요 없이 스키마에 따라 자동생성(프론트엔드,백엔드)
- api document를 api명세기반으로 자동 생성해 줌으로써 팀 내 일관성을 유지시켜줌(프론트엔드,백엔드)
Apidog을 적용했을 때의 개발 프로세스
1) api 명세정의하기
기획안 및 디자인시안을 확인하면서 api스펙을 정의
응답 스키마 설정
필드값의 타입을 지정할 수 있고, 필드명에 맞는 대략적인 목데이터를 자체적으로 파악하여 생성해 줌으로, 추후 목데이터를 생성하는데 시간을 단축시켜 줌(내부적으로 Faker.js를 사용)
또한 자주 사용되는 데이터모델은 저장해 놓고 재사용이 가능하여 응답 예시를 작성하는데 시간을 단축할 수 있음.
api응답값 자동생성
저장 후에 보이는 응답값
2) 개발팀 검토
- 개발팀 내에서 리뷰를 하면서 api의 use case를 정의
3) 개발 시작(프론트엔드,백엔드)
- 프론트엔드: local mock server, 자체제공 cloud mock server의 mockapi를 호출하여 화면 개발
- 2단계에서 정의한 use case를 모두 통과하는 것을 목표로 개발
- 개발 후 api테스트 자동화기능을 사용하여 검증 가능백엔드
- 개발과정에서 api수정사항이 발생하더라도, api스펙에 수정된 사항이 자동으로 반영됨으로써 api의 single source of truth를 유지할 수 있게됨(프론트 ↔ 백엔드 소통비용 감소)
4) 개발이 모두 완료되면 개발 서버 url로 변경 후 브라우저에서 테스트 진행
5) api 문서 배포
결과
api의 관리포인트의 일원화관점에서는 작용하였으나, 아무래도 커뮤니티가 매우 작고 출시한 지 얼마 안 된 툴이기 때문에 새로운 팀원이 합류했을 때 툴에 대한 사용법을 이해하는데 시간이 다소 걸렸다.
예를 들어 백엔드개발자는 기존에 Postman개발에 익숙하기 때문에 그렇게 큰 이질감은 없었지만, 프론트엔드 개발자 중에선 단순 mock환경은 쉽게 적용했지만, 세밀한 mock환경을 세팅하는데 다소 시간이 걸리는 상황이 발생했었다.