https://jasonformat.com/islands-architecture/
Islands Architecture - JASON Format
I’ve struggled to find references to this online, but heard the name used multiple times this year when describing the approach outlined here. To the best of my knowledge, the "Component Islands" pattern was coined by Etsy's frontend architect Katie Sylo
jasonformat.com
위 글을 번역 했습니다.
온라인에서 이에 대한 자료를 찾기 어려웠지만, 올해 이 글에서 설명하는 접근 방식을 설명할 때 이 이름이 여러 번 언급되는 것을 들었습니다. 제가 아는 한, 컴포넌트의 아일랜드 패턴은 2019년에 있었던 회의에서 Etsy의 프론트엔드 아키텍트인 Katie Sylor-Miller가 만든 것입니다.
아일랜드 아키텍처의 일반적인 개념은 서버에서 HTML 페이지를 렌더링하고 매우 동적인 영억 주위에 플레이스 홀더 또는 슬롯을 삽입하는 것으로 놀라울 정도로 간단합니다. 이러한 플레이스홀더 / 슬롯에는 해당 위젯에서 서버 렌더링된 HTML 출력이 포함됩니다. 이러한 영역은 클라이언트에서 서버에서 렌더링된 초기 HTML을 재사용하여 작은 독립형 위젯으로 "하이드레이션"할 수 있는 영역을 나타냅니다.
여러개의 개별 임베디드 애플리케이션이 포함된 정적 HTML 문서라고 생각하면 됩니다.
언뜻 보기에는 마이크로 프론트엔드와 비슷해 보일 수 있습니다. 두 접근 방식 모두 애플리케이션을 독립적인 단위로 나눈다는 아이디어는 공유하지만, 마이크로 프론트엔드는 일반적으로 이러한 단위의 구성이 HTML을 사용하여 이루어짐을 의미하지는 않습니다.
아일랜드 접근 방식에 더 가까운 유서점은 점진적 개선으로, 기본적으로 페이지의 특정 영역에 상호작용을 추가하는 일관된 은유와 SSR 하이드레이션 기능을 추가한 것입니다. 기존의 점진적인 개선 방식에서는 페이지에서 이미지 캐러셀을 찾아 그 위에 jQuery 플러그인을 인스턴스화하는 스크립트가 있을 수 있습니다. 대신 해당 이미지 캐러셀이 서버에서 렌더링되고 이미지 캐러셀 구현을 로드하고 제자리에서 인터랙티브하게 업그레이드하는 전용 스크립트가 실행됩니다.
Why does this matter?
일반적인 단일 페이지 애플리케이션 아키텍처와 비교할 때 여기에 설명된 접근 방식 그룹에는 여러 가지 이점이 있습니다.
점진적인 하이드레이션 제공.
저는 React, Angular, Preact, Vue와 같은 프레임워크에 대한 프로그레시브 하이드레이션 기법의 성능 이점을 소개한 바 있습니다. 이러한 아키텍처에서는 페이지의 개별 위젯이 시간이 지남에 따라 로드되고 초기화됩니다. 이 작업 requestIdleCallback을 통한 간단한 스케줄링 방식을 사용하거나 뷰포트 가시성, 인터랙션 가능성, 제품 가치등과 같은 추가 요소를 고려하여 수행할 수 있습니다.
점진적 하이드레이션과 마찬가지로 아일랜드 아키텍처를 사용하여 페이지를 렌더링하면 페이지의 무거운 동적 부분이 점진적으로 초기화되는 것이 아니라 개별적으로 초기화됩니다. 즉, 페이지의 다른 어떤 것도 먼저 로드할 필요 없이 페이지의 개별 영역이 인터렉티브하게 됩니다.
점진적 하이드레이션과 달리 아일랜드 아키텍처를 중심으로 구축하는 접근 방식은 탑다운 렌더링이 필요하지 않습니다. 하위 컴포넌트보다 먼저 초기화해야 하는 외부 "루트"컴포넌트가 없기 때문에 이는 분명한 이점입니다. 페이지의 각 부분은 독립된 유닛이므로 한 유닛의 성능 문제가 다른 유닛에 영향을 미치지 않습니다.
SEO와 UX는 트레이드 오프가 아니다.
단일 페이지 애플리케이션에서 사용하는 SSR의 현재 상황은 종종 SEO를 위한 필수 요소로 인용된다는 것입니다. 그러나 SSR은 실제로 사용자 경험에 부정적인 영향을 미칠 수 있습니다. 방문자는 실망스러운 가짜 버전의 페이지를 보면서 실제 기능이 도착할 때까지 기다려야 합니다.
또한 많은 애플리케이션이 자각하지 못한채 조용한 SSR 성능 함정을 겪고 있습니다. 가상 DOM 라이브러리에서는 첫 번째 렌더링이 서버에서 렌더링된 HTML DOM을 파괴한 후 처음부터 다시 생성하는 (종종 동기식으로) 상황이 실수로 쉽게(그리고 흔하게) 발생합니다. 이는 몇 가지 일반적인 오해의 결과이며, 이는 문서에서 하이드레이션에 대한 이상적인 시가긍ㄹ 제공하면서 까다로운 주의 사항과 단점을 간과한 데서 비롯된 것일 수 있습니다.
SSR 하이드레이션이 설계대로 작동한 경우에도 현재 상황은 개선해야 할 점이 많습니다. 페이지 로딩 중에 수행되는 자바스크립트 작업은 양은 여전히 "효율적"이라고 간주되는 것보다 훨씬 더 많습니다.
아일랜드 모델에서 서버 렌더링은 SEO나 UX 개선을 위한 단편적인 최적화가 아닙니다. 대신 페이지가 브라우저에 전달되는 방식의 기본적인 부분입니다. 탐색에 대한 응답으로 반환되는 HTML에는 사용자가 요청한 콘텐츠에 대한 의미 있고 즉시 렌더링 가능한 표현이 포함되어 있습니다.
해당 HTML의 섹션에는 클라이언트 측 상호 작용이 누락될 수 있지만 문서에는 최소한 가장 필수적인 콘텐츠가 포함되어야 합니다. 예를 들어 뉴스 페이지의 HTML에는 기사 본문이 포함되고 제품 페이지에는 해당 제품의 설명이 포함됩니다.
다른 모든 콘텐츠는 이 정보에 비해 부차적이며, 이 정보가 HTML에 포함되는지 여부에 따라 제품 결정이 달라집니다. 이 정보가 페이지를 방문하는 사용자에게 얼마나 중요한 정보일까요? 해당 위젯이 비즈니스 모델에 얼마나 중요할까요? 수익과 직접적으로 관련된 "지금 구매" 버튼은 정보 수집과 관련된 사이트 피드백 설문조사 버튼보다 우선순위를 쉽게 정할 수 있어야 합니다.
접근성 및 검색 가능성 개선
탐색에 표준 HTML 링크를 사용하는 웹사이트는 보조 기술 및 웹 크롤러가 사용하기 쉽습니다. 이는 링크나 양식이 자바스크립트에 의해 가로채져 클라이언트 측 로직으로 경로가 재지정되는지 여부와 관계없이 해당되며, 링크를 클릭하면 해당 페이지로 이동한다는 가정이 그대로 유지되기 때문입니다.
일화로, 발시낮가 보고 있는 페이지로 추정되는 '링크'를 보냈지만 그 링크에 필요한 정보가 전혀 포함되어 있지 않다는 사실을 알게 된 적이 몇 번이나 있는지 생각해보세요:
페이지 기반 애플리케이션을 구축한다고 해서 이러한 유형의 이상한 경험을 완전히 방지할 수 있는 것은 아니며, 다만 더 직접적인 결정을 내릴 수 있게 해줄 뿐입니다. 기본 결과를 접근 가능한 결과로 만들 수 있습니다.
결론적으로 말하자면, 무언가를 수행하는데 더 적은 코드가 필요한 아키텍처를 출시하는 것은 미래의 자신(또는 동료)에게 장기적으로 도움이 될 것입니다. 이러한 모델을 채택하려면 더 많은 사전 설계 사고가 필요할 수도 있습니다. 앱을 독립적으로 전달가능한 위젯으로 분해하는데 사용할 수 있는 배터리 포함 옵션이 거의 없습니다. 누가 알겠습니까, 우리가 해결할 수 있을지도 모르죠.
