쉽게 피할 수 있는 JS 퍼블리싱 오류 3가지 상세 소개_기본지식

웹 애플리케이션 개발은 클라이언트 측에서 모든 사용자 로직과 상호 작용 코드를 실행하는 경향이 있으며, 서버는 REST 또는 RPC 인터페이스를 노출합니다. 컴파일러는 플랫폼으로서 JS를 목표로 하고 있으며 ECMAScript의 두 번째 버전은 이를 염두에 두고 설계되었습니다. Backbone, Ember 및 Require와 같은 클라이언트 측 프레임워크는 코드가 풍부할 뿐만 아니라 개별 구성 요소, 구성 요소와 데이터 간의 많은 상호 작용을 포함하는 기능이 풍부한 애플리케이션의 생성을 장려합니다.
이것은 정말 훌륭하고 뛰어난 사용자 경험을 제공할 수 있지만 웹 애플리케이션과 웹 페이지를 개발하는 것이 어렵다는 것은 의심의 여지가 없습니다.
근본 원인은 특히 주의해야 하는 언어인 자바스크립트로 임의의 브라우저에서 실행되는 인터넷을 통해 코드와 데이터를 제공하는 것은 코드 배포가 전혀 없는 플랫폼이기 때문입니다. 그리고 그것은 곧 개선되지 않을 것입니다. Star Trek이 현실이라면 Jean-Luc Picard 선장이 가끔 싸울 수 없었던 이유는 그가 여전히 Krillin 대시보드를 탑재하고 있었기 때문입니다.
저는 비교적 흔히 발생하는 세 가지 실수와 쉬운 해결책을 강조하고, ReadyForZero를 통해 접하고 배운 몇 가지 독특한 점에 대해 이야기하고 싶습니다.
"캐시 지우기" 헤더 정보 제거
CDN을 사용하여 정적 리소스를 캐시할 수 있는데 이는 확실히 합리적입니다. 서버에서 캐시되지 않은 리소스를 요청하는 경우(예: 파일이 실제 웹 사이트를 가리키도록 AWS 측에서 "custom-origin"을 사용하는 경우) 주의하십시오. 새 버전의 파일을 배포한 후 파일 이름에 캐시 지우기 문자열(헤더 정보)을 추가하면 파일 이름이 다음과 같이 됩니다. http://www.jb51 .net/ js/main__V0123456789abcdef__.js
해시 알고리즘을 선택하여 이 문자열로 지문 정보를 생성하면 파일 내용이 변경됨에 따라 변경됩니다. 새 URL이 참조되면 캐시할 수 없으므로 서버의 새 버전을 가져올 수 있습니다. 여기서 오류가 발생합니다. 웹에는 "캐시 지우기" 헤더를 제거하고 대신 서버에서 새 버전의 파일을 직접 제공하도록 하는 권장 사항이 많이 있습니다. 여러 서버 클러스터가 있는 경우 사이트에 서로 다른 파일(예: html, js)의 버전이 일치하지 않을 수 있습니다(예: js는 업데이트되었지만 html(다른 서버에서 요청)은 여전히 ​​오래됨). CDN이 잘못된 버전을 쉽게 캐시할 수 있다는 것입니다. 이 오류는 다음과 같이 발생합니다.
·처음에는 모든 서버가 HTML1 및 JS1입니다.
·서버 A가 다시 시작되고 HTML2 및 JS2를 제공합니다.
·클라이언트가 CDN에서 main__V2__을 요청합니다. 현재로서는 새로운 것이므로 CDN에 캐시가 없습니다.
·CDN은 이 요청을 설정한 Custom Origin으로 전달했고, 이 요청은 서버 B로 전송되는 일이 일어났습니다.
· 서버 B는 "캐시 지우기" 문자열을 제거하고 이전 버전을 반환합니다.
·CDN은 오래된 파일을 새 파일로 캐시합니다.
쉽게 생각해볼 수 있는 일이지만 인터넷의 조언을 무작정 따르면 실수를 저지르기 쉽습니다. 더 나쁜 점은 모든 것이 괜찮아 보이고 오류가 발생했는지조차 모르는데 다른 CDN을 사용하는 다른 지역의 사용자가 잘못된 버전을 캐시했을 수 있다는 것입니다. 해결책은 "캐시 지우기" 문자열을 제거하지 않고 각 버전을 올바르게 지원하는 곳에 정적 리소스를 배치하는 것입니다.
2. 거대한 JS 폭탄 처리하기
자바스크립트 파일을 압축하고 연결해야 한다는 것은 누구나 알고 있습니다. 하지만 그렇게 맹목적으로 행동하는 것은 현명한 행동이 아닙니다. 연결된 파일이 큰 경우 더 효율적인 접근 방식은 파일을 병렬화하는 것입니다. 또한, 파일의 특정 부분을 자주 수정해야 하는 경우 여러 곳에서 오류가 발생할 수 있지만 파일의 상당 부분이 수정되지 않은 경우가 있습니다.
자주 수정되는 부분을 분리하면 양면의 문제를 해결할 수 있습니다. require.js를 사용하는 것이 좋습니다. 이는 자바스크립트에 대한 진정한 종속성 관리를 가능하게 하고 처음 설정이 쉬우며(나중에 추가하기가 어려울 수 있음) 비동기식과 같은 일부 고급 옵션을 포함하여 종속성을 이해하고 관리하는 데 도움이 됩니다. 로딩.
참고: require.js는 리소스 로드를 포기하기 전에 일정 시간 동안 대기합니다. 이는 waitSeconds 옵션을 지정하여 달성할 수 있습니다. 이 옵션의 기본값은 사용자의 위치에 따라 다릅니다. (예: 휴대폰) ) 이는 매우 짧은 시간일 수 있습니다.
3. 오류 이벤트 집계 없음
자바스크립트를 온라인 상태로 두고 작동에 신경쓰지 않을 수 있습니다. 모든 브라우저와 모든 사용자의 상태 조합을 테스트할 수는 없습니다. 또한 로딩 시간이 다르면 이상한 동작이 발생할 수 있습니다. 따라서 사용자에게 오류가 발생하는지 여부를 확인하기 위해 일종의 피드백 메커니즘을 설정하는 것이 매우 중요합니다. 쉽습니다. 오류를 수집하여 서버로 보내는 전역 오류 처리기를 지정하기만 하면 됩니다. 예는 다음과 같습니다.
어려운 부분은 사용자가 다양하고 이상한 플러그인 등을 설치했을 수 있기 때문에 0이 아닌 오류가 여러 번 발생한다는 것입니다. 따라서 안정적인 상태가 무엇인지, 편차가 있는지 추적해야 합니다.
ReadyForZero는 최상위 수준에서 onError 이벤트를 캡처하여 서버로 보낸 다음 오류를 범한 사용자 수와 오류가 발생한 위치를 요약한 일일 보고서를 생성합니다. 오류 메시지만으로는 충분하지 않은 경우가 많으므로 이벤트 시스템에서 마지막 몇 개의 이벤트도 반환해야 합니다. 사용자가 최근에 트리거한 Backbone이나 JQuery 이벤트를 분석함으로써 사용자가 오류를 트리거했을 때 상황에 맞는 정보를 얻는 데 매우 유용합니다.
낮게 달린 과일 개선
실망스러운 부분은 이것이 우리가 걱정할 사항이 아니라는 것입니다. 기업은 제품에 더욱 집중하고 신속하고 고품질로 제품을 생산해야 합니다. 그러나 이러한 쉽게 실행 가능한 개선 사항이 구현되면 큰 움직임에 더 집중할 수 있다는 점을 기억하십시오.
사람들은 사소한 일에 갇혀 많은 시간을 보내지만, 앱을 실행하는 것만으로도 큰 성장을 이룰 수 있습니다.
1. 클라이언트 코드에 메모리 누수가 있나요? 확실해요? 어떻게 알았나요?
2. ReadyForZero [참고 1]에는 이 예술을 홍보하는 데 전념하는 똑똑한 사람들이 많이 있습니다.
[참고 1] ReadyForZero: Y Combinator가 자금을 지원하는 회사입니다. 회사의 목적은 온라인 플랫폼을 통해 소비자가 신용카드 빚을 청산하도록 돕는 것입니다.