사용자 상호 작용이 높은 웹 사이트의 경우 클라이언트 측 렌더링 또는 서버 측 렌더링이 더 좋습니까?

찰스 포플러

사용자가 사용자 계정에 로그인하고 테이블에 데이터를 입력 한 다음 (Tabulator를 사용하고 있음) 테이블의 데이터를 저장하는 웹 사이트를 개발 중입니다 (데이터 저장을 위해 MongoDB Atlas를 사용하고 있습니다). 웹 사이트에는 데이터가 다른 하위 페이지에 저장된 다른 데이터와 상호 작용하는 다른 하위 페이지가 있습니다 (예 : 웹 사이트에 "판매"및 "인벤토리"하위 페이지가 있으므로 사용자가 새 판매를 할 때 재고가 판매 금액만큼 감소 함) ). 기본적으로 사용자가 데이터에 대해 지속적으로 CRUD 작업을 수행하는 웹 사이트입니다.

오늘날 웹 사이트는 클라이언트 측에서 렌더링됩니다. 웹 사이트의 모든 하위 페이지에는 고유 한 개별 HTML 파일과 개별 Javascript 파일이 있으며 모든 하위 페이지에 대해 Atlas와의 모든 백엔드 통신을 처리하는 하나의 노드 파일이 있습니다. 나는 하나 또는 두 개의 다른 사용자 계정으로 로컬 PC에서 웹 페이지를 사용하고 테스트했으며 모든 것이 정상적으로 작동합니다 (각 사용자는 자신의 데이터를 저장하고 작업합니다).

이제 (도메인 또는 Heroku에) 웹 사이트를 배포하고 잠재적으로 수백 또는 수천 명의 다른 사용자를 확보 할 계획임을 고려하여이 옵션을 조사했습니다.

  • 간단한 클라이언트 측 HTML을 계속 사용하려면.
  • Node의 응답으로 HTML 렌더링
  • 노드에서 템플릿 엔진 사용

확장 성을 고려할 때 어떤 옵션을 권장합니까?

O. 존스

귀하의 질문은 좋은 질문이지만 예측하기 거의 불가능한 답변이 있습니다. 웹 앱을 소수의 사용자에서 수천 명으로 전환하면 항상 놀라운 성능 병목 현상이 발견됩니다.

병목 현상이 원시 다운 바운드 대역폭에 있습니까? API 호출 및 페이지 요청에 대한 응답을 줄임으로써 얻을 수있는 큰 이득이 있습니까? 가능하지만 Heroku 및 기타 우수한 호스트 공급 업체는 좋은 대역폭 작업을 수행합니다. 또한 https는 데이터를 암호화하면서 압축하므로 반복적 인 HTML은 보이는 것만 큼 비용이 많이 들지 않습니다. 따라서 서버가 많은 html을 렌더링하도록하는 것은 아마도 수용 가능할 것입니다.

앱-데이터베이스 인터페이스에서 일부 병목 현상이 발생합니까? 많은 양의 데이터와 복잡한 필터링 기준이 작용할 가능성이 높습니다. 모든 성공적인 웹 앱은 데이터베이스에 대한 경계가 필요합니다. 색인을 추가하거나 현재 상상할 수없는 문제에 대해 덜 우아한 해결 방법을 개발해야합니다.

데이터를 수집하는 프로세스와이를 사용하는 프로세스간에 경쟁이 있습니까? 아마. 그러나 그 논쟁의 세부 사항은 예측하기 어렵습니다.

tl; 박사. 이게 작동합니다. 지금 다시 작업 할 필요가 없습니다. 가지고있는 것을 배포하십시오. 사용자를 초대하고 경청하십시오. 성능에주의를 기울이고 필요한 것으로 입증 된 영역에 튜닝 및 리팩토링을 집중하십시오.

이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.

침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제

에서 수정
0

몇 마디 만하겠습니다

0리뷰
로그인참여 후 검토

관련 기사

Related 관련 기사

뜨겁다태그

보관