Habr 프런트엔드 개발자 로그: 리팩터링 및 반영

나는 Habr이 내부에서 어떻게 구성되어 있는지, 워크플로가 어떻게 구성되어 있는지, 커뮤니케이션이 어떻게 구성되어 있는지, 어떤 표준이 사용되는지, 여기에서 일반적으로 코드가 어떻게 작성되는지에 항상 관심을 가져왔습니다. 다행히 최근에 하브라 팀에 합류하게 되어서 이런 기회를 얻었습니다. 모바일 버전의 작은 리팩토링 예를 사용하여 다음 질문에 답하려고 합니다. 여기서 최전선에서 일하는 것은 어떤가요? 프로그램: Habr에서의 개인적인 경험에 대한 메모의 소스가 포함된 Node, Vue, Vuex 및 SSR.

개발팀에 대해 가장 먼저 알아야 할 것은 우리가 작다는 것입니다. 작은 것은 3개의 전선, 2개의 후방 및 모든 Habr-Baxley의 기술 리더입니다. 물론 테스터, 디자이너, 세 명의 Vadim, 기적의 빗자루, 마케팅 담당자 및 기타 Bumburum도 있습니다. 그러나 Habr 사이트에 직접 기여한 사람은 6명뿐입니다. 이는 매우 드문 일입니다. 수백만 달러 규모의 청중을 대상으로 하는 프로젝트는 겉으로는 거대 기업처럼 보이지만 실제로는 가장 수평적인 조직 구조를 갖춘 아늑한 스타트업에 가깝습니다.

다른 많은 IT 회사와 마찬가지로 Habr은 Agile 아이디어, CI 관행 등을 공언합니다. 하지만 제 생각에는 Habr은 지속적이라기보다는 하나의 제품으로서 발전을 거듭하고 있습니다. 그래서 연속해서 여러 번의 스프린트 동안 우리는 부지런히 무언가를 코딩하고, 디자인하고 재설계하고, 무언가를 부수고 수정하고, 티켓을 해결하고 새로운 티켓을 만들고, 마침내 기능을 출시하기 위해 갈퀴를 밟고 발을 쏘았습니다. 미래. 그런 다음 재개발 기간, "중요-긴급" 사분면에 있는 작업을 수행할 시간이 옵니다.

아래에서 논의할 것은 바로 이 "오프 시즌" 스프린트입니다. 이번에는 Habr 모바일 버전의 리팩토링이 포함되었습니다. 일반적으로 회사는 이에 대해 높은 기대를 갖고 있으며 앞으로는 Habr의 전체 동물원을 대체하고 보편적인 크로스 플랫폼 솔루션이 되어야 합니다. 언젠가는 적응형 레이아웃, PWA, 오프라인 모드, 사용자 맞춤화 등 많은 흥미로운 것들이 있을 것입니다.

임무를 설정해보자

한번은 일반 스탠드업에서 프론트 중 한 명이 모바일 버전의 댓글 구성 요소 아키텍처 문제에 대해 이야기했습니다. 이러한 제안으로 우리는 집단심리치료 형식의 소규모 회의를 마련했습니다. 모두가 번갈아 가며 어디가 아픈지 말하고, 아무도 박수를 치지 않는 것을 제외하고는 모든 것을 종이에 기록하고 공감하고 이해했습니다. 그 결과 20가지 문제 목록이 나왔고, 이를 통해 모바일 Habr의 성공을 향한 길고 험난한 길이 여전히 남아 있음이 분명해졌습니다.

나는 주로 리소스 효율성과 소위 매끄러운 인터페이스에 대해 걱정했습니다. 매일 '집-회사-집' 경로에서 나는 내 오래된 전화기가 피드에 헤드라인 20개를 표시하려고 필사적으로 노력하는 것을 보았습니다. 그것은 다음과 같이 보였습니다:

리팩토링 전 모바일 Habr 인터페이스

