frontend data binding 서버와 똑같이 할 것인가?
full stack과 isomorphic하게 개발하고 싶어요
저는 java로 프로그래밍을 시작했지만 javascript를 더 좋아합니다.
여러 이유가 있지만 가장 큰 이유는 프론트와 서버를 같은 언어로 개발할 수 있다는 거죠.
같은 언어로 개발하면 좋은 점이 뭐가 있을까요?
- 검증 로직을 공유할 수 있다.
벡엔드와 프론트 둘다 같은 검증 로직을 적용해야 할 경우가 많습니다. 서버는 java이고 프론트는 javascript라면 똑같은 로직을 두번 작성해야 합니다.
개발이 피곤해 집니다. - 원하는 API response가 벡엔드와 프론트가 다르다.
프론트: ‘그런식으로 보내주면 화면에 표현하는데 손이 많이 가요. 내가 원하는 API가 뭔지 모르겠어요’
벡엔드: ‘기존에 있는 API로 충분히 표현 가능한데 추가로 API를 만드는 건 시간 낭비입니다. 개발자에게 시간은 금이라고요’
풀스택으로 개발한다면 가장 효율적인 방식을 고민하며 API구성을 하게 된다. - typescript의 이점 활용 서버와 클라이언트가 dto를 공유한다면 코드 수정을 편하게 할 수 있다. api싱크로율 또한 상승
프론트엔드 기술이 급변하면서 벡엔드와 프론트가 분리된 곳이 많아졌다.
전통적인 SI방식에서는 화면을 퍼블리셔에게 떠 넘기는 경우가 많았다. 근래에는 spa프레임워크를 필두로 프론트엔드 기술이 발전하면서 프론트엔드 전문 개발자가 필요하게 됐고 이에따라 서로의 기술을 잘 이해 못하는 경우도 많고 프론트는 서버와 완전히 분리되어서 개발 되는 경우도 늘어났다.
서버와 분리된 프론트 엔드 개발
개발 일정에 시달리고 기획이 수시로 바뀌는 상황이라면 API의 변경도 잦다.
API response 변수에 의존성이 큰 경우의 문제점
data binding이 api response 변수에 의존 성이 크다면 api가 변경될 때 마다 모든 곳을 수정해야 한다. 또한 같은 모양의 컴포넌트라도 다른api가 다른 변수를 내려준다면 컴포넌트를 새로 만들어야 한다. api를 변경할 때 마다 테스트를 하지 않는다면 후에 큰 혼란이 올 수 있고 변경이 일어날 때 마다 개발 시간도 많이 늘어나게 된다.
API 의존성을 탈피하자
A Component a Api 에서 A Component를 사용하는 b Api가 생겼다. 그런데 내려주는 변수가 다 다르다. 새로운 B Component를 작성한다. 이러한 경우가 늘어났을 경우 컴포넌트와 API를 분리했다면 어느 Component와 API가 매칭되는 지 파악하기 힘들다. API와 Component가 합쳐져 있다면 Component덩어리는 계속 커질 것이고 SPA를 사용한다면 그 의미가 퇴색된다.
이런 문제점을 개선하기 위해 api -> mapper -> component 패턴을 사용하자 크게 보면 adaptor패턴에 속한다. api변경이 일어난 다면 mapper만 수정한다. 새로운 api를 써야 할 경우 새로운 mapper를 만든다. mapper는 정말 단순한 코드고 typescript를 사용한다면 type검증도 할 수 있다. mapper가 군더더기로 보일 수도 있겠지만 component를 원래의 목적대로 사용하게 할 수 있는 건강한 관절이 되어 줄 것이다.