최근 angular.js를 활용해 single page application 으로 개발하는 것이 트렌드로 자리잡고 있다. 학생 중의 한명이 angular.js 기반으로 개발하는 것을 무지 좋아하면서 다음과 같은 주장을 하고 있다.
서버 측에서 template engine을 활용해 웹 페이지를 생성하던 기존의 방식보다 angular.js와 같이 서버 측에서는 api만 제공하고 클라이언트에서 동적으로 웹 페이지를 구성하는 것이 훨씬 생산성이 좋다.
즉, 서버는 api만 제공하고 모든 웹 페이지 구성은 클라이언트가 처리한다. 이와 같은 방식으로 개발할 경우 기존의 방식에 비해 생산성이 정말 좋을까?
장기적인 관점에서 api만 제공하기 때문에 모바일 대응이 가능하며, 서버 측 개발자와 클라이언트 측 개발자의 역할이 완전히 독립적으로 분리할 수 있기 때문에 얻어지는 장점은 분명 있으리라 보인다.
1개의 의견 from FB
api와 프론트단의 분리 개발은 플랫폼 확장을 위해 반드시 필요한 것 같구요.. 앵귤러와 클라이언트단 렌더링은 어차피 사용자경험을 위해 클라이언트단 렌더링을 쓰고 있으니 굳이 서버단 렌더링까지 할 필요가 있느냐, 렌더링은 클라이언트에서만 하도록 하면 뷰단 로직이 분산되지 않고 좋다는 주장인 것 같네요.
하지만 클라이언트단 렌더링으로만 처리하면 SEO 문제나 초기 스크립트로드-데이터통신-렌더 세 단계를 거치기 때문에 최종 페이지 렌더링이 늦게 되어 오히려 사용성이 저하될 수 있으니 간단한 문제는 아닙니다. 대개 고통을 감내하고 뷰 로직을 분산시켜 서버/클라이언트 렌더링을 모두 취하게 되죠.
제 경우는 서버/클라이언트 양쪽 모두 렌더링이 필요한 경우 뷰 로직은 한쪽(서버가 되겠죠)에서 처리하고 완성된 결과물(html)만 던져주는 식의 처리를 선호합니다. 데이터 통신만 하는것보다야 통신비용이 증가하겠지만 유지보수 측면에서 차라리 이게 낫다고 생각되어서..
전에는 이 문제를 서버/클라이언트 모두 동일한 템플릿엔진을 사용하는 방식으로 해결하려고 했는데 결국 실행환경(서버/클라이언트)이 다르면 미묘하게 동작이 다른 문제들이 있어 오히려 피로가 증가 하더군요.
그래도 양쪽 환경을 모두 자바스크립트로 통일하면 답을 찾을수 있지 않을까 합니다. 저는 node.js와 react로 도전해보고 있어요.
6개의 의견 from SLiPP
api와 프론트단의 분리 개발은 플랫폼 확장을 위해 반드시 필요한 것 같구요.. 앵귤러와 클라이언트단 렌더링은 어차피 사용자경험을 위해 클라이언트단 렌더링을 쓰고 있으니 굳이 서버단 렌더링까지 할 필요가 있느냐, 렌더링은 클라이언트에서만 하도록 하면 뷰단 로직이 분산되지 않고 좋다는 주장인 것 같네요.
하지만 클라이언트단 렌더링으로만 처리하면 SEO 문제나 초기 스크립트로드-데이터통신-렌더 세 단계를 거치기 때문에 최종 페이지 렌더링이 늦게 되어 오히려 사용성이 저하될 수 있으니 간단한 문제는 아닙니다. 대개 고통을 감내하고 뷰 로직을 분산시켜 서버/클라이언트 렌더링을 모두 취하게 되죠.
제 경우는 서버/클라이언트 양쪽 모두 렌더링이 필요한 경우 뷰 로직은 한쪽(서버가 되겠죠)에서 처리하고 완성된 결과물(html)만 던져주는 식의 처리를 선호합니다. 데이터 통신만 하는것보다야 통신비용이 증가하겠지만 유지보수 측면에서 차라리 이게 낫다고 생각되어서..
전에는 이 문제를 서버/클라이언트 모두 동일한 템플릿엔진을 사용하는 방식으로 해결하려고 했는데 결국 실행환경(서버/클라이언트)이 다르면 미묘하게 동작이 다른 문제들이 있어 오히려 피로가 증가 하더군요.
그래도 양쪽 환경을 모두 자바스크립트로 통일하면 답을 찾을수 있지 않을까 합니다. 저는 node.js와 react로 도전해보고 있어요.
오래전에(?), fat서버 -> thin클라이언트 -> 3 tier환경으로 개발 패러다임이 변경된것과 동일한 이슈 아닐까요? 서버에서 화면을 구성해서 더미터미널에 뿌리는 방식에서(WEB도 서버사이드에서 처리하고 html을 내려주는것과 같이),, 클라이언트 성능이 좋아짐에 따라 , 클라이언트에 로직을 두는방식(vb, delphi등 2tier 프로그램)으로 잠시 진행됐다가,, 궁극적으로는 프리젠테이션/비지니스로직/저장소 물리적으로 구분되는 3tier기반으로 변경되었던것으로 기억합니다. 당연히 서버/클라이언트 개발자가 구분되고, api만 정의하고 개발을 진행합니다. 서로 가상의 요청과 응답을 넣어며, 독립적으로 개발을 진행할수 있습니다. 특히, 서버 개발자는 좀더 비지니스에 집중할수 있어 로직이 견고해지고 DATA에 대한 소유권과 접근제어를 가능하게 합니다. 클라이언트 개발자는 UX에 집중할수 있으며, 업무영역에 대한 이해는 많이 필요치 않습니다.
개인적으로는 오래전 진행되었던 패러다임과 동일하다고 생각합니다. 과거 경험을 비춰볼때 생상성 + 품질 모두 드라마틱하게 향상됩니다.
현재의 웹 프레임워크 트랜드는 isomorphic하게 가는 것입니다. 아이소모픽은 같은 코드로 서버와 클라이언트에서 모두 실행이 되는 것입니다.
요즘 isomorphic에 대응되는 라이브러리는 React, Angular.js 2 (Angular.js 2는 DOM에 강결합이지 않아 isomorphic합니다.), jQuery, Backbone.j2, Ember.js, Modernizr, YUI, Handlebars, Flux, Meteor 등을 들 수 있을 것 같네요.
isomorphic의 범위에 대해서는 다들 이견이 있겠지만 대부분 View 수준에서는 isomorphic하게 가고 있고요. (이를 좁은 의미로 한정지어 Universal Rendering이라고도 부릅니다.)
저는 계층적으로는 분리가 되는 것이 옳겠지만 그 계층이 서버와 클라이언트로 구분되는 것은 모던하지 못하다고 봅니다. 계층으로는 분리되지만 하나의 컴포넌트가 서버에 돌지 클라이언트에 돌지는 유연한 것이 최근의 트랜드입니다.
@진우 @Dalinaum 답변 감사합니다. 최근에 흐름이 isomorphic라면 이 형태로 구현되어 참고할만한 코드가 있을까요? isomorphic에 대해 대략적인 감은 오는데 어떤 형태로 가능하도록 하는지 궁금해서요.
@자바지기 react-redux-universal-hot-example를 한번 살펴보시면 좋을듯 합니다. react, redux(flux 구현체 중 하나), es2015에 대한 이해가 선행되어 있으면 좋겠지만 사전 지식이 없더라도 README와 코드를 살펴보면 대충 동작은 이해할 수 있을것 같네요.
@진우 thx. 왜 이리 세상은 빨리 변하는거야. 뭔가 SPA 나와서 그런가보다 했는데 또 다른 흐름이 등장하고 있으니.. 뭐 그래도 새롭게 공부할 꺼리 생겨서 심심하지는 않네.
의견을 남기기 위해서는 SLiPP 계정이 필요합니다.
안심하세요! 회원가입/로그인 후에도 작성하시던 내용은 안전하게 보존됩니다.
SLiPP 계정으로 로그인하세요.
또는, SNS 계정으로 로그인하세요.