여기서 무슨 일이 일어나고 있는 걸까요? 즉, 서버는 사용자가 로그인했는지 여부에 관계없이 모든 사람에게 동일한 방식으로 HTML 페이지를 제공했습니다. 그런 다음 클라이언트 JS가 로드되고 필요한 데이터를 다시 요청하지만 이번에는 인증을 위해 조정됩니다. 즉, 우리는 실제로 동일한 작업을 두 번 수행했습니다. 인터페이스가 깜박였고 사용자는 100KB를 추가로 다운로드했습니다. 세부적으로 보면 모든 것이 더욱 소름끼쳐 보였습니다.

오래된 SSR-CSR 방식. 승인은 Node JS가 HTML을 생성하는 데 바쁘지 않고 요청을 API에 프록시할 수 있는 C3 및 C4 단계에서만 가능합니다.

Habr 사용자 중 한 명이 당시의 아키텍처를 매우 정확하게 설명했습니다.

모바일 버전은 똥이네요. 나는 그런 식으로 말하고 있다. SSR과 CSR의 끔찍한 조합입니다.

아무리 슬프더라도 우리는 이것을 인정할 수밖에 없었습니다.

저는 옵션을 평가하고 Jira에서 "지금은 좋지 않습니다. 괜찮게 만드세요" 수준의 설명이 포함된 티켓을 생성한 다음 작업을 폭넓게 분해했습니다.

• 데이터 재사용,
• 다시 그리는 횟수를 최소화하고,
• 중복 요청을 제거하고,
• 로딩 프로세스를 더욱 명확하게 만듭니다.

데이터를 재사용하자

이론적으로 서버 측 렌더링은 두 가지 문제를 해결하도록 설계되었습니다. SPA 인덱싱 측정항목을 개선하고 FMP (불가피하게 악화 TTI). 마침내 고전적인 시나리오에서 2013년 에어비앤비에서 공식화 (Backbone.js에서) SSR은 Node 환경에서 실행되는 동일한 동형 JS 애플리케이션입니다. 서버는 요청에 대한 응답으로 생성된 레이아웃을 반환합니다. 그런 다음 클라이언트 측에서 재수화 작업이 수행되고 페이지를 다시 로드하지 않고도 모든 것이 작동합니다. 텍스트 콘텐츠가 포함된 다른 많은 리소스와 마찬가지로 Habr의 경우 서버 렌더링은 검색 엔진과 우호적인 관계를 구축하는 데 중요한 요소입니다.

기술이 등장한 지 6년 이상이 지났고 이 기간 동안 프런트엔드 세계의 다리 아래로 많은 물이 지나갔음에도 불구하고 많은 개발자에게 이 아이디어는 여전히 비밀에 싸여 있습니다. 우리는 SSR을 지원하는 Vue 애플리케이션을 프로덕션에 출시하지 않고 한 가지 작은 세부 사항을 놓쳤습니다. 초기 상태를 클라이언트에 전달하지 않았습니다.

왜? 이 질문에 대한 정확한 답은 없습니다. 그들은 서버의 응답 크기를 늘리고 싶지 않았거나 다른 아키텍처 문제로 인해 발생하지 않았거나 성공하지 못했습니다. 어떤 식으로든 상태를 버리고 서버가 수행한 모든 것을 재사용하는 것은 상당히 적절하고 유용해 보입니다. 이 작업은 실제로 사소한 것입니다. 상태는 단순히 주입됩니다 실행 컨텍스트에 추가하면 Vue는 이를 자동으로 생성된 레이아웃에 전역 변수로 추가합니다. window.__INITIAL_STATE__.

발생한 문제 중 하나는 순환 구조를 JSON으로 변환할 수 없다는 것입니다(순환 참조); 이러한 구조를 평평한 구조로 간단히 교체함으로써 해결되었습니다.

또한 UGC 콘텐츠를 다룰 때 HTML이 깨지지 않도록 데이터를 HTML 엔터티로 변환해야 한다는 점을 기억해야 합니다. 이러한 목적을 위해 우리는 he.

