This month I Learned - 23년 2월
매일매일 업데이트
02.11(토) #
프론트엔드 아키텍처: Business Logic의 분리
- 비즈니스 로직을 분리하는 이유
- 뷰 로직과 비즈니스 로직은 맡은 임무와 책임이 다르다.
- 섞이면 유지보수 관점에서 비용이 증가 (응집도가 떨어짐)
- 비즈니스로직을 뷰에서 분리 후 클래스에 응집함
- 뷰에서 비즈니스 로직 분리시 장점
- 관심사 분리
- 객체지향적인 아이디어로 비즈니스 로직을 구성할 수 있다.
- 테스트 대상이 명확하다.
02.13(월) #
Higher-Order Components는 여전히 유용하다
- hoc는 컴포넌트 로직 재사용을 위한 패턴이다.
- hooks 이후로는 사용 빈도가 줄었지만 hooks와 달리 렌더링 조건(컴포넌트 리턴)을 결정할 수 있다는 점에서 여전히 유용함
02.14(화) #
피그마 폰트 이슈 #
- 피그마의 폰트 굵기가 브라우저 보다 얇게 나옴
- 피그마에서는 폰트에 자체 안티앨리어싱을 적용하기 때문
좋은 함수 만들기 - 부작용과 거리두기 #
- 동일한 입력일 경우 항상 동일한 출력을 반환하며, 부작용이 없는 함수를 작성한다면 우린 좋은 함수를 작성한다고 볼 수 있다.
- api호출과 같은 외부 의존성은 비즈니스 로직에서 격리시켜야 한다.
- 테스트하기 어려운 부작용 함수는 전염성이 높다.
- 테스트하기 어려운 함수 하나가 만들어지고, 해당 함수에 의존하게 되면 의존하는 함수들까지도 테스트가 어려워진다.
- 부작용 함수와 순수함수를 격리.
- 유닛테스트는 비즈니스로직을 담은 순수함수만 해도 됨
02.16(목) #
거대한 서비스 쪼개서 마이크로 프런트엔드 만들기 #
- 두레이 메인 서비스 리뉴얼 프로젝트
- 모놀리식 구조의 단점
- 서비스는 점점 더 복잡해지고, fe 엔지니어는 모든 도메인 지식을 다 섭렵하기 어렵다.
- 각각의 서비스 담당자에게 해당 서비스의 오너십을 주고 싶다.
- 소스가 방대해지고, 개발/빌드가 점점 길어진다.
- 통합하고 qa하고 배포하는 과정이 힘듬.
- 엔지니어에게 기술적인 선택권을 주고 싶다.
- → 하나의 서비스만 독립적으로 개발, 배포, 운영할 수 없을까?
페이지간 통합
- 방법 1 - Linked single-page applications
- 그냥 서비스별로 SPA를 따로 만드는 방법
- 팀 내부에서는 history api를 통한 클라이언트 측 라우팅을 사용 (soft navigation)
- 팀 간에는 하이퍼링크를 이용한 hard navigation 사용
- 두레이는 서로 다른 서비스를 유저가 빈번하게 전환하는 앱이므로 잘 맞지 않는 방법이었다.
- 그냥 서비스별로 SPA를 따로 만드는 방법
- 방법 2 - Unified single-pagej application
- App shell을 만든다.
- 모든 하위 서비스들의 상위 애플리케이션 역할
- 들어오는 모든 요청을 라우팅에 맞게 하위 서비스에 연결
- App shell을 만든다.
페이지 내 통합
- 런타임에 코드조각을 통합하기위해 webpack module federation 설정
- 생략
코딩보다 중요한것들
- micro frontend는 구체적인 기술이 아니다.
- 서비스가 충분히 커져서 복잡도의 증가를 따라가지 못할 때 선택할 수 있는 여러가지 대안 중 하나임.
- 개발도 중요하지만 운영하면서 나오는 요소들을 계속 고려하며 발전 시켜야 한다.
- 모놀리식 spa를 만들던 팀 구조 그대로 마이크로 프런트엔드를 적용하면 잘 되지 않을 것
- 매일 프론트엔드 개발자가 대화를 해야 할 대상은 다른 프론트 개발자가 아니라, 해당 도메인의 기획자, 백엔드 개발자이다.
todo