문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 TypeScript (문단 편집) === 백엔드와 프론트엔드 통합 === 타입스크립트는 [[Node.js]] 런타임뿐만 아니라 원래 자바스크립트의 고향인 [[프론트엔드(프로그래밍)|프론트엔드]] 개발에서도 상당히 유용하다. 특히 프론트엔드와 [[백엔드(프로그래밍)|백엔드]][* Express 프레임워크 등.]를 모두 TypeScript로 구현한다면 종전과는 비교할 수 없을 정도로 높은 개발 안정성과 편의성을 확보할 수 있다. 프론트엔드-백엔드 상호 간 데이터 통신을 위해서는 일반적으로 [[JSON]] 형식의 REST API를 구현하게 되는데, [* XML을 쓰는 경우도 있지만, 로직 개발을 JavaScript 혹은 그 파생 언어로 진행하면서 굳이 XML을 사용해야 할 이유는 거의 없다. 원래부터 JSON 형식을 갖춘 JavaScript 객체를 굳이 XML로 직렬화하거나 반대로 XML을 JavaScript 객체 형식으로 파싱해야만 하는 번거로움을 겪어야 하기 때문.] 이렇게 사용되는 데이터 포맷은 개발 과정 중에 수없이 변경되고 또 변경되기 마련이다. 이로 인해 프론트엔드와 백엔드 개발자 사이에서는 수도 없이 커뮤니케이션 로스가 발생하고[* 심지어 프론트엔드와 백엔드를 같은 사람이 개발해도 한쪽에 변경 사항이 있다는 걸 까먹고 반대쪽에 이를 반영하지 않는 케이스가 결코 드물지 않다.] 이는 고스란히 개발자의 피로도 상승 및 개발 기간 증가, 유지보수성의 저하로 이어진다. 게다가 이러한 문제점은 실제로 코드를 동작시키지 전까지는 알아채기 어려운 경우도 많기 때문에 최악의 경우 검증되지 않은 버그가 남은 채 프로젝트를 퍼블리시하게 될 수도 있다. TypeScript가 이러한 사태를 미연에 방지할 수 있는 이유는, 프론트엔드와 백엔드간의 데이터 포맷을 타입으로 정의하여, 이를 양측에서 공통으로 참조하도록 구현하고.[* 프로젝트 소스 코드 내부에 별도 폴더를 만들어 데이터 포맷용 타입을 정의한 코드를 모아둘 수도 있고, [[npm]] 패키지 등의 라이브러리로 구현할 수도 있다.] 데이터 포맷의 변경 사항이 발생할 경우 이렇게 공용화된 타입의 정의부를 수정함에 따라 프론트엔드와 백엔드 코드에 컴파일 에러를 발생시킴으로써 데이터 포맷의 통일을 강제하기 때문이다.[* 가령 User라는 타입의 id라는 필드를 name으로 수정한다고 할 때, 기존의 user.id를 참조하고 있던 프론트엔드와 백엔드의 코드들은 컴파일 에러를 발생시키고 개발자는 데이터 포맷의 변경에 따라 어떤 코드들이 수정되어야 하는지를 쉽게 파악할 수 있다. IDE의 리팩토링 기능을 활용하면 연관된 모든 코드들을 자동 수정해주기까지 하므로 일일이 고칠 필요조차 없는 경지에 이른다.] 물론 백엔드 개발자들은, 타입스크립트 사용 이전에 프론트엔드 개발자에게 올바른 API를 제공하~~고 본인의 정신건강을 지키~~기 위해서는 Swagger등의 API문서의 작성이 선행되는 게 권장되긴 하겠으나, IDE에서 제공하는 자동 완성이나 API 에러 알림 등의 피드백 덕분에 문서 참조의 필요성을 줄일 수 있다는 것 자체가 상당한 장점이다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기