다시 그리기 최소화

위 다이어그램에서 볼 수 있듯이 우리의 경우 하나의 Node JS 인스턴스는 SSR과 사용자 인증이 발생하는 API의 "프록시"라는 두 가지 기능을 수행합니다. 이러한 상황에서는 노드가 단일 스레드이고 SSR 기능이 동기식이므로 JS 코드가 서버에서 실행되는 동안 인증이 불가능합니다. 즉, 콜스택이 다른 작업으로 바쁜 동안에는 서버가 자신에게 요청을 보낼 수 없습니다. 상태를 업데이트했지만 사용자 세션을 고려하여 클라이언트의 데이터를 업데이트해야 했기 때문에 인터페이스의 경련이 멈추지 않은 것으로 나타났습니다. 사용자의 로그인을 고려하여 초기 상태에 올바른 데이터를 넣도록 애플리케이션을 교육해야 했습니다.

문제에 대한 해결책은 두 가지뿐이었습니다.

• 인증 데이터를 서버 간 요청에 연결합니다.
• Node JS 레이어를 두 개의 별도 인스턴스로 분할합니다.

첫 번째 솔루션은 서버에서 전역 변수를 사용해야 했고, 두 번째 솔루션은 작업 완료 시간을 최소 한 달 이상 연장했습니다.

선택하는 방법? Habr은 종종 저항이 가장 적은 경로를 따라 이동합니다. 비공식적으로는 아이디어에서 프로토타입까지의 주기를 최소한으로 줄이고자 하는 일반적인 바람이 있습니다. 제품에 대한 태도 모델은 booking.com의 가정을 다소 연상시킵니다. 유일한 차이점은 Habr이 사용자 피드백을 훨씬 더 진지하게 받아들이고 그러한 결정을 개발자로서 귀하에게 맡긴다는 것입니다.

이 논리와 문제를 빠르게 해결하려는 내 욕구에 따라 전역 변수를 선택했습니다. 그리고 흔히 그렇듯이 조만간 그에 대한 비용을 지불해야 합니다. 우리는 거의 즉시 지불했습니다. 주말에 일하고 결과를 정리하고 글을 썼습니다. 사후 부검 서버를 두 부분으로 나누기 시작했습니다. 그 오류는 매우 어리석었고, 그에 관련된 버그도 재현하기가 쉽지 않았습니다. 그리고 네, 부끄러운 일이지만 어떤 식으로든 비틀거리고 신음하는 가운데 전역 변수가 있는 내 PoC는 생산에 들어갔고 새로운 "2노드" 아키텍처로의 전환을 기다리는 동안 상당히 성공적으로 작동하고 있습니다. 공식적으로 목표가 달성되었기 때문에 이것은 중요한 단계였습니다. SSR은 완전히 사용 가능한 페이지를 제공하는 방법을 배웠고 UI가 훨씬 더 차분해졌습니다.

리팩토링의 첫 번째 단계 이후의 모바일 Habr 인터페이스

궁극적으로 모바일 버전의 SSR-CSR 아키텍처는 다음과 같은 그림으로 이어집니다.

"3노드" SSR-CSR 회로. Node JS API는 항상 비동기 I/O를 위해 준비되어 있으며 SSR 기능은 별도의 인스턴스에 위치하므로 SSR 기능에 의해 차단되지 않습니다. 쿼리 체인 #XNUMX은 필요하지 않습니다.

중복 요청 제거

조작이 수행된 후 페이지의 초기 렌더링은 더 이상 간질을 유발하지 않았습니다. 그러나 SPA 모드에서 Habr을 추가로 사용하면 여전히 혼란이 발생했습니다.

사용자 흐름의 기본은 형태의 전환이기 때문에 기사 목록 → 기사 → 댓글 반대로, 우선 이 체인의 자원 소비를 최적화하는 것이 중요했습니다.

