목적
리액트 사용해보기. 리액트 공부를 해봤으니까 공부한거 적용 + 더 찾아가면서 리액트로 간단한 쇼핑몰 페이지 만들어보기
데이터베이스는 mysql, 서버는 스프링 사용하기. RESTful API로 만들어보기
어려웠던 점
css가 너무 어려웠다. 나는 리액트를 사용해보는 것이 목적이여서 css에 많은 시간을 투자하고 싶지 않았는데, 디자인적 요소를 하나 맞게하는 것도 너무 시간이 오래걸렸다. 결국에는 위치만 대략 맞추는것으로 만족하기로 했고, 이쁜 디자인이나 폰트같은 요소는 다음에 해보기로 생각했다.
고민한 부분
여러 쇼핑몰 페이지에 들어가보면 상품을 신상품 순서, 많이 팔린 순서, 후기가 많은 순서 등 다양한 기준으로 나누어져 있다. 동일한 상품들을 일정한 기준에 따라서 정렬을 하는 것인데, 어디서 정렬을 하는지에 대해서 생각해봤다.
두 가지 가능성이 있다고 생각한다.
- 서버에서 각 기준에 따라 정렬을 하고 사용자에게 정렬된 데이터를 전송한다. 상품을 보여주는 기준(신상품, 많이 팔린 순서 등)의 개수에 따라 전송해야하는 데이터의 크기가 증가한다는 단점이 있다고 생각한다. 하지만 데이터가 많은 경우에는 정렬하는 속도가 빠르기 때문에
- 전체 데이터는 한 번만 전송하고, 사용자의 웹에서 정렬을 한다. 서버로부터 전송받는 데이터의 크기가 작지만, 상품의 개수가 많은 경우에는 정렬하는 오버헤드가 클 것같다. 네이버 쇼핑이나 쿠팡 같이 상품의 수가 셀 수 없을 경우에 이런 방법을 쓰면 속도가 엄청 느려질것이라고 생각한다.
결과적으로 1번의 방식으로 개발하는 것이 맞다고 생각한다. 처음에는 상품의 개수가 적어서 속도에 영향을 받지 않을 수 있겠지만, 여러 사람이 상품을 등록하고, 몇 년 뒤를 생각한다면 서버에서 처리하는 것이 맞다고 생각한다.
네이버나 쿠팡, 백화점 홈페이지 같은 경우에는 하루에도 여러 상품이 올라올 수 있고, 접근하는 사용자도 많을 것이라고 생각됩니다. 이런 경우에는 사람들이 많이 접근하는 데이터에 대해 캐시를 만들어서 동일한 정렬 작업을 줄이는 것이 중요하다고 생각합니다.
작은 쇼핑몰 페이지의 경우에는 매일 새로운 상품이 올라오지 않을 수도 있습니다. 그러므로 각각의 기준(신상품, 많이 팔린 순서 등)에 따라 데이터를 만들어 놓는 것도 하나의 방법이라고 생각합니다. 새로운 상품을 올리는 경우, 구매를 확정한 경우와 같이 순서에 영향을 줄만한 이벤트가 발생했을 때만 정렬작업을 다시 수행하면 된다고 생각합니다.
결과
메인페이지
세부페이지 (상품을 클릭했을 때)
리액트에 대한 내 생각
나는 자바나 파이썬같은 프로그래밍 언어를 주로 사용해와서 html은 낯설다는 생각이 있었는데, 리액트의 컴포넌트가 프로그래밍 언어 느낌을 줘서 익숙하게 사용했던거 같다. 데이터를 넘기는 것도, 반환하는 것도 프로그래밍 언어 느낌이 났다. 덕분인지 몰라도 html보다 가독성이 더 좋다고 생각했다.