Rethinking Text Resizing on Web : Airbnb가 접근성을 높이기 위해 WCAG의 권고에 따라 텍스트 크기를 2배로 키웠을 때도 웹 콘텐츠와 기능이 유지되도록 개선한 과정이다. 텍스트의 단위에 px, em, rem이 있지만 일관되고 예측할 수 있는 rem을 선택했고 후처리 도구를 만들어서 CSS에서 작성한 px를 자동으로, rem으로 변환하도록 했고 Figma 플러그인을 만들어서 디자인 단계에서 텍스트가 커졌을 때의 문제를 미리 확인할 수 있게 했다. 데스크톱은 확대에 대한 영향이 크지 않았지만, 모바일에서는 영향이 심했고 브라우저가 차이도 있었지만, rem 자동 변환을 통해서 쉽게 적용할 수 있었다.(영어)
Why, after 6 years, I’m over GraphQL : 오랫동안 GraphQL을 사용해왔고 옹호했지만, 최근에 그 입장이 변경되어 더는 추천하지 않는 이유를 정리한 글이다. 클라이언트에 쿼리 언어를 노출했기에 권한 부여나 Rate limit 같은 공격 표면이 늘어났고 N+1 성능 문제도 겪게 된다. 그리고 GraphQL에서는 비즈니스 로직이 전송 계층으로 이동되기 때문에 커플링이 심해지고 복잡해지는 문제가 있다.(영어)
State of HTML 2023 : HTML 생태계의 상황을 2만여 명에서 설문 조사해서 정리한 결과이다. From, 상호작용, 접근성 등 각 기능의 사용 여부와 알려진 정도를 살펴볼 수 있고 정적 사이트 생성기나 API의 사용 정도를 알 수 있다.(영어)
패키지 매니저의 과거, 토스의 선택, 그리고 미래 : JavaScript 패키지 매니저는 의존성을 처리하기 위해 어떤 의존성인지 고정하는 Resolution 단계, 해당 의존성을 다운로드 받는 Fetch 단계, 소스코드에서 해당 의존성은 사용할 수 있게 하는 Link 단계로 이뤄진다. 이 Link 단계가 npm, pnpm, yarn이 다른 접근을 하고 있는데 npm은 package.json의 의존성은 node_modules 폴더 아래 모두 작성하고 nnpm은 이 모두 파일에 쓰는 성능 문제를 해결하기 위해 모두 쓰지 않고 alias를 만들어서 연결하고 yarn은 Plug'n'Play 방식을 사용해서 .pnp.cjs 파일에 JavaScript Map으로 의존성을 찾는 방법을 명시해서 훨씬 빠르고 정확하게 동작할 수 있다. Toss는 Yarn의 좋은 아키텍처, 정확성과 성능 때문에 Yarn을 선택했다고 한다.(한국어)
Manifest V2 phase-out begins : 작년 11월 Chrome에서 공지한 대로 크롬 익스텐션의 Manifest V3의 도입으로 6월 3일부터 Manifest v2를 사용하는 익스텐션에서는 지원되지 않는다는 경고가 뜰 것이고 점진적으로 비활성화될 예정이다.(영어)
Keeping it 100(x) with real-time data at scale : Figma가 실시간으로 데이터를 가져오기 위해 내부에서 LiveGraph를 사용하는데 서비스의 성장에 따라 LiveGraph의 아키텍처도 다시 설계할 수밖에 없었다. 2년 전에 LiveGraph는 단일 Postgres의 replication stream에 의존한 구조였는데 부하가 커지면서 수직 샤드로 분할되자 전역으로는 순서가 보장되지 않았고 결국 큰 한계를 맞이하게 된다. LiveGraph는 실시간 업데이트를 위해 만든 서비스지만 트래픽을 분석하자 대부분은 초기 데이터 조회라는 것을 알게 되었고 쿼리를 분석한 결과 어떤 쿼리를 다시 조회해야 하는지 파악이 쉬워서 이에 따른 캐시 무효화도 쉽다는 것을 발견한다. 그래서 새로운 LiveGraph 100x는 Go로 만들었고 클라이언트의 뷰 요청을 처리하는 엣지, 쿼리 결과를 저장하는 읽기 캐시, 변경이 있으면 캐시 무효화하는 invalidator로 구성했다.(영어)
Visualizing algorithms for rate limiting : 특정 사용자가 서비스의 리소스를 모두 차지하지 않도록 하는 Rate Limit의 구형 방법을 설명한다. Fixed window는 가장 간단하고 사용자가 예측하기 쉽지만, 창 시작 시에 요청이 몰리거나 창의 시간이 긴 경우 타임존의 영향이 있을 수 있고 Sliding window는 동시에 받을 수 있는 개수를 제한해서 요청을 원활하게 분산할 수 있지만 리소스가 많이 필요하다. Token bucket은 버킷에 토큰이 있어야만 요청을 보낼 수 있고 일정 시간 간격으로 버킷이 채워지는 형태라 유연하지만, 사용자의 예측성이 떨어진다. 각 방식을 애니메이션으로 보여주어 이해하기 좋다.(영어)
Comments