NextJS,기반으로컬리쇼핑몰클론해보기클리앙 NestJS, Graphql, Typescript 기반의 쇼핑몰을 구축해 보았습니다.
NextJS는 이번에 처음이라 간단하게 사용기를 올려봅니다.
도입배경
지금까지는 순수 ReactJS 기반의 서비스만 개발하다가 검색 최적화를 해야하는 프로젝트가 있어서 NextJS로 기초 프로젝트를 해보았습니다.
첫번째 NextJS프로젝트로 쇼핑몰을 선택한 이유는 아래와 같습니다.
저희에게 개발을 의뢰해 주시는 회사들중 스타트업이 많이 있습니다.
스타트업은 그들의 앱에서 다양한 사용자의 활동을 지원하고 보상으로서 포인트를 발행해 줍니다.
그런데 발생된 포인트를 어딘가에서는 사용할 수 있어야 뭔가 좀 의미가 있는데.. 현실적으로 스타트업이 이 포인트를 타 업체에 이관해서 사용하기가 쉽지 않습니다. 그래서 서비스에 쇼핑몰을 접목하기를 원하는 경우가 많았습니다.
이 과정에서 카페24나 고도몰과 같은 서드파티 쇼핑몰을 사용하게 되는데요. 보통 앱을 제작하시는 경우 앱에서 외부 쇼핑몰을 웹뷰로 연동하여 보여지는게 일반적 입니다.
그런데 해보니 무엇보다 포인트와 회원정보를 자연스럽게 동기화하는게 쉽지가 않았습니다.
가능은 하지만 뭔가 어설프게 되는? 그리고 쇼핑몰의 기능이나 정책에 우리가 끌려다니는 웩더독의 모양새가 되어 버리더라구요.
아..쇼핑몰이 하나 있어야겠구나. 생각했습니다.
우리 회사는 주로 기업에 업무등과 같이 노출이 필요 없거나 ReactJS만으로 어찌어찌 검색엔진에 보여지게는 해왔는데요
많은 기업들이 적용은 하고 있지만 저는 약간 신기술 적용에 좀 보수적이라서 그런지 좀 늦은 감이 있었지만 드디어 NextJS를 도입하게 되었습니다.
도입과정
NextJS는 뭐 SSR과 그에 따른 검색엔진최적화, 라우팅, 코드분할, 캐싱, 자동 "이미지최적화" 등등 ReactJS와 차별화 된 다양하게 기능들이 있습니다.
이기능을 잘 활용하는것 외에 ReactJS와 개발과정이 대동소이했습니다.
SSR을 통해서 완전한 html 문서들이 서버에서 생성되어 제공됩니다. 이로써 모든 검색엔진들이 페이지의 정보를 잘 인식하게 됩니다.
그런데 저희가 ReactJS로 웹애플리케이션을 운영할때도 구글에서는 잘 검색이 잘 되었고 네이버는 안되었어요. 그래서 PHP가 헤더정보를 뿌리고 ReactJS를 로딩하는 편법을 사용하였습니다.
폴더 기반 라우팅은 개발 과정에서 일거리를 좀 덜어 주고 편리하게 사용했습니다.
코드분할과 캐싱은 ReactJS도 동일하게 있는 기능이네요..
코드분할을 잘 이용하면 "선제적으로 로딩되어야 하는부분과 요청시에 로딩되는 부분을 잘 구별해서 설계하면 꽤 가벼운 초기로딩을 만들수 있다"라고 듣기는 했는데 잘했는지는 모르겠어요..
이미지최적화는 간단하게 말해서 제품 이미지등을 서빙할때 사이즈에 맞춰서 자동으로 리사이징 후 제공하는 기능입니다. 네트워크부하도 줄고 속도도 빨리지더군요.
그런데 최초에 이미지에 접근할때는 이미지리사이징에 꽤많은 시간이 소요되고 cpu리소스도 엄청 먹습니다. 결국에서 이미지 캐싱시간을 일년으로 해두었습니다.
이미지가 업데이트되거나 하게 되면 캐싱을 무효화하는 방법을 추가 해야 겠습니다.
리사이징과정에서 서버에 sharp패키지가 꼭 필요하고요 특히 스왑사이즈가 충분하지 않으면 서버가 죽습니다. AWS 특히 lightsail 인스턴스는 기본적으로 스왑을 잡지 않네요 이거 찾는데 한참 걸렸습니다.
그..리..고..."이미지최적화" 이렇게 저렇게 하면서 느끼는게, 이것이 약간 계륵인것이..웬만한 사이트는 이미지를 웹서버에서 서빙하지 않습니다.
저희 같은 경우도 작은 서비스를 만들때 조차도 S3/Cloudfront를 이용하지 웹서버에서 바로 서빙하지 않거든요..
결국에는 이미지가 CDN에서 서빙되어야 하는데요..그럼 NextJS에서 만들고 이것을 s3로 올리나?
이럴바에야 s3에 람다의 가장 멋진 기능인 트리거를 통해서 리사이징을 하면되는데요...
이문제는 VERCEL에 배포를 해결될것도 같은데. 다시한번 생각해 볼 문제입니다.^^
그리고 SWC를 적용했더니 빌드가 좀 빨라지긴 했던것 같네요..문서처럼 드라마틱한 증가는 저는 경험하지 못했지만 실제로 조금이라도 더 빠르니 사용하지 않을 이유가 없네요..
Graphql은 서비스를 좀더 구체화?한다는 기능이외에도 모든 api들에 대해서 잘 정리된 문서가 제공되므로 프론트개발자에게는 api사용에 편의성을 제공하고 백엔드개발자에게는 같은 설명 두번 안해도 되는 ㅋㅋ 큰 장점이 있습니다.
하나의 엑세스포인트를 제공하기 때문에 깔끔한것 같으면서도 요청마다 쿼리를 하나하나 만들어줘야 한다는 점은 있습니다. 의도는 명시적인 요청을 통해서 오버헤드를 막겠다는건데 결국에는 클라이언트에서 어떤걸 요청하던 백엔드에서 주는놈 맘이라. 없는걸 요청해봐야 오류만 나죠..ㅎㅎ
이런 기능들은 스웨거 또한 제공된다고 알고 있습니다.
Typescript는 결국에는 해야겠죠.
네스트는 기본적으로 Typescript를 사용합니다. 서버는 뭐 스프링이던 타입을 써서 그러려니 하지만 프론트까지 해야하니..똑같은 타입을 양쪽에 만드는 일이 좀 번거롭기는 합니다.
NextJS라는 것이....다 좋은데..
서버가 한대 더 늘어나는게 좀 그렇네요..결국에는 SPA에서 PHP나 JSP처럼 예전의 방식으로 회귀하는거구나 하는 생각도 듭니다.
구현 후에 살펴보니 큰 어려움 없이 대부분이 강점을 잘 살려서 제작할 수 있었던 것 같습니다.
좋은점
새로운 기술을 적용해 보는것은 언제나 즐겁다 입니다..
아쉬운점
돈을 못벌고 있다..이제 팔기만 하면되겠다...
개선방향
엄마아빠가 농사를 하시는데 이걸로 부모님을 위한 쇼핑몰을 하나 하면서 기술적으로나 기능적으로 추가해 보려고 합니다.
실력은 언제나 주니어라는점 양해 바랍니다.^^
내용 중 잘못이해하고 있거나 틀린점 있으면 댓글 부탁드립니다.
주소는 https://shop.leanspack.com 입니다...컬리 미안해요...