타다 : 비트윈과는 굉장히 다른 서비스 - 오프라인 운영 경험의 부재 팀원들의 개발능력 향상 - 각자 안하던 분야를 함으로서 개발 능력 향상 - 다른 플랫폼을 보아 어떻게 다른지 알게 됨 비즈니스 로직의 통합 - 플랫폼 마다 다른 동작을 최소화 & 비즈니스 로직 고민 시간 단축
타다 : 비트윈과는 굉장히 다른 서비스 - 오프라인 운영 경험의 부재 팀원들의 개발능력 향상 - 각자 안하던 분야를 함으로서 개발 능력 향상 - 다른 플랫폼을 보아 어떻게 다른지 알게 됨 비즈니스 로직의 통합 - 플랫폼 마다 다른 동작을 최소화 & 비즈니스 로직 고민 시간 단축
타다 : 비트윈과는 굉장히 다른 서비스 - 오프라인 운영 경험의 부재 팀원들의 개발능력 향상 - 각자 안하던 분야를 함으로서 개발 능력 향상 - 다른 플랫폼을 보아 어떻게 다른지 알게 됨 비즈니스 로직의 통합 - 플랫폼 마다 다른 동작을 최소화 & 비즈니스 로직 고민 시간 단축
- HTTP Request Method (GET, PUT, …) 을 제대로 썻는가? - URL 에 오탈자가 없는가? - Parameter 이름에 오탈자가 없는가? - DTO 에 오탈자가 없는가? - API 문서를 제대로 따르지 않았는가? 아무리 봐도 잘못한 게 없다 - 재현되는 curl 커맨드를 만들고 이렇게 해도 안된다고 서버에게 말한다.
에 저장하고 있는데, DTO 구조가 바뀌면? - Client specific 로직은? proto 파일을 수정? - generated code 는 읽기 어렵다 결론 : DTO 를 직접 만들자 (data class) - proto 파일 = API 문서 - Migration, client specific 로직 짜기 수월 - 그럼 결국 Client 는 오탈자가 날수 있는거 아닌가요?
에 저장하고 있는데, DTO 구조가 바뀌면? - Client specific 로직은? proto 파일을 수정? - generated code 는 읽기 어렵다 결론 : DTO 를 직접 만들자 (data class) - proto 파일 = API 문서 - Migration, client specific 로직 짜기 수월 - 그럼 결국 Client 는 오탈자가 날수 있는거 아닌가요?
에 저장하고 있는데, DTO 구조가 바뀌면? - Client specific 로직은? proto 파일을 수정? - generated code 는 읽기 어렵다 결론 : DTO 를 직접 만들자 (data class) - proto 파일 = API 문서 - Migration, client specific 로직 짜기 수월 - 그럼 결국 Client 는 오탈자가 날수 있는거 아닌가요? -> 원하는 형태의 data class 를 만들어주는 Compiler 를 만들자.
GetUserParams, GetUserResult 를 protobuf 로 만듬 - GetUser.proto 를 VCNC/tada-protocol 에 git push 클라이언트 팀 - tada-protocol 의 proto 파일을 컴파일 후, Client specific 로직 추가 - GetUserParams 를 api.tada.com/GetUser 에 POST 로 request - response = GetUserResult