드디어 graphql 이전작업이 이루어졌다.
graphql 적용하려는 이유는?
- 현 회사의 문서화 부족
문서화가 기본적으로 돼있어서 api구조 설명서를 따로 쓸필요 없는점.(가장 중요) - overfetching, underfetching문제 해결
- frontend에서 backend api에 대하여 TS적용 가능(apollo codegen을 이용한 개꿀기능)
- frontend단에서 아주 좋은 사용자 경험
- 개꿀 캐싱기능
등으로 간단히 추릴수 있다.
이전작업 진행 방법
-
이미 구축돼있는 모든 api를 갈아엎을수는 없으니깐
기존 로직을 유지하면서 도어맨 역할만 graphql로 변경해주는 방식으로 진행한다. -
일부는 역공학을 때려서 graphql에 적합한 로직으로 재구성 한다.
- 위와같이 현실과 타협을 하면서 진행합니다.
아무도 알아주지 않지만...
이미 서비스가 잘? 굴러가고있는데 왜 이런 자원투자를 해야하냐는 의견이 있었지만
회사의 시스템은 이미 고도화 됐고 복잡한데 앞으로 더욱 고도화 되고 복잡성도 증가할 것이다.
지금이라도 이런 체계를 미리 구축하지 않는다면 앞으로는 작업이 너무 힘들어지고
개발자의 특성상(철새 특성) 자주 교체되는데
개발자들이 현 회사에 적응할때 너무 많은 자원소모를 하게되는것을 방지하고자
이전 작업을 진행했다.
(진행 하자고 대표님을 설득합니다.)
그리고 겸사겸사 이런 저런 이점도 있고 현 트렌드에 적합하기도 하고 등등...
굳이 적용 안할이유가 없었다.
할수 있는데 굳이 안할 이유도 없다.
협업에 관하여
매번 api endpoint를 직접봐야지만 이해가능한 구조
(또는 백엔드 개발자에게 요청하던가..불편함)
를 벗어나고
불필요한 커뮤니케이션 비용을 줄일수 있다.
의사소통 비용
실제로 전 회사에선 api doc를 따로 구축하여 협업을 하였지만
사람이 작성하다보니깐 해당 사람의 의도파악이 제대로 안될때가 있고
해당 문서를 작성하는 사람마다 문서화의 패턴이 다르기에 일정한 패턴을 가진
즉 규칙적인 문서화가 필요했다.
회사 일에서 가장 소모가 많은것이 커뮤니케이션 비용인것 같다.
개발자와 개발자, 개발자와 비 개발자, 개발자와 대표님 등등...
일이 어려운거야 시간 투자하면 결국 해결이 되지만
의사소통이 제대로 안된상태에서 작업이 진행되고 프로젝트가 산으로가서
이것을 갈아 엎어버린 경험이 수두룩하다.
(이럴때마다 느껴지는 허탈함은 생각보다 컸다)
이런 과정또한 개발의 과정인것을 인지하고 있고 더욱 시스템을 개선하여 서로의 입장을 이해할수 있게 만드는것도 개발자의 자세라고 배웠다.
마무리
비 개발자와 개발자의 의사소통, 생산성과 좋은 코드 및 프로젝트 설계,
눈에 보이는 부분과 안보이는 부분들 등등
이런것들중 그 사이 어딘가 현재 주어진 환경에 맞춰 잘 완급조절을 잘 해야한다.(쉽지않음)