게시물 피드로 돌아가면 새로운 데이터 요청이 트리거됩니다.

깊게 파고들 필요가 없었습니다. 위의 스크린캐스트에서 뒤로 스와이프할 때 애플리케이션이 기사 목록을 다시 요청하고 요청하는 동안 기사가 표시되지 않는 것을 볼 수 있습니다. 이는 이전 데이터가 어딘가에서 사라짐을 의미합니다. 기사 목록 구성 요소가 로컬 상태를 사용하고 파기하기 위해 이를 잃어버린 것 같습니다. 실제로 애플리케이션은 전역 상태를 사용했지만 Vuex 아키텍처는 정면으로 구축되었습니다. 모듈은 페이지에 연결되고, 페이지는 다시 경로에 연결됩니다. 또한 모든 모듈은 "일회성"입니다. 이후 페이지를 방문할 때마다 전체 모듈이 다시 작성되었습니다.

ArticlesList: [
  { Article1 },
  ...
],
PageArticle: { ArticleFull1 },

전체적으로 우리는 모듈을 가지고있었습니다 기사목록, 여기에는 유형의 객체가 포함됩니다. 기사 및 모듈 페이지기사, 이는 객체의 확장 버전이었습니다. 기사, 일종의 기사전체. 전반적으로 이 구현 자체에는 끔찍한 것이 없습니다. 매우 간단하고 순진하다고 말할 수도 있지만 매우 이해할 수 있습니다. 경로를 변경할 때마다 모듈을 재설정하면 그대로 사용할 수도 있습니다. 그러나 예를 들어 기사 피드 간 전환은 /피드 → /모두, 개인 피드와 관련된 모든 것을 버리는 것이 보장됩니다. 기사목록, 새 데이터를 입력해야 합니다. 이로 인해 다시 요청이 중복됩니다.

주제에 대해 파헤친 모든 것을 수집한 후 새로운 상태 구조를 공식화하여 동료들에게 발표했습니다. 논의는 길었지만 결국 찬성론이 의구심을 능가했고 저는 실행을 시작했습니다.

결정의 논리는 두 단계에서 가장 잘 드러납니다. 먼저 페이지에서 Vuex 모듈을 분리하고 경로에 직접 바인딩하려고 합니다. 예, 스토어에 데이터가 조금 더 많아지고 getter도 좀 더 복잡해지지만 기사를 두 번 로드하지는 않습니다. 모바일 버전의 경우 이는 아마도 가장 강력한 주장일 것입니다. 다음과 같이 보일 것입니다:

ArticlesList: {
  ROUTE_FEED: [ 
    { Article1 },
    ...
  ],
  ROUTE_ALL: [ 
    { Article2 },
    ...
  ],
}

하지만 기사 목록이 여러 경로 간에 겹칠 수 있고 객체 데이터를 재사용하려면 어떻게 해야 할까요? 기사 게시물 페이지를 렌더링하여 기사전체? 이 경우에는 다음과 같은 구조를 사용하는 것이 더 논리적입니다.

ArticlesIds: {
  ROUTE_FEED: [ '1', ... ],
  ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
  '1': { Article1 }, 
  '2': { Article2 },
  ...
}

기사목록 여기에는 일종의 기사 저장소가 있습니다. 사용자 세션 중에 다운로드된 모든 기사입니다. 우리는 이를 최대한 주의 깊게 다룹니다. 이는 역 사이의 지하철 어딘가에서 다운로드되었을 수 있는 트래픽이기 때문이며, 이미 다운로드한 데이터를 로드하도록 강요하여 사용자에게 다시는 이러한 고통을 끼치고 싶지 않습니다. . 객체 기사 ID 단순히 객체에 대한 ID(예: "링크")의 배열입니다. 기사. 이 구조를 사용하면 경로에 공통된 데이터가 중복되는 것을 방지하고 객체를 재사용할 수 있습니다. 기사 확장된 데이터를 병합하여 게시물 페이지를 렌더링할 때.

기사 목록의 출력도 더욱 투명해졌습니다. 반복자 구성 요소는 기사 ID가 있는 배열을 반복하고 기사 티저 구성 요소를 그려 ID를 소품으로 전달하고 하위 구성 요소는 차례로 다음에서 필요한 데이터를 검색합니다. 기사목록. 출판 페이지로 이동하면 다음에서 기존 날짜를 검색합니다. 기사목록, 누락된 데이터를 수신하도록 요청하고 이를 기존 객체에 추가하기만 하면 됩니다.

이 접근 방식이 더 나은 이유는 무엇입니까? 위에서 쓴 것처럼 이 접근 방식은 다운로드한 데이터에 대해 더 주의를 기울이고 이를 재사용할 수 있게 해줍니다. 그러나 이 외에도 이러한 아키텍처에 완벽하게 들어맞는 몇 가지 새로운 가능성의 길을 열어줍니다. 예를 들어 기사가 표시되는 대로 피드에 기사를 폴링하고 로드합니다. 최신 게시물을 간단히 "저장소"에 넣을 수 있습니다. 기사목록, 새 ID의 별도 목록을 기사 ID 그리고 이를 사용자에게 알립니다. "새 출판물 표시" 버튼을 클릭하면 현재 기사 목록 배열의 시작 부분에 새 ID를 삽입하기만 하면 모든 것이 거의 마술처럼 작동합니다.

다운로드를 더욱 즐겁게 만들기

리팩토링 케이크의 장식은 느린 인터넷에서 콘텐츠를 로드하는 과정을 조금 덜 좌절하게 만드는 뼈대 개념입니다. 이 문제에 대한 논의는 없었으며 아이디어에서 프로토타입까지의 과정은 문자 그대로 2시간이 걸렸습니다. 디자인은 실제로 그 자체로 그려졌으며, 우리는 데이터를 기다리는 동안 간단하고 거의 깜박이는 div 블록을 렌더링하도록 구성 요소를 가르쳤습니다. 주관적으로 이러한 로딩 방식은 실제로 사용자 신체의 스트레스 호르몬 양을 감소시킵니다. 뼈대는 다음과 같습니다.

하브라로딩

반영

저는 Habr에서 6개월 동안 일했는데 친구들이 아직도 묻습니다. 음, 그곳이 마음에 드나요? 알았어, 편안해 - 응. 하지만 이 직업이 다른 직업과 다른 점이 하나 있습니다. 저는 제품에 완전히 무관심하고 사용자가 누구인지 모르거나 이해하지 못하는 팀에서 일했습니다. 하지만 여기서는 모든 것이 다릅니다. 여기서 당신은 자신이 하는 일에 대해 책임감을 느낍니다. 기능을 개발하는 과정에서 귀하는 부분적으로 해당 기능의 소유자가 되고, 기능과 관련된 모든 제품 회의에 참여하고, 제안하고 스스로 결정을 내립니다. 매일 사용하는 제품을 직접 만드는 것은 매우 멋진 일이며, 자신보다 이를 더 잘 이해하는 사람들을 위해 코드를 작성한다는 것은 정말 놀라운 느낌입니다(비꼬는 말이 아닙니다).

이러한 모든 변경 사항이 출시된 후 우리는 긍정적인 피드백을 받았으며 매우 좋았습니다. 그것은 고무적입니다. 감사합니다! 더 많이 쓰세요.

전역 변수 이후에 아키텍처를 변경하고 프록시 레이어를 별도의 인스턴스에 할당하기로 결정했음을 상기시켜 드립니다. "2노드" 아키텍처는 이미 공개 베타 테스트 형태로 출시되었습니다. 이제 누구나 이를 전환하여 모바일 Habr을 개선하는 데 도움을 줄 수 있습니다. 오늘은 그게 다야. 댓글을 통해 귀하의 모든 질문에 기꺼이 답변해 드리겠습니다.

출처 : habr.com